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

271–280 of 446 posts

Re: The bottleneck was never the code

#271

Post by aspenmartin »

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…

- 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 and its strategy

- BUT the benefit now is you can basically prototype for free. Before we had to be extremely careful with engineer headcount investment. Now we can try many more things under the same time constraints.

Re: The bottleneck was never the code

#272

Post by aspenmartin »

leptons wrote: post #247
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…

And now they're almost forcing us to produce machine-made tech-debt at an industrial scale. The AI craze isn't going to produce the boon some people think it will. And the solution? More AI, unfortunately.

The solution truly is more AI, yes.

> AI craze isn't going to produce the boon some people think it will.

What’s the boon you don’t think it will produce?

Re: The bottleneck was never the code

#273

Post by [deleted] »

anonyfox wrote: post #197
rkozik1989 wrote: post #71

Earlier quoted context omitted.

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…

[deleted]

Re: The bottleneck was never the code

#274

Post by visarga »

aspenmartin wrote: post #271
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…

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

> BUT the benefit now is you can basically prototype for free.

But.. so can your competitors. And that changes the value proposition.

Re: The bottleneck was never the code

#275

Post by visarga »

leptons wrote: post #247
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…

And now they're almost forcing us to produce machine-made tech-debt at an industrial scale. The AI craze isn't going to produce the boon some people think it will. And the solution? More AI, unfortunately.

> And the solution? More AI, unfortunately.

I think the solution to using AI in coding is more testing, which unlocks even more AI.

Re: The bottleneck was never the code

#276

Post by [deleted] »

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…

[deleted]

Re: The bottleneck was never the code

#277

Post by Nemi »

solatic wrote: post #258
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…

I would term it a Depreciating Asset, like a car or a building. Bitrot is real.

Re: The bottleneck was never the code

#278

Post by flakes »

runeks wrote: post #269
paldepind2 wrote: post #100

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

One of the classic examples is highway traffic. You want to prevent traffic jams, so you increase the number of lanes. However, now that there are more lanes, people see less “cost” in driving, leading to even more people driving (e.g. to go on more day trips or as alternative to public transport). This can cause the traffic jams to become even worse.

So, increased efficiency can sometimes not lead to reduced latency, which goes against our natural thinking.

Re: The bottleneck was never the code

#279

Post by jayd16 »

timacles wrote: post #219
jayd16 wrote: post #179

Earlier quoted context omitted.

You're not looking at it very empathetically. You're disregarding the concerns I floated, you expect the team that feels underwater to now stop everything to reshuffle the work scheduling to fit in a wild card all while you're calling them bad and replaceable. I mean it really sounds like you're not on their side at all. It's their job to help you succeed, apparently. From what you've said already, you don't care abo…

If he was hired to do a job, its not on the team to "trust" him. Its to incorporate him as a resource. I'm sorry but speaking strictly from a productivity standpoint, we're not here to be empathetic, we're here to deliver value to the organization. If I'm a manager of a team thats struggling and now also sabotaging additional resources, because they havent got the right warm and fuzzies, I'm going to be looking to ha…

Well this is all highly hypothetical but my point is that there are valid reasons to not entrust a contractor, who is only around temporarily, with long standing features. Not because they are nefarious but because they, by definition, will not own the feature ultimately.

Resistance is also not the same as sabotage. My assumption is that everyone is acting in good faith from their own perspective. An immediate issue I see that the contractor was brought in because folks were looking at the calendar and not the tasks. Now the team is being pushed to carve out tasks. If shovel ready tasks are identified first, almost certainly, things go smoother. You're not context switching everyone. Its far less chaotic.

What you seem to not understand is empathy is going to move the team forward and deliver. Jumping to bad faith immediately is likely not the fastest way to a solution. If someone is struggling, its useful to understand why and address those problems. Its often not because they're bad.

Re: The bottleneck was never the code

#280

Post by nomel »

tikhonj wrote: post #114
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…

Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management. There is a reason (well, many reasons) that, if I'm working on a creative project with somebody outside a company, we would never think of reaching for Scrum ceremonies or Jira. It is more than perfectly consistent to complain about that while valuing collaborati…

I require Jira for all my work to protect myself from three things, definitely not productivity:

1. µManagement asking "What have you even been doing?" Now they have a dashboard, and I have a nice record.

2. Protect me from people who wouldn't tell me problems existed, but would tell their managers they were blocked by those problems. Now, the understanding is that if the Jira doesn't exist, then the problem doesn't exist.

3. I use the "On Hold" state of an issue for a clear signal, for them and their managers that I add as watchers, that there will be no progress until whatever requirement is met (question answered, etc). It dramatically decreases response times, and means I don't have to nag them. Goes back to #2, where I can point out that they are blocking themselves.

All these things come into existence because people are so bad at collaborating, but really good at pointing fingers.

Post reply on HN