Live data from Hacker News

The bottleneck was never the code

thetypicalset.com

261–270 of 446 posts

Re: The bottleneck was never the code

#261

Code is a liability. I think it can be easy to look at code as an asset, but fundamentally it is a liability. Some of the "bottlenecks" to new code are in place to make sure that the yield outweighs the increased liability. Agents that produce more code faster are producing more liability faster. Much of the excitement and much of the skepticism about coding agents is about whether the immediate increased productivit…

> Code is a liability You're over-simplifying. Code in and of itself is neither an asset nor a liability. The minimal amount of code needed to solve business needs with no additional complexity is an asset with some maintenance liabilities attached (same as how a farmer's tractor is an asset that needs to be maintained), with depreciation if unmaintained (bitrot). Any code used to build unnecessary complexity is pure…

Yes, if code is only a liability then just delete the code and poof liability is gone.

Re: The bottleneck was never the code

#263

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…

Before, meetings (aka. coordination) bottlenecked the coding.

Even if coding was solved, meetings could still be the bottleneck.

You think spending more time on meetings is going to solve anything?

Re: The bottleneck was never the code

#264
post #226

Earlier quoted context omitted.

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 contr…

>I believe in A, I don't take a strong position on B

But if A and B are opposed, then there is a question of why a strong position on A can be allowed with a weak position on B, if the reason for the strong position on A would also indicate a strong position against B.

The underlying argument being implied (but rarely ever directly stated) is to question if your reason for the strong position on A is really the reason you state, or if that is just the reason that sounds good but not the real reason for your belief.

In effect, that you don't apply the stated reason to B despite it fitting is the counter argument to why it doesn't actually support A.

If there is an inconsistency in arguments being applied, any formal discussion falls apart and people effectively take up positions simply because they like them, contradictions irrelevant. This generally isn't a good outcome for public discourse.

Re: The bottleneck was never the code

#265
"What slows down a team where agents do the implementation is the production of specifications precise enough for an agent to pick up and run. Roadmap, written down. Acceptance criteria, written down. The “what we actually want” forced into precision, be it via a test suite, a ticket, or a written design."

This is merely speed of development and not the velocity of a company towards higher value. There are many PMs confidently (using the same AI tools), without a clear deep understanding of the user problems or why the requirements will be adopted by their target users (or even who the target users really are), writing these done elaborately.

So yes this will lead to faster end-end execution. But if the product is used or if it sits unused will depend on things beyond the above.

Re: The bottleneck was never the code

#266
Before going to work, we're fed algorithms and data structures and how they are the bottlenecks that makes wasteful use and here's how to utilize them; only to naively know from hard stories that the actual bottleneck is always from the people, the H-factor, except this time H stands for human.

Insane amount of bureaucracy, paperworks, and how we are missing deadlines so we write shit code that the quick and dirty solutions were never replaced.

Algorithms and data structures therefore are more like helping you utilize the machine economy better, but it doesn't have any meaningful impact on the social aspect of it. That's a hard lesson I had to learn from my two previous job, though now I'm considering starting my own small business just to make a little bit of living enough to survive.

But now my ADHD kicked in and is still lazy and I had so many concerns whether the market validation is great, how to deal with situations if I broke customers stuff, how to gain (and hopefully not regain) trust if any bad things ever happen, what if I want to go vacation and suddenly the server broke and got code zero (the highest level of alert I termed internally, when you had alertmanager flashing everything red, network storage is down, corruption happened) during a trip to Bahamas.

I'm still in the watershed of thinking really to do this or not, but the job market is filled with ghost jobs that are not worth my time either, I'm basically "dead locked" right now and had to make a decision quick.

Either choice is fucked for me, as I started to notice after going to work, despite I got some really interesting ideas in tech, but I'm not a charismatic person so I can't really make those idea to fruition, because no one wants to listen to me and implement it together, so I'm pretty sure it is impossible for me to be a great leader (tech lead probably, but CEO level of leadership and coordinator and manipulate the grand scheme of thing, nah, I pretty much can't do).

Now the problem is, even if I'm pretty sure to get fucked, you should choose the one that inflicts minimum pain to you. So far having my own business seems like a less painful to die and bankrupt, and I'm preparing to sell off some of my stuff to get a last dip of my fortunes and have fun. Will see how it looks. Bankruptcy is nothingburger in this modern society perhaps.

Now you see how the bottlenecks can't even be the code anymore and even goes beyond code, despite having the same core template: I don't even have to code, to repeat the same "quick and dirty" kind of mindset in another domain, in another instance. That's something LLM, heck not even AGI can solve: decision-making based on situations with limited time and resources, and it can be personal or organizational or even structural.

This is very much not going to be solvable by a bunch of lines and statements and expressions, but it really need some time to dig in and compromise. Pick your kool-aid and drink it

Re: The bottleneck was never the code

#267

Earlier quoted context omitted.

I doubt the GP has gone back through their career and checked on each person who thought there were too many meetings have now all made the switched they're being accused of, though.

Why does that matter?

Because a claim was made about a group of people.

Re: The bottleneck was never the code

#268

Earlier quoted context omitted.

The community portion that unironically think AI is good enough now, are mostly managers and non/semi-technical people, and engineers who do not engage in critical or complex problems. HN has always been too much of the velocity-alignment-synergy class of professional talkers; it's just so much more obvious now that they feel emboldened in false confidence.

There's some of that, but more often it's developers whose arguments are a year behind the frontier models or, just as common, they're dramatically overstating their abilities. It's an inherent tension that every discipline has to wrestle with. The most experienced developers are in the best position to evaluate where LLMs are, but those who are the loudest about their own abilities generally aren't in this camp. Hum…

Conversely there's a massive amount of money being thrown around biased in favor of inflating what LLMs can do compared to humans.

Re: The bottleneck was never the code

#269

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…

> 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), but still the total usage of that resource increases.

Why is this stated as a paradox? One simple cause is the given task being performed more than it was before because it is now cheaper (since it uses fewer resources).

Post reply on HN