Senior Developers — The World Owes You an Apology

Senior developers what a wild ride you have had.

I think the world owes you an apology.

For the last two years you've had to sit there and listen to people tell you that AI is going to replace you. You've had to sit through LinkedIn posts from people who've never deployed anything to production telling you that coding is dead. You've had to watch some guy with 400,000 followers build a to-do app in 4 minutes and declare that software engineering is over.

Meanwhile you're sitting there going "cool, what happens when two people edit the same to-do at the same time." And everyone looks at you like you've ruined the party.

You haven't ruined the party. You're the reason there's still a building to have the party in.

Not a Medium member? Keep reading for free by clicking here.

Let me tell you a story.

Imagine you've got a junior developer and a senior developer.

The junior developer has Cursor. The junior developer has Claude Code. The junior developer has GitHub Copilot. The junior developer has every AI tool known to mankind.

The senior developer also has all of those things too.

They both sit down on Monday morning. They both get the same ticket. "Build the integration with the payments API."

The junior developer finishes by lunch.

The senior developer finishes by lunch.

Wait what.

Yeah. They both finished at the same time. The code looks the same. The feature works. The demo is great. The project manager is thrilled. The client is happy.

Everyone goes to lunch.

This is the part where I'm supposed to tell you the senior developer's code was better right? More elegant and it has cleaner architecture and better variable names. You know, those 'senior' things.

For the sake of argument, let's say that the code was basically the same and that the AI wrote most of it for both of them. So if you went through it, it actually looks identical.

So what's the difference.

Well I am finding that senior developers do something quite interesting. It usually happens after lunch.

The junior developer comes back and picks up the next ticket. Like little keen legends. They are productivity machines! Smashing through the backlog like Pac-Man.

The senior developer gets back from lunch and sometimes you will see them just sitting there. Staring at the screen. Not writing any code. Just… sitting. Thinking. Looking like they are doing nothing. Looking like they are having an existential crisis about their career choices. Looking like they are buffering.

Then the senior developer started asking annoying questions.

"What happens when the API goes down."

"How does the Clerk Documentation actually work?"

"How would I break this system?"

"Is this really an efficient way to do what I have done?"

"What happens on daylight savings."

Daylight savings! Who thinks about daylight savings! This person is insane. This person needs a hobby. This person is worried about clocks changing in October when we're trying to ship a feature in February.

Then the senior developer writes tests. Lots of tests. Tests for things that haven't happened. Tests for things that might never happen. Tests for things that sound made up.

The senior developer also just seems to use the system more. Sure the rate of output might be a bit slower, but I'm beginning to get this idea that you want a methodical rate of shipping, not a maniacal rate of Pac-man shipping.

The senior developer also seems to just read the documentation more. You know those instruction manuals that coding has that tell you how things work. Yeah it turns out senior developers just seem to read them way more.

But that's boring! Why do all of that stuff when you can just get Cursor to jam in agent mode.

Back to the junior developer.

The junior developer has picked up three more tickets by now. The junior developer is a machine. The project manager loves the junior developer. The velocity chart looks incredible.

The senior developer has mass produced zero new features. The senior developer has mass produced paranoia. The project manager is starting to wonder if the senior developer is OK.

But.

This is really important point.

The senior developers tools don't break. For all of this mass hysteria out there about AI meaning you don't need developers, it is just absolute codswallop. This is why senior developers need an apology. You know they aren't being annoying? You know they are actually just really good at their job. I've just been reflecting on our last 12 months since AI has been invented and all the products that my senior engineers have built just haven't broken. Like at all. I have never had a call. Not a 2am call, not a call at 6pm, not a Sunday, never. Their systems work. I usually just get happy calls from our clients that their systems just work. It doesn't make a flashy headline or LinkedIn Post "Senior engineer creates extremely reliable system that doesn't break" but honestly, it's an absolute vibe.

This is a new trait that I am really rating about senior developers right now. You hear the frustration of senior developers in the comments on Medium. They will often critique things for various reasons. They will complain about the downsides of things. They will complain about where AI falls short.

Do you want to know a big secret? They are right. Do you know how the senior developers prove it to you?

Because in an age of AI and hype and silliness, their systems work. They keep working. They are stable. They work over a year.

Do you know how insanely good a senior developer, with their level of paranoia is, combined with AI? If they are working on something for 2 weeks, it's 2 weeks and done and basically never worry about that thing again.

Junior developers it feels like 2 weeks + 1 week + half a day + 4 hours + 2 hours. That's also scattered over 3 months. It's like one of those horror movies where at any time, the killer could appear behind a doorway.

Things break for all sorts of reasons. This post isn't to throw shade at junior developers, heck I myself have so much to learn, but I feel the pendulum has swung so much to the generative side these days, that we run the risk of overbearing on the people that understand how everything actually works.

I think AI has shortchanged the learning curve in a way. When you have this new layer of abstraction you introduce this problem where you have massive blindspots. You don't know what you don't know.

That's why I don't buy the argument that you don't need to learn the fundamentals of coding. You need a base and a mental model so that you can apply it to your system when things go wrong.

But hey this is a team sport and I run a company and so we have been doing Friday sessions where we try to get the senior developers to help train the junior developers and share lessons that they have learned. I thought I would share what they have said here as they have been really valuable. It's turning into my favourite time of the week.

Testing is the thing that comes up the most. That and they deeply care about the core architecture. They are pedantic. But the key thing I notice when I peek at senior developers desks is that they are using the product more. They are just always using it! Like logging in. Refreshing. Again it's weird because I don't know how to say this, but it kind of feels slow? But it's not. They are just like surgeons.

It's not shipping things and moving on. Also, if I give them a task, there is a lot of …. not coding. There is a lot of thinking. There is a lot of planning.

They also talk about periods of growing the system and then period of pausing and learning. You can't just build build build new features all the time. They have time when they take stock of what they have done. Again, that old testing thing. Who knew? If you use the system a lot and pedantically try to find ways to break it, you make a more reliable system.

A way they recommended to practice is that build 2 new pages, a list screen and a details screen and then you sit with that. Go and read the code. Maybe use ask mode, get the AI to explain what is going on. Get the AI to critique your work. But that's basically the method that you need to practice.

Build a feature, test a feature, sit with the feature, think about the feature.

Or one thing we are encouraging our developers to do is a certification. So we use a lot of AWS at our work. One way is to just get Cursor to help you with AWS and do all the commands for you. The other way that is slower is to go and actually run through a video of how the AWS systems work. It's slow work. I think it's critically important though. In fact we are introducing periods of slow work on purpose as this old manual methodical stuff is what builds reliability. Sure it is harder, but you actually learn things.

Here's another one. Go and break something on purpose.

I'm serious. Set up a test environment and just start breaking things. Turn off the database. Send a request with no data. Send a request with way too much data. Put an emoji where a phone number should go. Part of learning to code is learning to deal with randomness. Humans are random. When they use your system, they do random things. You learn a lot by trying to destroy your own system. Maybe ask Cursor to pretend to be a hacker and see what it would do. That could be quite fun.

Read the error logs. I know. I know. Nobody wants to read error logs. Error logs are the terms and conditions of software development. Everyone scrolls past them.

But here's the thing. Your system is literally telling you what's wrong. It's writing you letters. Every single day. "Hey, this thing timed out." "Hey, this thing returned null and nobody handled it." "Hey, someone tried to put their entire life story into a field that only takes 50 characters."

Your system is crying for help and you're over there picking up the next Jira ticket.

Spend 15 minutes a day reading your error logs. Just 15 minutes. You will find things that terrify you. You will find things that have been quietly failing for weeks that nobody noticed. Try this once a day instead of just pasting it into Cursor and Alt Tabbing to a YouTube video.

Pair with someone who annoys you in code reviews.

You know the person. The one who leaves 14 comments on your pull request. The one who asks "what about the edge case where…" and you want to scream because it works fine and why are they like this.

That person is your best teacher right now.

Sit next to them for a day. Watch how they think. Watch what they do after the feature works. I guarantee you they have a mental checklist they run through every single time. They probably don't even realise they have it. It's just how their brain works. Move to your opposite personality type. You will learn a lot from them. Every time I do this, I always learn something new.

Keep a "things that went wrong" journal.

Every time something breaks. Every time there's a bug. Every time someone finds an issue. Write it down. One line. What happened and why.

After six months you'll have this incredible document. And you'll notice patterns. The same kinds of things keep breaking. The same assumptions keep being wrong. The same edge cases keep showing up.

That document is basically a senior developer's brain in written form. Senior developers have this document too. They just keep it in their head because it's been accumulating for ten years through pain and Thursday nights and client emails with exclamation marks.

I think its such an exciting time to be a coder right now and if you are a junior, you have an AI with freaken ask mode at your fingertips. I'm not saying that a junior developer can't catapult and be an incredible force to be reckoned with but pick the brains of the senior developers. Be a sponge and soak up as much as you can.

The exciting part is that this is not a hierarchy, it is a progression. Junior developers bring energy, curiosity, and a willingness to move. Senior developers bring pattern recognition, restraint, and responsibility. AI amplifies both. The future does not belong to one over the other; it belongs to TEAMS where speed is paired with judgment, where curiosity is paired with memory, and where experience is shared instead of hoarded.

But in the meantime, sorry senior developers, you were right. Thanks for making my systems work.

Before you go

Subscribe to my free Substack newsletter because you get the following:

• A brand-new article for executives on Sunday that's only posted on Substack.
• Links to every Medium post I've written in the past week
• Book recommendations every week for you to spend your Audible credits on

If you are a senior developer with any other tips, help out your fellow junior developers. What would you do if you were starting again today?