In my last post, I wrote about the problems I was creating for myself by trying to learn everything at once. Which summarised is just that I was spreading myself too thin.
Too many topics, too many projects, and too many things I thought I should know.
So I've been trying to follow my own advice. I've stopped chasing every new technology that catches my attention and started being a bit more deliberate about what I spend my time learning.
This sounds great, but there's just one problem. What should I actually focus my time on?
It's easy to say "learn less" or "focus more on one thing". But that still leaves a pretty important question unanswered.
What is that one thing?
I've spent the last few months thinking about that question, and I eventually realised that I wasn't looking for another technology to learn. But rather, what direction I should be headed toward.
For me, the answer started to become clearer when AI started becoming a much bigger part of my day-to-day work. The company I work for eventually got everyone a Claude subscription, and we started using it properly in our development workflow.
And it was impressive, like really impressive.
I started seeing what people had been talking about online. Claude could take a feature, understand the requirements, write a good chunck of the code, and move on the the next thing before I would have even finished typing out the first function.
We were getting to the point where the AI could produce features faster than the team could write the specs for the next one. But the more I used it, the more I started to realise something about it.
The AI would sometimes take shortcuts.
It might hardcode something that shouldn't be hardcoded; it might ignore a pattern we'd established elsewhere in the codebase; it would solve the immediate problem perfectly well while completely missing the bigger architectural structure. And the problem wasn't that the code was bad; more often than not, the system worked just fine. The tests passed; the feature did what it needed to; there were no obvious errors. But I would look at this and think: "That's not how we should be building this".
So I'd fix it. We'd update the documentation or the skills we were giving Claude, add another guideline, and try again. The AI would get better and follow the rules we'd established. And in that process, I had a realisation. Maybe my job isn't going to be about writing every line of code myself anymore. But maybe it's becoming more important that I understand what good software looks like in the first place.
I think this is where I've started to change the way I look at learning. For a long time, a lot of my learning was focused on the how.
How do I use this framework?
How do I deploy this application?
How do I configure this service?
How do I implement this feature?
Those are useful questions, sure. But increasingly, I'm finding myself more interested in the questions underneath them.
Why are we doing it this way?
Why is this data in a document and not a table?
Why do we need to cache?
Why does this application need a queue?
Why are there multiple services?
I think there's a difference between knowing how to use a technology and understanding the problem that technology is trying to solve. I can learn the commands to deploy something to Kubernetes without really understanding why Kubernetes exists. I can learn to configure a load balancer without understanding what problems appear when an application goes from one server to ten. I'm sure I can even ask AI to implement those for me.
But if I don't understand the underlying problems, I'm mostly just hoping that the thing it builds is the right thing. And that's the part I want to change. I don't want my learning to be about collecting enough knowledge to recognise the names of more technologies.
I want to understand the problems they're solving. Because once you understand the problem, the technology starts to make a lot more sense.
And if the technology changes tomorrow, then the underlying problem probably hasn't.
Once I started thinking about learning in this way, I began looking at the systems I was already working on differently. I'd look at parts of the system and start questioning the decisions behind them.
Why did we choose this architecture?
Why did we split this code into separate services?
Why are we using microservices here?
What problem were we trying to solve when we made that decision? And perhaps more importantly: What could go wrong if we changed it?
A monolith isn't automatically bad because it's a monolith. Microservices aren't automatically good because they're distributed.
A container isn't inherently better than a Lambda service, and Lambda isn't inherently better than a container.
The interesting part is understanding Why one was chosen over the other.
Maybe there was a scalability requirement. Maybe there were deployment concerns. Maybe different parts of the system needed to scale independently. Or maybe the architecture grew organically, and nobody questioned some of the decisions made.
I think that is the kind of understanding I've been missing.
It's one thing to know how to build a feature; it's another to understand how that feature fits into a larger system, why the system was designed the way it was, and what consequences come with changing one of its pieces.
That's the direction I've decided I want to develop toward.
Not because I want to stop writing code myself, and not because I need to know every technology that exists.
I want to become better at making and evaluating engineering decisions.
I feel like I've just begun this journey, and there is still a lot I need to learn before I can answer the tough questions. And that is exactly why I want to start going deeper.