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

251–260 of 446 posts

Re: The bottleneck was never the code

#251

Post by drschwabe »

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…

What type of engineer, who until a year ago - because of AI apparently - is suddenly no longer concerned about code? Personally I'm just as concerned about code because AI has not changed the fact that it still takes a really long time to develop stable, secure software (ie- if you're making software to do ambitious things). Nothing about modern AI tools eliminate the need to get in the zone; using AI to amplify one's engineering skills let's us solve the next problem faster - but in software there are unlimited problems.

Re: The bottleneck was never the code

#252

Post by skydhash »

locknitpicker wrote: post #217
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…

> I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. I don't think this comment is fair or grounded. There are plenty of process bottlenecks that are created by developers. Unfortunately I have a hefty share of war stories where a tech lead's inability to draft a coherent and clear design resulted in project delays and systems riddled…

> Unfortunately I have a hefty share of war stories where a tech lead's inability to draft a coherent and clear design resulted in project delays and systems riddled with accidental complexity required to patch the solution enough to work

This is also an organizational problem (bad hiring/personal management). If you put an incompetent individual at the helm of a project, then resources (especially time) will be spent horrendously and you will have more problems down the line. That’s true for all type of organizations and projects.

Re: The bottleneck was never the code

#253

Post by tadfisher »

_diyar wrote: post #129
SV_BubbleTime wrote: post #103

Earlier quoted context omitted.

That’s kind of just strawman with an origin story isn’t it?

No because the goomba is the average of two real opinions, and the strawman is a distortion/reduction of any opinion such that its easy to argue against.

More like a superposition of two opinions.

Re: The bottleneck was never the code

#254

Post by palmotea »

bcooke wrote: post #229
palmotea wrote: post #214

Earlier quoted context omitted.

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

>> (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.

That's a distinction without a difference. At least historically, I was "paid to build software that solved problems" and I was to do that by writing code. If I didn't write code, and enough of it, I'd be fired. Getting my flow state disrupted for no good reason was something I'd resist.

Also agile ceremonies are a drag, literally becoming the thing agile was originally supposed to be fighting against (not that agile is gospel, I've always disagreed with some of its practices). They're not a good reason. And I also mentioned an actual good reason. I should also note those meetings I was referring to positively were almost always with users, not tech people.

> 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 wasn't addressing the parent poster's point per se (and I noted that and why), just noting that a lot of the "collaborative" activities he cited were often not that collaborative, and the shade he was throwing at people who were unenthusiastic about participating in them was probably unwarranted and misguided.

tl;dr: OP needs to have more empathy. There are better ways to thread the needle of his observations than what was on display in his comment.

Re: The bottleneck was never the code

#255

Post by nilirl »

locknitpicker wrote: post #224
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…

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 apologize for my tone. You're right, dealing with the speed of code generation is an unprecedented problem. I was making the argument that it's not the most important to the business and that rate of code change is very rarely the top concern. But that does not mean it's not the most important problem for someone. For the developers dealing with the system, it is.

Re: The bottleneck was never the code

#256

Post by Izkata »

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…

There's an in-between point that I think is better than either, but it can be more difficult to find the right balance: Direct contact with internal stakeholders (with the manager still somewhat involved to still have a good overall view and help prioritize / push back / act as a general buffer), while shielded from customers. That's the place I've always preferred.

Re: The bottleneck was never the code

#258

Post by solatic »

jmilloy wrote: post #188

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 liability.

Re: The bottleneck was never the code

#259

Post by 2ndorderthought »

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…

Did you ever try no meeting days and other methods to avoid interrupting thought workers?

Because even if someone is writing design documents you shouldn't be interrupting that process regularly either.

Re: The bottleneck was never the code

#260

Post by jolt42 »

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…

Sometimes code is the bottleneck, other times it's not. Large company, not a bottleneck, fixing bugs or individual app developer, more so.
Post reply on HN