It feels like we can never learn enough in our field.
As software engineers, calling ourselves an “expert” in any area just doesn't feel right.
How could we ever know everything about a specific language or framework?
Here's why I believe this is a good thing.
We first learn to program simple things. “Hello World”, a simple website, a calculator.
Then our programs and the problems we solve with them get more complex. A to-do list app, a simple game, a CLI for our personal needs. We've learned enough to be dangerous, so we get a job as a developer.
On the job, we learn there's so much more to programming than learning a few languages and frameworks. Depending on our specialization, we learn about performance optimization, microservices, user and authorization management, or memory efficiency. We learn about version control and how to fix merge conflicts. Securing environment variables. And working in a team, coordinating with our coworkers, mangers, and clients.
And on top of all that there's a lot of domain knowledge to learn. And the business and team-wide processes. And all that legacy code.
Our job has a high inherent complexity, because to support real-life processes we need to model the complex, messy real world. Add to this the intricacies of multiple humans working together and technology rapidly advancing, and you have the environment we developers find ourselves in.
The easy, high-value problems were solved first. Book-keeping in banks and payrolls in large companies. Over time, the problems we solve with software became more complex.
And now, as our problems became more complex, the systems we're building became much more complex, too.
Software engineering is about so much more than languages, frameworks, and libraries.
It's about building maintainable applications to support humans. To make activities easier, enable things not possible before, or just to be fun. The libraries and programming languages are just the tools we use.
An expert software engineer is someone who:
Being an expert software developer means having a good, experience-based guess which tools and approaches to use for certain problems. It doesn't mean having all the answers.
When building non-trivial applications, in complex domains, in teams, with tools that change and improve all the time, we'll never finish learning.
And that's what I love about being a developer.