The progression of a software career

I don’t want to bury the lede here: this is a post about the impact of AI. Of course it is. Every blog post written in 2026 is about AI.

Anyway, with that out of the way, I want to tell you a little bit about someone I know well and his progression as a software engineer. (yes, that someone is me)

There he was, a 14-year-old kid, sitting, staring, amazed at the text he saw on his computer screen. Sitting there, in neon green on a black background, the words almost immortal, “Hello World!” I am not really sure why he was amazed. The text was the output of a program written in BASIC. A program that looked like:

1
10 CLS
2
20 PRINT "Hello World!"
3
30 END

Should a program so simple, so obviously clear, really be amazing?

It was the first computer program he had ever written. But it wasn’t just a program, it was a moment.
A special moment where the computer ceased to be a device and became a canvas. Nick was no longer a simple boy, he was now an artist. The text on the screen bringing life one keystroke at a time.

This fascination with making bits turn into bots would never go away. Nick left for college and craved every programming class he could get into. Eventually graduating in Computer Science, he thought he had the perfect life. Getting paid, to write code. Nothing could top that.

Writing the code wasn’t just artistry, it was also a puzzle. A mental exercise in which one would fight with physics itself. A intellectual amusement park ride where ultimate fear, excitement, and the thrill of the unknown, all intertwined. The fulfillment of sitting for hours, confused and frustrated, suddenly wondering if you are cut out for the task, only to finally solve the case. It was a feeling of accomplishment that could only be described as euphoria.

But writing software as a professional engineer is not craft alone. It’s also a practice. A discipline that requires rigor. A task that must also appease the cravings of capitalism. It’s not enough that code work, it must be bug-free. It must do something meaningful for others. And as Nick continued to receive a paycheck for his code, he realized slowly, that his love for software was changing. He had to leave a piece of himself behind. At first, writing code for other’s people’s problems was an excuse to connect with the CPU. But the art, the creativity started to fade. He was still doing what he loved, but it didn’t bring the same level of joy as before when he was able to work on anything.

Hope was not lost. As the dollars kept coming, Nick started to realize that leaving the hobby behind opened the door to a different avenue of joy. The engineering side of software. The code has a life. It was not just bits on a page, but it would live on; see another day where another engineer would modify it.

Things such as “code quality”, “maintainability”, “performance” all started creeping in. Each one stretching him to grow. To be better. The challenge was back. The mental stimulation would continue. But no longer the same. It was as if the puzzle had shifted. No longer working on the edge pieces all the time, he was now working on the inside.

Time goes on, and Nick sees himself as a manager. Finding less and less time to code as he manages others and attends meetings. What had he done? Is management a good fit? Perhaps the loss of the keyboard is not worth it. But yet again, just as before, he finds himself in the middle of an awakening. More puzzles to solve, this time deeper than the rest.

Lets talk about legos

Nick’s story is one about abstraction. Surely, a word you are used too if you are a software engineer. To over explain what is happening, let’s go to the world of legos. legos make a lot of types of sets. There are pirate legos, star wars legos, princess legos, race car legos, and more. When I was a child, I LOVED star wars legos. The lightsabers, the droids, the spaceships. Making them was a dream.

I would sometimes play with other legos too. And you know what? I still enjoyed them. They weren’t star wars. They weren’t the same. But they were still legos.

Let’s say you are tasked with building a city of legos. (Sort of like legoland). You are hired to work on one section of that city. Well, there will come a time when that section is done, and you will have to start using a different lego set. You know star wars. You know how the droids go together. You know all the configurations of the lightsabers. But there isn’t any more room, and the princess section is still needing to commence. Over time, you will find that there is just as much joy in the princess set. There is nuance you didn’t understand before.

If you continue to be good at legos, your knowledge of both star wars AND princess legos will impress some. It might make sense for you to start teaching others. Now they are the ones building legos as you watch. You will still help, but not as much. But as you teach them, you will find that you are still learning. What you thought you knew, you are only beginning to understand. The teaching of the thing helps you understand it deeper.

With each section of the lego city being built, someone needs to put them all together and make them blend together in a cohesive way. You might not be working with the individual pieces anymore, but it’s still legos, and they still use the same system. Making the sets blend, and not feel thrown together is an art unto itself.

Every layer just builds on the next. You never lose your connection with the legos. You will always gain a deeper love than the one you left behind.

Back to me

In my career, I have gone from Individual Contributor, to Team Lead, to Manager, back to Individual Contributor, back to manager, to director, and above. Each time, I had to give a piece of myself away. Each time I did, I also found far more than I gave. My passion grew over time, it did not diminish.

Along with passion, my level of control also changed. When I was writing code myself, I had to make sure my code was solid. That it didn’t have bugs. That it worked. I did this because 1) I cared and 2) because thats the job and I am held accountable.

But eventually, I wasn’t the one writing the code. Instead I was the one reviewing it. I would take the effort to review the code as if I had written it. But once I became more senior, I realized I could no longer apply my own standard on other engineers. My bar for what level of quality could be accepted had to change.

Then as a manager, I did not have the time to review all the code anymore. Some code would make it all the way to production without me ever seeing a line of it. What do you do? Thats a weird moment. How do you make sure everything is good? Well, the simple answer is the transitive trust property. If you didn’t review the code, then thats okay as long as someone else you trust did.

This works for a while, but it doesn’t hold forever. The purpose of reviews and ownership is to have someone to “blame”. Someone to take responsibility for an issue in production when the program is incorrect. When you say you trust someone else with code, you aren’t really trusting the code itself, you are trusting that that person is good enough to fix the code quickly if anything were to happen, and resolve any downstream issues.

But therein lies the problem. If you are in this career long enough, whether the management or engineering track, there will come a day when a production issue happens that needs a fast response. A production issue which is caused by code you didn’t write, code you didn’t review, written by someone you didn’t hire and isn’t even at the company anymore. Code, which you weren’t even around when it was being discussed. And with all that on the table, you will nevertheless be the one holding the bag.

What do you do then? How do you handle it? Well, that is the moment you realize shipping high-quality software is no longer about playing gatekeeper, but about the systems you put into place. Software engineering isn’t actually about the functions, its about the services. You thought legos was hard, but your career is just beginning: keeping the lego city running is the real challenge.

Okay, now its time to talk about AI

I would love to tell you your career would look like this. I would love this to be an article about self discovery. But it’s not. This article is about how I evolved, slowly, over time, to become a software engineer. Maybe the better word is architect, i’m not sure. But I no longer see software the same. That transition happened slowly. Each step in my career allowed me time to process. Time to find a new piece of myself after having lost another. Almost every engineer I know of at my stage in career is embracing AI as if it’s obvious. You see, we have “evolved” to understand that code quality cannot be created by reviews alone. We have learned how to pull levers on software, without writing any code. I am used to having code written on my behalf from a loosely worded spec, and make it all the way to production without me ever once seeing the underlying code. So for me, letting AI write software, doesn’t seem too out of place.

But for you. You. The target of this article. If you have yet to be in this position in your career, then what is happening now to you, I can’t even fathom. You are being asked to jump all the way to my finish line in the timespan of a couple of months. I have no idea what emotions you have. I honestly can’t imagine them. I had those emotions. But not at once. I had time. Time to process. Time to fight. Time to wake up. You don’t. You must immediately accept that your job has changed. Changed without you ever having the training to be performing at the level you must now be expected to run at.

But, it’s now. It has happened. You are now where I am. I no longer have more experience than you. We are all here, at the same level now.

Good luck.