A Decade of Software Engineering: Between Arrogance and Imposter Syndrome
What makes a good software engineer?
Is it the language they write in, the number of projects shipped, or the titles they've collected? After ten years in the field, I’ve seen Juniors teach Seniors, Seniors over engineer and cling to outdated tools, and hype cycles turn best practices into legacy code almost overnight. Rather than discussing what the "right" tools are, I want to reflect on what actually matters in the long run:
What actually defines a good software engineer in a field that constantly changes?
Recently, a Recruiter asked me to rate my expertise in specific areas from 1 to 10, and aggregate a list of every technology and methodology I worked with in every position I worked in, rather than just the ones relevant to the positions I was targeting.
Rating myself felt almost impossible. The more you see of the world, the smaller you become, and what once felt like mastery in hindsight feels like scratching the surface.
But compiling the full list turned out to be fascinating. While technologies and methodologies changed, matured, or withered away, I accumulated an incredible set of 50+ entries, not even counting the countless libraries and APIs along the way.
Nevertheless, after a decade of adopting a myriad of tools, ranging from bleeding edge to de facto standard, sometimes checking even 40% of the tech requirements is ludicrously hard.
What springs to mind is the time IBM was posting a Job opening for a Technical Product Manager with 12 years of Kubernetes experience ... when Kubernetes existed for only 6.
I’ve worked across stacks and methodologies, from jQuery to Angular Microfrontends, from PHP symfony monoliths to Scala Data Pipelines and Event Driven Kotlin Microservices, on-prem to Kubernetes. I’ve shipped Waterfall, Scrum, Kanban, and back again. Tools changed, titles changed, and much of what I once tried to master became obsolete.
In his talk about modern software engineering, Dave Farley at Tech Excellence takes a step back to look at how software engineering fits into the family of engineering itself and what they share, and came up with this definition: "Engineering is the application of an empirical, scientific approach to finding efficient solutions to practical problems.
And in "Pragmatic Programmer", Andy Hunt and Dave Thomas advise you to pick up a new language or framework at least every year, not only for the obvious reason of staying relevant in your field, but to experience new ways of thinking and solving problems.
The skills that I personally feel make a great engineer are the following:
- Perseverance: I can't think of many fields that demand the same amount of continuous learning and shifting thought as software engineering does. Even if writing COBOL for mainframe banking applications, if you fall behind, there will be a time when the software is not the only thing that's modernized.
- Analytical Thinking: This will help you follow the flow of requirements derived from the business, turn them into structured code, and follow the code written by others.
- Communication: Whether discussing requirements or change requests with a client, PM or PO, debating architecture decisions and reviews with your peers, or mentoring junior engineers, the best engineers are hardly helpful if they can't share their ideas and explain their thought processes.
- Strategic Prowess: Especially regarding infrastructural and architectural decisions, you need to understand the situation and plans of the company or client you're working for. Build too big and your venture might crash, or burn a lot of money, build too small and it might not scale.
The more languages and frameworks you work with, the more paradigms and patterns are added to your toolbox, making it increasingly easy to learn new pieces of technology and incorporate different ways of working. As knowledge becomes more readily available in many forms of self-learning material, and AI can speed up learning processes even further by providing examples, explaining code, and taking over scaffolding, I think the value lies in exposure to varying problems, rather than years of repetition.
Looking back now on over a decade in the business, I experience it to be a constant rollercoaster, where you feel like you've mastered one thing, just before meeting new technology, peers, or ways of working, that expand your world, leaving you humbled and doubting yourself all over again.
At this year's CodeCrafts conference, I had an interesting discussion about what drives people to our field and what makes them stick around. And while financial incentives are inarguable there, I doubt they are what sustains people in the craft over a long time.
I feel grateful for all the different problems and approaches I faced over the years. For me, the most monotonous periods, the times I came closest to getting into goat herding, were those where I kept solving the same problems over and over.
What got you into software? What keeps you around?
