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

11–20 of 446 posts

Re: The bottleneck was never the code

#11

Post by nilirl »

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 uncontrollables are in our favor?

Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.

Re: The bottleneck was never the code

#12

Post by christophilus »

lysium wrote: post #6
j16sdiz wrote: post #3

(not related to the article) The flashing red dot on the web page is very annoying. Is there some design reason for that? edit: I meant the inside `trail-map-container`

FWIW I see the red dot only at the top of the page, flashing slowly. It does not annoy me, in fact I only discovered it because of your comment.

On desktop, it's fixed to the left of the story, pulsing along the entire time you're trying to read. If you are like me, it will annoy you. I had to switch to reader mode.

Re: The bottleneck was never the code

#13

Post by jorisw »

lysium wrote: post #4

Can someone explain the title? I think the author illustrates that the code was the bottleneck and it has shifted to context. What am I missing?

I think the point they're trying to make is that context known by humans and the requirements they agree on, is 'the' bottleneck, rather than implementation

Re: The bottleneck was never the code

#14

Post by jorisw »

> Agents that consume context need agents that produce it. Once that loop is running, the organization has a written substrate it would never have produced on its own.

I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.

Re: The bottleneck was never the code

#15

Post by nayroclade »

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 about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.

Re: The bottleneck was never the code

#16

Post by bsenftner »

lysium wrote: post #4

Can someone explain the title? I think the author illustrates that the code was the bottleneck and it has shifted to context. What am I missing?

I think he is saying, I hope he is saying, that software has never been writing software, it has been communications with people over what the software should be, needs to be, and the entire point all along has been to achieve better collaboration with people, and implied: to achieve their collective goal. He spends a good amount of time on how slow writing software has been in the past, and that allowed the industry to over focus on the software writing. While it has been pointed out a number of times by milestone books our industry embraced that it is the communications aspect of why and what we write that is the most important. Finally now that is being forced upon us because writing code is now automated, and all that is left is the specification and the communications with humans over what and why.

Re: The bottleneck was never the code

#17

Post by jugg1es »

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 worked at in the long-term.

Re: The bottleneck was never the code

#18

Post by jpollock »

jorisw wrote: post #10
rudyp_dev wrote: post #8

I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product. It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context mis…

> difference between code used to implement a product and when code _is_ the product Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.

Code you ship vs tooling you use to build the code.

So, the product vs everything that is needed on the way, but isn’t the core.

CI/CD tooling, template population…. Things you write a use once/use few script for.

I typically end up with a library of tools to deal with repetitive finicky tasks.

Re: The bottleneck was never the code

#19

Post by rudyp_dev »

jorisw wrote: post #10
rudyp_dev wrote: post #8

I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product. It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context mis…

> difference between code used to implement a product and when code _is_ the product Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.

I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck.

If you're writing OSS code or software projects expected to be used by others that may have constraints like that, then by all means the code that gets output matters itself. But even still I'd argue that the cost of writing code manually to get there is still a bottleneck.

Re: The bottleneck was never the code

#20

Post by luodaint »

The paper hits the nail right on the head, but it misses the mark on the next constraint: how to decide what to build.

In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.

Post reply on HN