Live data from Hacker News

The bottleneck was never the code

thetypicalset.com

191–200 of 446 posts

Re: The bottleneck was never the code

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

yes, most places I have worked were hobbled by the organizations being completely idiotic.

which is why engineers want to be left alone to code, historically. Better to be left alone than dealing with insane bureaucracy. But even better than that is working with good bureaucracy. Just, once you know it's insane, there's not really anything that you can personally do about it, so you check out and try to hold onto a semblance of sanity in the realm you have control over, which is the code.

Re: The bottleneck was never the code

#192
post #150

Earlier quoted context omitted.

> 2. It's annoying and disruptive to be interrupted when doing work that requires deep focus. Steering a LLM also requires deep focus. Unless you want to end up on accidentally quadratic or have a CVE named after your project.

How can it? You prompt it, then wait minutes+ for it to come back. It's the opposite of flow state.

I'm using my ADHD hyper focus skills while flagging issues that the LLM is doing.

Reading 10x more code than before puts me straight into the zone. (In a language that I find interesting: Elixir)

My own process is improving so much that I had only one bug last week that was fixed immediately after the error tracker caught.

But yeah I feel more tired sooner. So it's oneto three hyper focus zones per day, just like before.

The difference is that I enter faster, and now I'm not afraid of leaving the task and resuming later, since I can just ask for a summary of what we did so far.

I'm using two different models from two different providers to cross check the work tho.

I'm very good with bad smells I guess, after years supervising less experienced developers since early days in my long career.

Re: The bottleneck was never the code

#193

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…

/s Oh noooo, it's like they're turning into managers... Now that machine can do their job better than them they've become as unimportant as you always thought they were, always pretending to be banging keyboard where it used less brain cycles than highly important work like posturing in a meeting did. Anyone can bang a keyboard even a machine can do that now, it can surely never replace important work of you having to 10 meetings. Lets replace all of them with machines and us meeting lovers can run the company with the machine produced work that we never have hope of understanding.

I agree with this sentiment https://news.ycombinator.com/item?id=48033534

Re: The bottleneck was never the code

#194
post #34

Earlier quoted context omitted.

Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think…

> Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite Uh yes it does?? What are you talking about. https://www.google.com/search?q=hypocrisy

Bottom line is the people described as hypocritical in the comment have no principles, but rather feign passion in anything they think other people consider valuable. When devs thought coding skill was valuable, that's what they claimed to be passionate about, when the game changed and communication became key, they suddenly changed their passion. Either the timing is a coincidence, or they are hypocrites.

I don't think switching one's passion on a dime is a valid escape hatch from hypocrisy.

Re: The bottleneck was never the code

#195

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.

Ah yes, the good old No True Scotsman fallacy, where we smugly proclaim that anyone who thinks AI is good now must be working on unimportant and easy things.

Ah yes, the (please copy & paste this message into an LLM to get it to generate a novel response in these parentheses)

Re: The bottleneck was never the code

#196

An awful lot of problems can in fact be solved by 'more code' in fact. People seem to straw man this in terms of product feature surface. A lot of places skip creation and maintenance of decent observability - that's code. We can now easily use advanced, code heavy testing techniques like property testing - code. We can create environmental simulations to speed up and improve integration testing - code. We can lift u…

[dead]

Re: The bottleneck was never the code

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

Any competent engineer should understand that engineering is just the assembly line side of product development. Deciding when to release which feature, bug fixes, etc. and the development/management of the product in general has always been the real challenge, and a lot of the strategy involved in doing this relies on feedback loops that AI cannot speed up. Though at the same time I do feel like leaders on the busin…

I get what youre trying to say but this is actually a bad picture to defend. product and engineering should go hand in hand, with one side informing the other. Engineers sctually giving a shit about a product will tell product possibilities they havent even considered, product people caring about engineering will not propose utterly stupid things. and I for one can spot when a product is well designed but poorly made, as well as when a product is perfectly crafted yet useless. the sweetspot is both. and even with the speed multiplier of AI, having a proud in the craft and being actually good in it as an engineer makes a night and day difference for the final result.

Re: The bottleneck was never the code

#198
post #101

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…

I don't know how rare it is. I have always found it harder to write software when I don't know the people who will use it or get to see what they feel about it. It's part of the feedback loop.

When I get good feedback it's like winning a prize and when it's bad it lets me see where we should be spending our time rather than were we perhaps thought we should.

Re: The bottleneck was never the code

#199

Earlier quoted context omitted.

For business, software applications are tools that facilitate "the thing" that generates money. (We in the software world think that _thing_ is software and software _features_, but outside that world, there's usually a different _thing_.) The bottleneck for making software applications better at being used by (non-software) businesses is making sure the software does all the software things that actually benefit the…

> But yes, the speed can really help. You can prototype and trial and improve the feedback loop. Based on what I’ve seen, prototyping has been always easy. You don’t even have to build software for the first iteration. For UI stuff you can use a wire-framing tool. What has happened is that we abandoned the faster iteration methods (design think tank, quick demo and UX research,…) and we have full in on building the f…

Hmm not agile or waterfall....

Tsunami?

Re: The bottleneck was never the code

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

> [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway 1967

Post reply on HN