Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The bottleneck was never the code

thetypicalset.com

Post reply on HN
Print view View original

221–230 of 446 posts

Re: The bottleneck was never the code

#221

Post by corysama »

TheLudd wrote: post #107
paldepind2 wrote: post #100

From the article: > Jevons Paradox: when something gets cheaper, you tend to use more of it, not less. That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper. What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), bu…

Should the paradox not be that we PAY more for it? Or, if some process is made more effective, i.e. takes shorter time, we spend more time in that process.

The paradox is usually presented as:

The People: Hey local government! The roads are so packed with cars they are useless. Fix it!

The Government: We hear you and just finished a huge road expansion project. The roads now have 2x the capacity! Enjoy the new fast roads!

The People: The roads are just as slow as before because they are packed with 2X as many cars now!

So, the paradox is that greatly increasing the capacity of the roads led to the roads being just as slow as before. Maybe even slower. This is because there previously were lots of potential uses of the roads that people did not enact because it would not have been worth the hassle. But, now with 2X the capacity, those uses become viable. So, more people find more uses of the roads up until it gets right back to the limit of everyone patience.

Apply this to coding and you can predict: Coding is much faster and easier now. So, why are all my coders still so busy?

Re: The bottleneck was never the code

#222

Post by syndacks »

nayroclade wrote: post #15

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

The archetype of the "jerk engineer" is over, because it turns out coding isn't all that valuable anymore. We now need "engineers" who understand much more than coding.

Re: The bottleneck was never the code

#224

Post by locknitpicker »

nilirl wrote: post #11

Bottleneck for what? More features? I don't think amount of software is what determines whether a company does well. I don't think capturing quantity of context is that important either. Now, quality of context. How well do the humans reason? Then, attitude. How well do the humans respond to bad situations? Then, resource management. How well does the company treat people and money? Finally, luck. How much of the unc…

> Bottleneck for what? More features?

Code changes. Not necessarily features, but also bug fixes, plain old maintenance, and even refactoring to improve testability.

With AI coding assistants, what in the past were considered junior dev tasks are now implemented with a quick prompt and an agent working in the background.

These junior dev tasks are now effortlessly delivered by coding assistants, with barely any human intervention. Backlogs are cleared faster than new items are added. And new items are added more and more because capacity to clear them is no longer an issue. The challenge is now keeping up with the volume of changes. I see this first-hand at my org.

> Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.

Just because you can think of other bottlenecks that doesn't mean that generating code was not a bottleneck, and is not the bottleneck today. The mere notion of a backlog demonstrates that it is a bottleneck.

Re: The bottleneck was never the code

#225

Post by nibab »

the tediousness of keeping documentation up to date and the natural tendency towards small attention spans has always come up as a tax on organizational efficiency: complicated org structures, legibility exercises, communication tollgates etc. there is real value in reducing the friction in the former so that the latter becomes less of a burden.

at the same time, context poisoning is a real cognitive problem for humans too and I can't tell you the number of times I've seen irrelevant details become a drag on execution. my fear is that having too much context will only cause bikeshedding and a revisiting of prior decisions.

frankly, our organizational structures were already pretty good at creating mechanisms for eliciting the right implicit context at large scales. it is possible that we're just going to come up with the same mechanisms from first principles...

Re: The bottleneck was never the code

#226

Post by plorg »

SkyBelow wrote: post #109
knollimar wrote: post #54

Earlier quoted context omitted.

Or just goomba fallacy

Sometimes there are two groups of people who have different opinions that don't interact, but given the extent they take up the same platform and don't seem to see each other, I'm not sure it is really a fallacy even then. First, it becomes possible for people who have a double standard to hide behind this. One can try to track an individual's stance, but a lot of internet etiquette seems to be based on the idea of n…

I believe in A, I don't take a strong position on B, I am in coalition with people who believe in B and don't take a strong position on A, we both believe in C, D, E, and F, which some other people believe in with differing weights. Browbeating me about position B (or, the most useless kind of Internet banter, complaining about me and my hypocritical position on A+B to your friends who oppose both in a likewise contradictory way, in some venue I've never heard of) is not about making people reevaluate positions, it's about negative factionalism. The only reason it might not fit the familiar categorization of "fallacy" is that you would never use it in rational debate, either in arguing with another person or in reasoning out your own position.

Re: The bottleneck was never the code

#227

Post by morelandjs »

nayroclade wrote: post #15

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

I understand your sentiment, and there’s absolutely some truth to it, but I don’t think the path forward is throwing more management resources (or layers) at the problem. And I don’t think the management technology industry is the answer either.

I think the solution will be small (1-5 person) teams where product and engineering sit next to each other and have clear authorization to launch directly to prod at their discretion. The gripes about performative work tracking mechanisms and the realization that non-tech considerations are now the bottle neck are not mutually incompatible.

Re: The bottleneck was never the code

#228

Post by ngc248 »

ap99 wrote: post #92
kenforthewin wrote: post #31

Earlier quoted context omitted.

Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?

Is it even a problem that so called goal posts are moved? That's life. Life changes and us along with it. "Who Moved My Cheese?"

Exactly goalposts need to keep moving

Re: The bottleneck was never the code

#229

Post by bcooke »

palmotea wrote: post #214
nayroclade wrote: post #15

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

I'm not going to comment on the likely "Goomba fallacy" at work in your comment, but I just want to note: > team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews Are frequently not: > [important] collaborative activities I've always been someone who disliked distractions from my "coding 'flow state' they claimed as their most essential and sacred activity to be protected at all cost…

> (because, you know, I was getting paid to write code and that's the only way I could actually get it done)

I'm going to assume you were getting paid to build software that solved problems and created value for your customers and stakeholders. Writing code has always been just one activity that's part of the job, and developers forget that and make statements like this! That's the parent poster's point. I'm not saying it's not an extremely important part of the job, or that people don't often collaborate poorly in ways that take away from the sacred deep work time, but framing it as "I get paid to do X and not Y" is just a highly limiting way to look at or talk about the role.

Re: The bottleneck was never the code

#230

Post by [deleted] »

xquce wrote: post #101
ftmootnomoat wrote: post #26

Earlier quoted context omitted.

This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better). Meetings that increases sync between customer and coder are few and precious. In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to a…

Not a false dichotomy. I agree with OP and I can say for certain that if you are one of the few developers that is "fond of meetings with customers" you are not the the type of person OP is talking about, and you are more rare than you think. I am a former Dev turned PO/PM and now CEO, I can tell you many a developers are not fond of those meetings you are fond of and people like myself don't insert our selves where…

[deleted]
Post reply on HN