The Silent Developer

I work alone most days.

No office. No colleagues popping over to ask if you've seen that weird bug in production. No one grabbing a coffee and accidentally explaining something you'd been struggling with for weeks.

Just me, a desk, and whatever's on Slack.

As an introvert, I want to be honest, a lot of the time, that's fine. Great, even. I get my head down, I focus, I don't have to perform being sociable when I'd rather just think. Remote work suits me in a lot of ways.

But there's a cost to it that I don't think gets talked about enough.

What you lose when there's no office

When I was earlier in my career, a huge amount of what I learned didn't come from documentation or tutorials. It came from sitting near people who were better than me.

Overhearing a senior dev grumble about why a certain approach was a bad idea. Watching someone refactor a messy bit of code and suddenly understanding why structure matters. Getting a PR review that said "this works, but have you thought about what happens when..." and then actually thinking about it.

That ambient knowledge transfer is real. And when you're remote, it's almost entirely gone.

You don't accidentally absorb how experienced developers think when you're not in the same room as any of them.

Communities help, but they're not the same

I work with Umbraco day to day, and one of the things I genuinely love about it is the community. The Our Umbraco forum is brilliant. If you're stuck on something, there's a good chance someone has already hit the same wall and written about it. If they haven't, post a question and people will actually try to help you.

I've been an Umbraco MVP since 2018 and that community is a real part of why I've stayed close to the ecosystem for so long.

But here's the thing.

Posting on a forum is not the same as spinning your chair around and asking the person behind you. When you're in an office and you're stuck, you can get unstuck in thirty seconds. Someone glances at your screen, spots the problem, says "oh, you're missing a semicolon" or "that's a known issue, do it this way instead" and you're moving again.

On the forum you write up the problem, wait for someone to see it, hope the question makes enough sense for someone to answer it usefully, and then wait again. Even in a great community, that's hours, not seconds. And in the meantime, you're either blocked or you've moved on and half-forgotten the context.

It's asynchronous help in a world where sometimes you just need someone to look at the thing right now.

Then AI showed up

And now there's another layer to this.

I use AI to help me code. I'm not going to pretend I don't, because I do, and so does pretty much everyone I know. It's genuinely useful. It speeds things up. It unblocks you when you're stuck on something stupid.

But I've noticed something.

When AI gives me a working answer, I don't always interrogate it the way I would if a colleague had written that code. There's something about it arriving clean and confident that makes it feel authoritative. And if I'm honest, sometimes I just... move on.

The thing is, I've got enough experience to know when something smells off. I can look at AI-generated code and feel that slight discomfort that tells me there's a better way to do this, or this is going to hurt us in three months. I've made enough mistakes to recognise the shape of a future one.

But what if you haven't?

AI doesn't stop at the code

It's not just the coding part anymore either.

Tools like GitKraken and GitHub Copilot can now look at your changes and write your commit messages and pull request descriptions for you. I've written about GitKraken before and genuinely think it's a great tool but when I was writing this, it got me thinking about some of the AI features.

Writing a commit message sounds like a chore. And yeah, sometimes it is. But it's also a tiny forced moment of reflection. You have to summarise what you actually did, which means you have to understand what you actually did. If you're fuzzy on it, the commit message will be fuzzy too, and that's usually a signal worth paying attention to.

Same with a PR description. Writing one properly, explaining what changed, why, and what to look out for when reviewing, it is a bit of a pain. But it's also the moment where you read back over your own work and either feel good about it or quietly realise you're not totally sure why you did something that way.

Hand that off to AI and you skip that moment entirely.

The code was written by AI. The commit was written by AI. The PR description was written by AI. At what point in that chain did you actually stop and think about what you were shipping?

The junior dev problem

This is the bit that actually worries me.

A junior developer, remote working, leaning on AI to get through tickets. No senior dev nearby to glance over and say "hold on, why are you doing it like that?". No one to ask "does this feel right to you?" and then actually explain why it doesn't.

They get working code. The tests pass (if there are tests). It ships.

But they haven't learned anything about why it works, whether it's a good approach, how it'll hold up at scale, or whether there was a simpler way to do it. And they have no baseline to compare it against, because they haven't written enough bad code themselves to recognise it yet.

That's usually how you learn what good code looks like. You write something, someone more experienced than you points out the problems, you feel briefly embarrassed, and then you never make that mistake in quite the same way again.

Remove the experienced person. Add AI that confidently generates mediocre-but-functional code. Remote-work the junior dev away from anyone who might catch it. Let the tooling write the commits too so there's no moment of pause anywhere in the process.

What's left?

I don't have a neat answer

I wish I could wrap this up with five tips for junior developers or a hot take about AI being bad, actually. But I don't think it's that simple.

AI isn't going away and remote work isn't going away. Both of those things are fine, genuinely. But I think we need to be more deliberate about what we're losing in the gaps.

If you're a junior dev reading this: be sceptical of the code AI gives you. Ask it why it did something that way. Push back on it. Ask it what the downsides of its own answer are. It'll tell you, if you ask. Write your own commit messages, at least for now. It sounds small but it keeps you in the habit of actually understanding what you just did. And find a community around the tech you work with — the forums, the Discords, the Slack groups. They're not instant, but the people in them are real and the answers are usually better.

And if you're a senior dev, remote or otherwise: the occasional code review where you actually explain your thinking rather than just approving and moving on is worth more than you probably realise right now.

The silent developer thing can work. But silence shouldn't mean learning stops.