[drooby]

Writing. Code. Is. No. Longer. The. Bottleneck.

Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.

So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited.

Teams have not re-organized to match the new code-input velocity.

Engineers don't want to do QA because it's "beneath them".. and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.

[gwerbin]

Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?

[sanderjd]

There is some truth to this, but in practice I'm finding that yes, removing the writing code bottleneck has improved throughput quite a bit.

My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.

Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).

The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.

It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.

[jghn]

One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.

[sanderjd]

I disagree that it's not meaningfully speeding me up. I'm definitely doing a lot more, and more quickly. But the benefit is definitely smaller at the team and organization level, because we still have all the same serialization points - review, validation, decision making - downstream of my work.

[jghn]

I realized after I posted that it didn't quite capture what I meant. For instance if I'm able to do a more complex piece of work all at once in about the same amount of time as it'd previously take me to do a simpler piece of work, than that is a speedup. And that's what I am able to realize.

But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of my day to day work are the things you mentioned as being serialization points. The time I take to figure out what needs doing, what the best approach would be, making sure it was actually the right thing to have done in the first place once I'm done, all that stuff. I use AI assistance for those tasks too but it's not the same effect as when I just hand off the pure implementation phases. So it winds up being "faster" and you'll have to pry my AI assist tools out of my cold, dead fingers - but if I'm being honest with myself by *that* metric it's not a huge gain.

[sanderjd]

Yep totally agreed.

[orwin]

Depends on your company. I'd say very rarely, and never for long.

[adverbly]

This. Isn't. News.

People. Already. Know. This.

It hasn't been the bottleneck for decades for the majority of products.

[drooby]

I put a little too much weight on "the".. sorry..

Reality is that was A bottleneck. Code review has historically been faster than writing the code.

That is no longer true for me. I can complete two to three PRs per day in a span of time that would have historically taken one to three days.

I now sit around doing code reviews and asking for code reviews.

[skydhash]

> Engineers don't want to do QA because it's "beneath them"..

I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.

Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.

> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.

Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.

> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.

None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.

The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.

[orwin]

'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.

I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)

[llm_nerd]

Code has never been the bottleneck, and it was always an illusion that it was. I mean, programmers on the whole are a group that jerks around probably 95% of their time (this isn't an attack as I've spent my career as a software developer, and this included countless hours on Reddit, HN, Slashdot, and so on).