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

371–380 of 446 posts

Re: The bottleneck was never the code

#371

Post by chanux »

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…

An important thing can (and one may argue will) be overdone AND hvlfvssed stealing oxygen from another important thing.

While I'm glad you posted this point of view/framing which honestly needs highlighting in the name of a better discussion, I must remind that the moaning back then was for the ceremony stealing time from building.

Re: The bottleneck was never the code

#373

Post by k1w1 »

It makes me wonder if remote-first companies will have an advantage in an AI-first world because they must be more intentional about communication. By their very nature remote teams use more written communication and more intentional, and documented, processes. Perhaps the RTO mandates will turn out to be the biggest organizational mistake?

Re: The bottleneck was never the code

#374

Post by rafaelmn »

jwpapi wrote: post #341
Aurornis wrote: post #335

Earlier quoted context omitted.

I think it's obvious that they're not referring to the author or a specific person at all. They're talking about how the zeitgeist has changed. Look at Hacker News archives 3 or more years ago and it would be really hard to find anyone arguing that coding speed is not a bottleneck or that engineers need to spend more time in collaboration. You would find a lot of arguments that leaving engineers alone to code is the…

Needing focus to think is not the same as needing focus to write code.. It can take a whole day to find 10 good lines to write.

And sometimes an LLM can find those 10 lines in 10 minutes. Or it can find a 100 and you cut them down to 10 in two hours total. Yes I've seen this in practice. The amount of code an LLM can tirelessly ingest is super human.

Re: The bottleneck was never the code

#375

Post by locknitpicker »

nilirl wrote: post #255
locknitpicker wrote: post #224

Earlier quoted context omitted.

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

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 matter is that all software development processes is built around how slow code is written. Now code is ceasing to become a bottleneck and the current software dev process starts to emerge as inadequate.

Re: The bottleneck was never the code

#376

Post by locknitpicker »

fg137 wrote: post #307
locknitpicker wrote: post #224

Earlier quoted context omitted.

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

> Backlogs are cleared faster than new items are added Totally depends on what kind of product and codebase. Last time I checked, the number of open issues in Claude Code repo has increased. And I have seen tons of tickets that are open for years. Not because it's technically hard or anything. An intern can do that. Those tickets are not closed because nobody wants to deal with what comes after it.

> Last time I checked, the number of open issues in Claude Code repo has increased.

The Claude Code repo features bug reports that are a mishmash of complains about prompt output, backend responses, documentation updates, browser extensions, etc.

Still, during the last week the repository reports ~2k closed issues vs ~1.3k new issues.

https://github.com/anthropics/claude-code/pulse

Re: The bottleneck was never the code

#377

Post by locknitpicker »

crabbone wrote: post #316
aspenmartin wrote: post #289

Earlier quoted context omitted.

You are not wrong about anything you’re saying but like I said this misses the forest for the trees. I’m talking about like the next ~2 years. There is a common idea that we don’t understand this technology or what will happen performance wise. We know a lot more about what’s going to happen than people think. It’s because none of this is new. We’ve known about neural nets since the 40s, we know how RL works on a fun…

> look at say Claude sonnet 3.x. It’s an entire world away in like a year In the area I work I find them to be of very little value both then and now... I see no real difference. They help in marginal tasks. Eg. they catch typos, or they help new programmers to faster explore the existing codebase. So far, I haven't used a single line of code generated by AI, even though I've seen thousands. Some of them worked to dr…

> So far, I haven't used a single line of code generated by AI, even though I've seen thousands. Some of them worked to draw attention to a problem, but none solved it successfully. It was all pretty lame.

I find this statement highly suspect. AI coding agents nowadays can spot subtle object lifetime management issues and even dependency lifecycle incompatibilities, and here you are stating you are unable to use them to fix things? How strange.

Not to mention that coding agents excel at creating greenfield projects and migrating whole frameworks.

But if you feel you can't use them then I feel sorry for you.

Re: The bottleneck was never the code

#378

Post by socratic_weeb »

One of the most full of bullshit phrases that nevertheless gets parroted all the time, specially by clueless AI bros. If that's the case, then why programmers invested so many years creating high-level langs, debuggers, syntax higlighting, intellisense, libraries, and a myriad of other tools in order to make programming easier? You guessed it: it's because programming is actually super hard and thus a real bottleneck, and will always be.

Re: The bottleneck was never the code

#379

Post by jwpapi »

rafaelmn wrote: post #374
jwpapi wrote: post #341

Earlier quoted context omitted.

Needing focus to think is not the same as needing focus to write code.. It can take a whole day to find 10 good lines to write.

And sometimes an LLM can find those 10 lines in 10 minutes. Or it can find a 100 and you cut them down to 10 in two hours total. Yes I've seen this in practice. The amount of code an LLM can tirelessly ingest is super human.

Most of the time it can’t it can write 1000s, but its not good in finding the best 10s.

Re: The bottleneck was never the code

#380

Post by Someone »

jugg1es wrote: post #17

I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have work…

> the real problems with velocity have always been more organizational than technical

If you go back far enough to the time when and one-offs and all programs were written from scratch, I doubt that. https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...:

“the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance and also, because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value”

I think technical debt started to be somewhat of an issue somewhere in the early 1970s, maybe a few years earlier.

Post reply on HN