It’s Not Over Yet: Stories of an Aging Software Developer

As we grow older, our outlook on life changes. We go through physical and mental changes. Both types of changes impact the kind of work we can and like to do. This is most obvious in professions that require physical work. A 30-year-old tennis player is old. A construction worker’s body cannot take as much abuse at the age of 50 as it could at 20. Easy to see. But what about a software developer?

When I started my career, I felt on top of the world and capable of solving any problem. This was in no small part due to the culture at Oracle. I guess you would call it “toxic masculine” today. I got away with writing a 32KB SQL query in VI that actually did what it had to do. Later, I used the same attitude, “Why wouldn’t this work?” to set up the first web presence at a Dutch insurance company called Centraal Beheer. Life ran its course; children were born, and work-only was frowned upon. At some point, I looked back and realized I had become an IT architect. This seems to be a natural career path: Software developers become team leads, and team leads become managers or architects. With some 25 years to go until retirement, that didn’t seem like a very attractive outlook. What happened to the young man who could churn out megabytes of archaic SQL?

Not good. So, I decided to go back to software development. From a distance, it would seem like a lot changed in my decade as an architect. We have new programming languages and infrastructure as code and clouds and whatnot. We have better tools and more powerful hardware. But, finding a solution for a customer’s IT challenges is seldom about technology— it’s mostly about working effectively as a team. This means challenging the requirements we’re given and reducing the size of the problem that needs solving. My youthful technology focus used to get in the way of cheaper solutions. Finding the simplest solution to the smallest problem yields the lowest cost for the customer.

What used to happen: I picked up a task, and my only goal was to finish the code as soon as possible. This produced software really quickly that mostly did what it was supposed to do. I used to work in teams following a waterfall approach, so someone would write a specification, the next person would turn that into a design, and I would turn that design into code. Luckily, the industry has moved on, and we currently have Agile processes to ensure we keep doing the right thing. But still, people focus on turning stories into code. I learned to never take a story at face value. There’s always a way to make it smaller or better suited to solve a real need. As long as I kept thinking of myself as an engine that turned requirements into code, I could only give customers what they asked for, not what needed to be done.

Giving people what they need requires building a relationship with them and understanding their business. No need to become a specialist in banking or insurance or whatever, but enough to understand what your customer is talking about. So you can ask the right questions.

I can easily keep asking the right questions and listening to their answers for years to come. Having calmed down and settled, I care more about team results than individual success. Nice. Now, on to the next chapter of my career.