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 2 hours ago | parent | next [-]

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

	▲	jghn 2 hours ago \| parent \| next [-]
		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.
	▲	orwin an hour ago \| parent \| prev [-]
		Depends on your company. I'd say very rarely, and never for long.

▲

adverbly 2 hours ago | parent | prev | next [-]

This. Isn't. News.

People. Already. Know. This.

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

▲

llm_nerd 2 hours ago | parent | prev | next [-]

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).

▲

skydhash an hour ago | parent | prev [-]

> 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 an hour ago \| parent [-]
		'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)