Seeing the Bigger Picture
I’ve lived in more than two countries, spending a few years in each. They were spread across different parts of the world, shaped by different histories, cultures, mindsets, and ways of life. When you experience that, you start to see each place more clearly — its strengths, its weaknesses, and why one might thrive where another struggles.
The same thing happens in software development. A Windows C++ developer will have a different perspective from a Linux C++ developer. But if you’ve worked with both, you gain a broader, deeper understanding of C++ itself — not just the syntax, but the ecosystem, the tools, and the philosophy behind each platform.
A Mindset Problem in the C++ Community
There’s a mindset problem in the C++ world — or maybe in the C++ community. Many C++ developers are not willing to learn from other programming languages.
Take Java, Kotlin, or C#. These languages have thriving communities that focus not just on language features, but on building better architectures and maintainable systems. They publish books, articles, and talks about design principles, clean architecture, and evolving systems that businesses depend on.
But in the C++ world, we talk about “Modern C++.” Why do we even need that label? We don’t talk about “Modern Java” or “Modern Kotlin.” The language evolves, but the community focuses on design and architecture.
The Same Old Problems
Meanwhile, many C++ projects are still plagued by the same old problems: unreadable code, tight coupling, and fragile designs. When code is hard to read, it’s hard to extend, reuse, or safely modify. And because of C++’s low-level nature, memory issues — like buffer overflows — are still common. That’s not surprising. What is surprising is that, after decades, we still approach design the same way.
The Business Perspective
C++ was invented before Java and had already been widely used because of its unmatched performance. Even today, one of C++’s great strengths is its efficiency — with tools like smart pointers, developers can avoid unnecessary copies and directly access the original memory, reducing runtime costs.
But when you look at languages like Java, C#, or Kotlin — which don’t have this level of control over memory and don’t offer features like smart pointers — you still see their communities insist on design and architecture first. Why? Because software exists to solve business problems.
Business goals are what drive software projects. If we can’t deliver maintainable, extendable, and understandable code, the business suffers. Projects get delayed, technical debt grows, and long-term costs skyrocket.
And that’s the striking part: despite having more powerful tools and better performance, C++ projects often have less readable, less maintainable code compared to their counterparts in Java, C#, or Kotlin.
Features vs. Design
For example, many C++ developers argue that templates are “better” than abstractions. But templates and abstractions serve different purposes. Abstraction is a design technique — a way to make software more modular, maintainable, and clear. Templates are a mechanism for static polymorphism and compile-time optimization. Yes, templates can be faster, but performance has never been C++’s main problem. C++ already offers near top-tier performance — second only to C, and close to assembly.
So why is the community still obsessed with squeezing out more performance through language features, while largely ignoring design discussions? In other language communities, architecture and maintainability are a constant focus. In C++, most of the conversation is about features — “modern” features, “sexy” features — instead of the decades-old design issues that still hurt readability and maintainability today.
Tools Should Follow Design
To put it another way, in the C++ world, we often think about features first — new capabilities, new syntax, new “modern” constructs — before thinking seriously about design.
But in many cases, we could have a much clearer, more maintainable implementation without using any fancy features at all. When you start with features, you often end up locking yourself into an approach before you’ve even decided what the architecture should look like. The result is tightly coupled, hard-to-extend, hard-to-modularize code — something I’ve seen repeatedly across many C++ projects.
Features are just tools. They exist to make our lives easier. But they should follow good design, not dictate it. We have decades of knowledge about software design — principles, patterns, and lessons learned — that we can apply regardless of language. And yet, in the C++ community, those lessons are too often ignored in favor of feature-driven development.
