Hacker News Reader

Comment by marginalia_nu | Hacker News Reader

Code was very rarely the bottleneck in the first place.

If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers would have instead mostly been thinking and programming.

We've always had the ability to 2X if not 10X the output of each and every one of those poor souls. You don't end with this sort of programming purgatory because it's a productivity optimum, it very clearly isn't, but because it's a billable hours optimum and/or an org chart clout optimum and/or because of Jevons paradox got hands even in business management and the IT department was allocated too many dollars.

View on HN

> Code was very rarely the bottleneck in the first place.

I disagree. Kinda

What AI has made much simpler is that you don't have to waste time checking docs and have the best autocomplete system by a long shot - this was a bottleneck unless you were doing Java or some other language with "perfect" AC

What AI made "kinda easier": solving for usual problems. The stuff you would search Stack Overflow, or think a couple of minutes for an optimized solution - not a bottleneck but not 100% smooth neither

You still have to test and validate your code. AI made this easier-ish but this is still where I see manual work being needed (even if you are automating tests - you still have to think on what you want the code to do)

I disagree. Coordinating 100 folks to align on a problems statement with "agile" and sprints was always the biggest bottleneck. Difference in opinion, internal politics is always a bottleneck.

I think now, code is the bottleneck. Just because you can generate million lines of code, people with different skill level think they are accomplishing the task, testing, merge conflicts, trust has become the bottleneck.

A pattern I have seen:

The “old way” would be lots of debate (both bike shedding and useful) among engineers during design phase, and then you’d implement.

Now it’s shifted so there are no design docs and there is only the generated prototype. People trying to do their design review while there’s already a functional-ish prototype and it goes nowhere. There’s an anchoring effect in place because the first thing already exists and management says “this seems to work, just use it and move on”. The result is that useful debates about substantive issues don’t happen and bikeshedding is all way get to do

This is so accurate. I am a fairly senior individual contributor and its been more than a year since I saw a good design doc or quality design discussion. Before you can even question the design, someone has generated a 50k line prototype and already made up their mind because of all the “you’re absolutely right..” and “X is exactly what you need..” from AI.

This very much. First thing built is what get approved. Even if it will generate 10x the workload down the line, because today's quality bar is very much demo level.

And then you get paged at 2am because prod is down and the support channel is more active than the team's one.

"Talk is cheap, show me the code"

A working prototype beats endless discussions over paper

Talk is cheap, that's why you do it before sinking months of man-effort into building a turd.

This. Exactly this. Most ideas are bad ideas. Now noone can stop all of them from being sent to prod for everyone to deal with.

A working prototype like that is good if the debate is “is this possible?”, the problem above is more for problems where it’s possible and we’re arguing which path to take

The distance between substantive issues vs bikeshed sized issues is non-linear and ill-defined. Sometimes: yeah, we're just bikeshedding. Other times, it's important to suss out unshared implied context that doesn't match between various stakeholders and will have outsized ramifications later. What's new is the speed of executing changes. If there was no substantive debate about what programming language to even use so everyone is equally happy (read: sad), so what? Have the LLM rewrite the entire project in another language over the span of a couple of days after that discussion is had because the language used has specific shortcomings that have been unmined.

This just says that we can output code faster. I'm saying that the rate at which we output code wasn't the thing that was slowing down development. We've always been able to increase that even without AI by adjusting the working environment and removing obstacles to programming.

In larger organizations, quite often it's the business that is holding back development. They can only handle so much change and speed needs direction to be velocity. Drafting requirements is generally much slower than implementing them.

Like the number one complaint from programmers has been that they don't get to do programming. They want to write code, not update jiras or spend hours in meetings.

But searching on google or SO wasn’t the bottleneck either. It was searching on your own codebase (and dependant ones) for the exact place (a class, a file, a function) where to put/delete/update business logic without breaking production.

LLMs help, but they haven’t been trained on our own repos. I don’t need the LLM to help me with algos that are available online… I need them to help me with custom business logic

Reply on news.ycombinator.com