Eleven Years In: A Developer's Shifting Priorities

I started keeping this journal in 2014. Eleven years is long enough to see how a developer changes. As the year draws to a close, I looked back at my old posts and realized that what changed wasn’t the technologies — those always change. What changed was what I chose to prioritize.

From Speed to Resilience

There’s a word that keeps coming up in my early posts: speed. How fast I could build something, how much a tool sped up my workflow. Back then, a good developer was one who shipped fast.

Speed still matters today, but it’s no longer the primary metric. Now, when I look at a solution, the first question I ask is: how painful will it be to change this six months from now? Code written quickly but untouchable ends up costing more than code written slowly but with flexibility. My priority has shifted from speed to resilience.

This shift happened gradually. At some point, I noticed I was asking less “how does this work?” and more “why does it work this way?” and “what will someone else make of this when they read it?” It’s not enough for code to work today — it needs to make life easier for whoever has to change it six months from now, which is usually me.

From Code to Decisions

At the mid-level stage of my career, code was at the center of my work — writing it, running it, fixing it. My posts reflected that: “here’s how I did this.”

Over the years, the center of gravity shifted from code to decisions. Today, the most value I add often isn’t a line of code but rather calls like “let’s not do this,” “not now,” or “let’s solve this problem with this language instead.” Code is just the last step of a decision. Some of the best things I’ve written were the code I chose not to write.

The clearest sign of this shift: in the past, I used to wait for my turn to ask a question in a meeting. Now, steering the meeting, setting the frame rather than asking questions — that’s become my role. Technical decisions are still my domain, but thinking about why those decisions were made, how they’re communicated and to whom, and in what order they get implemented — all of that has become part of the job.

From One Language to Many

Eleven years ago, I defined myself as a PHP developer. PHP is still my backbone today, but I no longer define myself by a single language. I work in the worlds of Go, Python, and JavaScript as well. This isn’t a collector’s enthusiasm — I’ve reached a point where each problem leads me to its own language. Being polyglot became a natural outcome of the years, not a goal I set out to achieve.

While learning each new language, I noticed something unexpected: a new language reveals which parts of your primary language are “the language itself” and which parts are just “habit.” Learning error handling in Go made me re-examine how I used exceptions in PHP and how often I was writing them unnecessarily. Learning a language isn’t just acquiring vocabulary — it’s adopting different ways of thinking.

What Hasn’t Changed

Amid all this change, one thing has stayed constant: the learning continues. Eleven years ago I was learning something new; I still am today. The difference is that I now know I don’t need to learn every new thing — deciding what not to learn is also a skill.

Writing hasn’t changed either. This journal has been a thinking tool for me for eleven years. Time and again I’ve seen that I don’t fully understand something until I’ve written it down.

The Year Ahead

I don’t know exactly where my priorities will shift next. But I can sense the direction: less “how,” more “why” and “when not to.” Eleven years ago, being a good developer meant being capable of doing a lot of things. Today, it means being able to choose the right thing. This journal will keep being a record of that change.