this post was submitted on 19 Jul 2026
9 points (61.0% liked)

Programming

27769 readers
306 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
9
The Bosses Are Coding Again (blog.herlein.com)
submitted 1 day ago by codeinabox@programming.dev to c/programming@programming.dev
24 comments fedilink hide all child comments
 

Somewhere in the last year, a bunch of us who hadn’t shipped real code in years quietly started shipping again. Not reviewing it. Not architecting it in a doc and handing it off. Actually building it. And loving it.

I lead software for a living. That means my days are meetings, roadmaps, hiring, unblocking people, and saying “no” a lot. The last time “writing code” was my actual job was a long time ago. I never stopped being able to code — I stopped having the time to code. At least in my day job. There’s a difference, and every engineering leader reading this feels it in their bones.

top 24 comments
sorted by: hot top controversial new old
[–] tatterdemalion@programming.dev 31 points 22 hours ago (2 children)

If you identify with this post and you are in a manager position, please heed my warning. Throw away your prototypes. Stop vibing "quick fixes to unblock me". Stop trying to help your devs because you think you're superman now. You are only pissing everyone off, I promise. The devs who didn't stop coding while you were off doing important manager/product stuff are the ones who understand what's best for the codebase. And yes, they also know how to use LLMs.

Just because you feel like you have a new superpower doesn't mean that everyone needs to be saved. Follow the damn engineering process.

[–] onlinepersona@programming.dev 4 points 18 hours ago

100%

I got this my superior who decided AI allowed them to code fixes and we were stuck with buggy code that wasn't merged, because the superior had moved on to a more important task requiring more AI "support" and couldn't process the comments. Things could've been faster had we implemented things ourselves.

When you aren't out in the fields dealing with stuff, you don't know what's important to the workers. "Jumping in" for a minute to do a task might actually slow down the team if understanding of day to day struggles isn't present.

[–] MagicShel@lemmy.zip 3 points 20 hours ago

I'm contributing story execution. And my goal is to contribute like any other team member. My code gets reviewed. Harshly because I don't know all the norms for this code base. And honestly it's great because to be a technical lead I feel like I should know the code way better than I've had time to.

[–] arran4@aussie.zone 3 points 16 hours ago

Weather or not this is good or not wildly depends on who the person is and what the situation is. The article seems rather self aware.

[–] resipsaloquitur@lemmy.cafe 44 points 1 day ago (4 children)

Great. The "why don't you just.." idiots are "writing" code again and not reviewing it.

What could go wrong?

[–] squaresinger@lemmy.world 17 points 1 day ago (2 children)

Who needs human review, the AI can do that? Who needs human coding, the AI can do that? Who needs human testing, the AI can do that? Who needs human requirements engineering, the AI can do that.

80% uptime. How did this happen?

[–] ICastFist@programming.dev 2 points 5 hours ago

The AI agents need to sleep, too, so the downtime is expected

[–] resipsaloquitur@lemmy.cafe 19 points 1 day ago

Still five nines of uptime — 79.9999%.

[–] trem@lemmy.blahaj.zone 15 points 1 day ago (1 children)

Yeah, I thought the blog post was gonna be about horror stories, because even the greatest senior/architect/whatever will push absolute garbage into your codebase, if they don't have the time to familiarize themselves with how the code actually works.

Even if it's some isolated component, if they implement it without explaining the what and why to others, then no one else can maintain or debug that. And you do not want to rely on your super important guy to have the time to fix things when production grinds to a halt.

[–] adhocfungus@midwest.social 11 points 1 day ago (1 children)

At this point I think we're moving past maintaining projects. Tech debt is no longer going to be paid off; management will just suggest a complete rewrite using AI as soon as issues get too complex for a junior dev with Copilot to figure out. It's going to be a mess.

[–] elvith@feddit.org 6 points 1 day ago

I ~~feel~~ fear the same. Problem is, when it's too complex to maintain for a junior dev/intern with AI, it's probably also too complex for a rewrite/redesign with AI...

[–] pHr34kY@lemmy.world 0 points 18 hours ago* (last edited 18 hours ago)

I don't mind writing code and having copilot review it. I can tell a clanker to fuck off in satisfying ways that I couldn't with a junior dev.

...and there's the one time in 10 when it sees something and I can make a minor improvement.

Still, the "Oh crap, my code actually is broken" monents are few and far between.

[–] codeinabox@programming.dev -4 points 23 hours ago (1 children)

Could you qualify what you mean by "idiots"? The author and the examples he gives - Kent Beck, David Heinemeier Hansson, and Garry Tan - are all very experienced software engineers.

[–] resipsaloquitur@lemmy.cafe 3 points 21 hours ago (1 children)

By idiots I mean the people who haven’t engineered in years.

The subject of the article.

Seems self-evident.

[–] codeinabox@programming.dev -4 points 20 hours ago (1 children)

Well that depends on how quickly you believe that engineering skills atrophy without use.

Though, I'd argue programming is like riding a bike. Even after a long break, it's not difficult to get back into it, as the fundamentals for programming haven't changed.

[–] resipsaloquitur@lemmy.cafe 2 points 20 hours ago

If they’ve stopped engineering, then they probably weren’t good in the first place, what skills they had are rusty, and their knowledge is out of date.

I’d argue programming languages are like natural languages. Use it or lose it.

[–] Sanctus@anarchist.nexus 13 points 22 hours ago

Writing code was never the bottleneck. This didnt make it easier. It just made it faster, people already ignored the output when engineers made it.

[–] squaresinger@lemmy.world 11 points 23 hours ago (2 children)

Reminds me of that one time when Microsoft said "We don't need UI/UX designers, powerpoint is so easy that managers can do UI/UX design themselves".

That's how we got Windows 8.

[–] ICastFist@programming.dev 1 points 5 hours ago

Most of the problem with 8 was M$ insisting that desktop computers should get the mobile UI treatment because "we're totally going with phones now so fuck you"

Them proceeding to completely fail at the mobile market was no surprise.

[–] MachineFab812@discuss.tchncs.de 2 points 20 hours ago (1 children)

... Windows 11 is far worse. 8 was solid compared to 11. 8 was a pain in the ass, but it mostly did what it was supposed-to.

[–] squaresinger@lemmy.world 1 points 8 hours ago

What does being technically solid have to do with UX?

[–] originalucifer@moist.catsweat.com 10 points 1 day ago

An agent handed to someone who doesn’t know what they want produces a confident pile of plausible nonsense. Fast. The same agent handed to someone who knows exactly the shape of the solution and can smell when it’s drifting? That’s the mech suit. That’s the leverage.

yesssssss

[–] stsquad@lemmy.ml 6 points 1 day ago

I've long been off the critical path because as a tech lead I have a lot more random stuff (and meetings) to deal with. I've been able to vibe code some non-production stuff like scripts to unify feature lists across JIRA, specs and the upstream docs which has helped free up time to hand craft more code on production.

I don't care too much about the quality or maintainability of those scripts as long as they make my life a bit easier. I do care about the maintainability of the production code base.

[–] MagicShel@lemmy.zip 4 points 1 day ago

Agreed. This is my experience exactly, though I really only took a break from production code for about a year. It feels really good.