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

431–440 of 446 posts

Re: The bottleneck was never the code

#431

Post by i_think_so »

longevitygreenl wrote: post #403

36 years in, solo founder now, and this matches what I'm living. The code stopped being the bottleneck a while ago — Codex and Claude ship features faster than I can decide which features are worth shipping. The Jevons Paradox point lands hard: I have to actively resist building things just because I now can in an afternoon. Solo doesn't escape the coherence problem either, it just turns it into a fight with my past…

Just wanted to say hello and encourage you to share your perspective. I saw that you got flagged on your second ever comment (possibly because it sounded like your first). Unfortunately, there are some very itchy trigger fingers here when it comes to shooting down AI slop. Surviving long enough to get a few karma points and not be treated like a bot was much harder than I expected, so I want to toss you an upvote and thanks in advance for sticking with it.

I wish I could give you good, brief advice on how to avoid getting downvoted to death before you even get started. There are undoubtedly others who would do a better job. So I'll just say "try really hard not to appear like ChatGPT write your post."

Everything imaginable is being impacted by AI, in expected and in surprising ways. Communities are going to need to put extra effort into things that used to just happen, like welcoming new members. Here's mine.

(I hope I'm not wrong and that you're not actually a spammer. But I think my bet is safe enough. :-)

Re: The bottleneck was never the code

#432

Post by roenxi »

abduhl wrote: post #171
roenxi wrote: post #44

Earlier quoted context omitted.

Old value: Producing high value software. How to do it? Focus on writing code. New value: Producing high value software. How to do it? Focus on writing specs for code / identifying needs. I expect there are a lot of hypocrites in the mix, scared for their job. But this isn't a fundamentally hypocritical position - agents are changing the game for how software gets produced and the things that were important as recent…

This is shifting the principle/value discussion up to a level where it's meaningless. Let's use a different example. Old value: Returning value to shareholders. How to do it? Treat your employees like family and don't be evil. New value: Returning value to shareholders. How to do it? Treat your employees like human resources and get away with what you can get away with. Is this hypocritical? Most people would say yes…

> Is this hypocritical? Most people would say yes, but in your framing it's not because we've backed up to the least specific articulation of an underlying principle. It's a species of the motte and bailey fallacy.

I'm happy to defend that one too, for the reasons you outline. It is completely normal behaviour from a company, everyone understands it [0] and most managers I've worked with would be happy to talk about it openly. It isn't hypocritical. It'd be hypocritical to pretend that there was some sort of long-term commitment in an employment relation, but that isn't implied in your example.

Changing your behaviour when the situation changes isn't hypocrisy. That is just being aware of the conditions around you. Hypocrisy is pretending your behaviour is principles based, then clearly not following the principles. To show hypocrisy, you have to do two things (1) show people claimed to be following a principles and (2) show that they are not following it. In your scenario, you haven't identified a principle that people are being inconsistent with.

I note you threw in a "don't be evil", so maybe you're thinking of Google. Google is hypocritical, because it claimed to be acting on principles ("don't be evil") and then didn't follow them when it became inconvenient. But if it'd just been honest up front that it was a normal business and would act responsibly to maximise profit it could have undertaken exactly the same actions and not been hypocritical. It was the professing of principle in advance that made the hypocrisy, not the action. Claiming to "not be evil" is unusual for companies, because while they are immoral they usually only lie when it is detectable that it is to their benefit and they're usually just cynical, not hypocritical.

[0] "should" understand it, I suppose. One born every minute.

Re: The bottleneck was never the code

#433

Post by ftmootnomoat »

ryandrake wrote: post #160
xquce wrote: post #101

Earlier quoted context omitted.

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…

> I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case! I think a lot of HN truly believes that Software Developer is the only important role at their company. Software goes straight from the developer's brain, through his fingertips into the computer, and then on to the online store (run by nobody)…

There's a reason why startups always begin with a software guy/gal and a sales guy/gal.

It all begins with a product and a sale. That's how you go from zero to one.

Then if you're lucky enough to become an organization and start to have organisational problems you hire HR, accountants, lawyers, and managers.

But there will always be a dichotomy between core and auxilliary roles.

A coder and a salesman can create something out of nothing. We create the garden and those who come after tend to it.

Tech companies who grow large and old enough to forget that product and sales are the bedrock on which everything else stands decay and die.

Re: The bottleneck was never the code

#434

Post by fao_ »

devonkim wrote: post #408
fao_ wrote: post #356

Earlier quoted context omitted.

I don't think that this is very hypocritical on the part of the developer holding such views. Typing code has never been the bottleneck, building the mental model has. You need the mental model so you know how the domain and the actual model will interact, which is needed for pre-empting what tests you need, what QA you need to do, etc etc. and the limitations of the system. You can demo this out with a specification…

One of the core problems we have in software engineering is the longstanding philosophical problem around creation of cohesive, consistent, objective mental models of inherently subjective concepts like identifying a person, place, etc. Look at the endless lists of falsehoods programmers (tend to) believe about any topic. You’re right that LLMs specifically have no guarantees about accuracy nor veracity of the text t…

> but I posit that that’s the same with people,

> The difference is in the kind of errors machines make compared to ones that humans make.

There's another difference, and that is that other humans can learn and study that mental model (which is why "readable code" is a goal — the code is a physical manifestation of the model that you, the programmer, has to learn), and then the model can be tweaked and taught back to the original programmer, who can then think of that tweak in the future. Programming is inherently (in most cases) a collaborative art, because you're working with people to collectively develop a mental model and refine it, smoothing it down until (as Christopher Alexander said) there are no misfits between the model and the domain.

Re: The bottleneck was never the code

#435

Post by andrewingram »

trjordan wrote: post #296

Yes, but: writing code always teaches you something. I've worked at founder-sized startups and $xxb dollar public companies. I've never read a product spec, a pitch deck, or a PRD that describes a solution that, if implemented in the way described, would solve the problem. Building the thing teaches you how it should behave. Software is a complex, interactive medium. Iterating in the code, with people who understand…

As they say (they being me), no design survives implementation.

Re: The bottleneck was never the code

#436

Post by pdimitar »

locknitpicker wrote: post #375
nilirl wrote: post #255

Earlier quoted context omitted.

I was not merely stating other bottlenecks. I'm saying they're more important bottlenecks. They can't all be equally important bottlenecks; a bottleneck is by definition a singular component or sub-system most-limiting to the system's output. What are we trying to output from our businesses? Code? What is this magical context floating around every business that will unlock AI agents to produce ... what? [Edit] I apol…

> I was not merely stating other bottlenecks. I'm saying they're more important bottlenecks. This is a pointless statement though. The fact that writing code is a bottleneck, and a critical one, doesn't mean it's the only thing standing between us and fixing/implementing something. It's like downplaying the time taken by international flights, because people can spend time passing through security. The truth of the m…

> Now code is ceasing to become a bottleneck and the current software dev process starts to emerge as inadequate

If you say so. It's a honeymoon period for executives and a lot of them already got a lot of cold showers. It's just a very uncomfortable topic but it is already happening. Maybe not in your org but I am seeing it already.

I am not against the new reality even if it were to solidify (which it will not; productivity gains as sold are illusory and plateau VERY quickly; we're talking days -- and contrary to what many on HN believe, not all work is pitch decks and rapid prototypes).

I really like the acceleration and removal of dumb grunt work. I love it. But the current LLMs, even Codex and Opus, _are_ doing dumb stuff even on max effort still. People get hyped up and overshoot as they always do.

It must be said that I've used Opus for some pretty high-level and high-quality architectural work and it did very well -- but it took a lot of effort and steering, leaving me questioning whether I wouldn't have the done planning and scoping better and quicker.

Frontier LLMs do very well but people give them too much credit IMO.

Re: The bottleneck was never the code

#437

Post by RaftPeople »

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…

Both things can be true at the same time:

1-There is significant collaboration and action required beyond just coding to successfully create+implement software systems

2-When performing the coding step, minimal interruptions are vastly more efficient than working in little chunks of time

Re: The bottleneck was never the code

#439

Post by kadhirvelm »

doitLP wrote: post #177
kadhirvelm wrote: post #151

Totally agree, we wrote our own piece similar to this: https://productnow.ai/blogs/teams-that-coordinate I really think as code becomes cheap, misalignment between people, teams, and organizations is going to hurt a lot more, especially when everyone is trying to move at break neck speeds. I also think a big piece of this is human attention and inertia. Aka, why bother doing the hard work to coordinate with others wh…

“Something went wrong with the editor” when loading page

Whoop sorry, should be back now

Re: The bottleneck was never the code

#440

Post by aspenmartin »

jugg1es wrote: post #318
aspenmartin wrote: post #271

Earlier quoted context omitted.

- systemic tech debt is now addressable at scale with LLMs. Future models will be good enough to sustain this, if people don’t believe this I would challenge them to explain why. First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally - I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself…

The problem with tech debt is not that it is some poorly designed code in a few repositories that can just be changed. True tech debt is the kind that requires significant architectural changes across many systems and is almost always coupled with major data migrations. You need the rest of the business to agree that you want to invest all that time and energy to fix a problem someone else created 10 years ago. You l…

> You likely will also need other teams to set aside time on their own road map to address it.

This is the part that’s no longer true. Everything else you said is spot on. But everything you mentioned — making sound decisions in the vast context of the business and enormously complex codebase, dealing with ambiguity and customer implications. None of this is inherently untouchable by AI

Post reply on HN