Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

391–400 of 400 posts

Re: Writing Code Was Never the Bottleneck

#391

This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1". If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making. [1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-…

But the reason we read code is to be able to change it or extend it. If we don’t need to change it extend it, the need to read it disappears too.

Re: Writing Code Was Never the Bottleneck

#392
post #290

In a professional setting, I agree 100%, no notes. Where LLMs have helped me the most are actually side projects. There, writing the code is absolutely the bottleneck - I literally can't (or perhaps won't is more truthful) allocate enough time to write code for the little apps I've thought of to solve some small problem.

LLMs help me at work writing one-off scripts where I can verify they're behaving correctly. Or I'll give it a few lines of code where I don't like how they read and ask it if there's a cleaner way to write it, i.e. if there's maybe an API or method on a class that I'm forgetting/didn't know about, and I can understand its suggestion for a rewrite. But getting it to spit out hundreds or even thousands of lines of code…

This is where LLMs agents work well. Micro-micro-services.

Re: Writing Code Was Never the Bottleneck

#393
post #390

Earlier quoted context omitted.

Basically the juniors just ask the LLM for an explanation of what the problem is and then fix what the LLM interprets your review to be talking about. The way that you solve this is that you pull your junior into a call and work them through your comments one by one verbally, expecting them to comprehend the issues every time.

If my boss is ok with AI, why bother and make the junior hate you? The codebase will go to shit regardless.

I mean obviously if you have completely checked out and no longer care then don't bother with this.

Re: Writing Code Was Never the Bottleneck

#394
post #53

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

> - Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This reminded me of a quarter million dollar software project one of my employers had contracted to a team in a different country. On the face of it - especially if you go and check by the spec sheet - everything w…

> With LLMs this kind of work now basically becomes free to do and automatic.

So is this going to kill the demand for offshored code ? If you can get the same needs-babysitting code quality in no-time and no-budget ?

Re: Writing Code Was Never the Bottleneck

#395
post #283
post #172

Earlier quoted context omitted.

This almost seems to be a weird artefact of capitalism. Ive worked on several projects which at some point became obviously doomed to almost everybody in the trenches but management/investors/owners kept believing. Perception of reality did not permeate the class divide. I wish I could make $$$ off this insight somehow but im not sure it's possible.

> This almost seems to be a weird artefact of capitalism. I don't see how this would be causally linked to capitalism in any meaningful way.

Because hundreds of years after multiple things have proven that systems with free and open flow of information, skills, and techniques beats any system where information is walled off, capitalism (or corporatism really) still insists, all too often, on favoring feudal style top down methods of control instead of bottom up “empower the teams and facilitate the flow of information”; they don’t merely suppress the flow of information they actively ignore information; and they prefer people idle rather than work on non-approved priorities.

Many people use capitalism to mean the system of multinational corps and their secretive, hierarchical, and morally offensive ways, rather than anything to do with free market economics (which are predicated on the free flow of information in the market).

Re: Writing Code Was Never the Bottleneck

#397
I’m seeing this everywhere and it’s great to have it spelt out.

“The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication”

AI can dramatically speed up testing and code reviews. Generating unit tests is a major application of AI.

Code reviews can be accelerated too: “please quickly explain what this code is doing” to give you a foothold; “please check this code for any obvious mistakes” enables you to quickly bounce if a new review will be needed. And better yet - the submitter can ask the AI to do that, and also to suggest refactoring that will make code review easier and faster for someone else.

As for understand code and communicating it, well that is going to less and less necessary as the abstraction level we work at is lifted.

This objection is just cope. It’s moving the goalposts because we’re scared AI is going to take out jobs.

In truth, it will simply accelerate our work until we hit AGI. And at that point (which I think is probably a way off) we’ll have much greater concerns than the job market.

Re: Writing Code Was Never the Bottleneck

#399
post #375

Earlier quoted context omitted.

>LLMs write a lot of bad code that cannot be realistically reviewed. It can be reviewed. The job descriptions I have encountered so far, (thousands of them), not one of them mentions reading fast as a skill even more important that writing/typing. Put it another way, I have yet to go to an interview with the sole purpose of reading code, and writing code as an insignificant detail. For example: 5 years of reading Pyt…

Donald Knuth never said that. It's from the preface to SICP, by Abelson and Sussman. I've edited the quote on Goodreads (though I don't know how long it will stick).

The actual quote in the SICP preface:

> Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

I've updated the quote on Goodreads again, but it seems like a losing battle to stem the tide of careless/misattributed quotes (it's even found its way to books and papers by not-too-meticulous authors).

Re: Writing Code Was Never the Bottleneck

#400
Lots of devs complaining about code quality and understandability here.

I'm going to skip the obvious answer about how LLMs can actually improve code quality and reviewability and focus on a different argument: why engineers even care about code quality.

Most code is not written as a work of art but as an important functional piece to achieve return on capital. Programmers get paid by companies to produce code. The payment ultimately is driven by expectation of a return on investment of the code. Ultimately business owners and owners do not really care about code quality as long as it can deliver on return on capital. There are plenty of profitable businesses run on spaghetti code and old technology. However, engineers realized that bad code resulted in costly downstream consequences including consequences that affected ROI. Tech debt had to be paid not just in developer hours but also dollars and cents. Thus this obsession with code quality, code reviews, and this current debate.

Many including Andrew Ng at YC startup school recently are realizing that writing bad code is now a two way door instead of the one way door that it used to be. With LLMs you can deploy some bad code, realize it's bad, and rewrite that entire codebase tomorrow with near negligible cost. The fact that LLM can write some very very bad code is less important than the return on invested capital of that code especially when taking into account the speed at which that code can be fixed / completely re-written in the future, and especially when that in that future, LLMs will be even more capable than it is now.

Here's my advice: give in the shitty code and merge it. Claude 6 will refactor all of it to your liking very soon.

Post reply on HN