Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

371–380 of 400 posts

Re: Writing Code Was Never the Bottleneck

#371

I've felt like a broken record the past few weeks, but this. Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck. The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there. For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or…

To me the core purpose of code review is clear - knowledge sharing. If the only person who knows about a particular change is the person who wrote it, then you have a critical point of failure. If there is an issue in a subsystem whose owner is away or who has moved on, that issue is likely to take much longer to resolve if the person on the case is looking at the code for the very first time.

An AI maximalist might say that code review is no longer necessary because in the case that there is an issue in a subsystem nobody is familiar with, you can simply ask the AI to read that source code and come back with a report of where the bug is and a proposal of how to fix it. And, since code review is useless anyway, might as well take the human out of the loop entirely - just have AI immediately commit the change and push it to production and iterate if or when another issue emerges.

This is the dream of autonomous, self-managing systems! Of course this dream is decades old at this point, and despite developing ever more complex systems it turns out that we were never quite able to do away with humans altogether. Thus, code review still appears to be useful. But it's only useful if everybody goes into it with the mindset that the goal is knowledge sharing. If the outcome of a review is not that everyone comes out of it with a good understanding of the purpose and function of the code being committed, then imo it was a waste of time.

Re: Writing Code Was Never the Bottleneck

#372
post #24

Earlier quoted context omitted.

You have to be fluent on the keyboard, to type without thought or 'hunting and pecking' if you want your ideas to flow from brain to pc smoothly and uninterrupted. Speed is part of fluency and almost a shortcut to explaining the goal in real terms. Nobody is hunting and pecking at 80wpm.

Maybe nobody is hunting and pecking at 80wpm but I am not exaggerating when I say one of the best devs I've worked with was a hunt+peck typist The fact is that programming is not about typing lines of code into an editor

I often out think my typing pace and have to cache ideas. The faster you can offload cache the less you end up having to manage. It's an effective way to rapidly reduce cognitive load and if it isn't in your toolbox then you're missing out on a valuable bit of kit.

Re: Writing Code Was Never the Bottleneck

#373

Earlier quoted context omitted.

> I don't think they are employable right now Well that sucks because that just means the pipeline for engineers to become seniors is completely broken

Sounds like we’re about to become more and more valuable over time? Hmmmm

Maybe so, but I don't want to continue this trend of older generations thriving while younger generations are kicked to the curb

I have no interest in pulling the ladder up behind me

Re: Writing Code Was Never the Bottleneck

#374

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…

these are excellent and well put observations! thank you for taking the time to share this.

Re: Writing Code Was Never the Bottleneck

#375

Right, we all know this. LLMs write a lot of bad code that cannot be realistically reviewed. I've even had code submitted to me by juniors which didn't make any sense. When I ask them why they did that, they say they don't know, the LLM did it. What this new trend is doing is generating a lot of noise and overhead on maintenance. The only way forward, if embracing LLMs, is to use LLMs also for the reviewing and maint…

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

Re: Writing Code Was Never the Bottleneck

#376

Earlier quoted context omitted.

> Writing code was the bottleneck years ago. No it wasn't. It never was.

If you're hiring 16 year olds just because of their ability to write code sounds like you're bottlenecked by writing code. Your comment doesn't clarify why you disagree.

> hiring 16 year olds just because of their ability to write code

They weren't. They were hired because of their ability to deliver software products. Huge difference.

Every kid who mechanically copied BASIC games from a magazine could "write code", but they weren't Bill Gates.

(Anyways Bill Gates was hired because of nepotism, but that's irrelevant here.)

Re: Writing Code Was Never the Bottleneck

#377
post #76

Earlier quoted context omitted.

I pray for whoever has to review code you didn't bother writing

I think this is a good use of AI. Change your thinking - the code is, and has always been, a medium between the computer and the human. Where is the human? Where do we define our intent? AI gives us a chance to redefine that relationship or at least make it more fluid. A well-architected system is easier to develop and easier to maintain. It makes sense to put all the human effort into producing that because, lo and…

LMMs don't follow instructions very well. They lose track of constraints around conversational turns, which makes them extremely unreliable

Re: Writing Code Was Never the Bottleneck

#378
post #354
post #328

Earlier quoted context omitted.

It's measurable in the number of times you have to spend >x minutes to help them go through something they should have written up by themselves. You can count the number of times you have to look at something and tell them "do it again, but without LLM this time". At some point you fire them.

That’s not measurable either. Your opinion on someone is not data.

My opinion on someone is how I decide whether I want to work with them and help them grow or fire them/wait for them to fail on their own merit (if somebody else is in charge of hiring/firing).

Re: Writing Code Was Never the Bottleneck

#379

Earlier quoted context omitted.

Fwiw I honestly think it was a mistake to turn our back on vb. Yes there were a lot of crappy barely functioning programs made in it. But they were programs that wouldn’t have existed otherwise. Eg. For small businesses automating things vb was amazing and even if the program was barely functional it was better than nothing.

When the Derecho hit Iowa and large parts of my area were without power for over a week we got to discover just how many of our very large enterprise processes were dependent to some degree on "toy" apps built in "toy" technologies running on PCs under people's desks. Some of it clever but all of it fragile. It's easy to be a strong technical person and scoff at their efforts. Look how easily it failed! But it also r…

Please don’t stop at building “toy” prototypes, it’s a great start, but take some time to iterate, rebuild, bring it to production standards, make it resilient and scalable.

You’d be surprised how little effort it is compared to having to deal a massive outage. E.g. You did eventually had to think about backup power.

Post reply on HN