Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

Post reply on HN
Print view View original

291–300 of 400 posts

Re: Writing Code Was Never the Bottleneck

#291

Post by imiric »

aleph_minus_one wrote: post #126
andrelaszlo wrote: post #22

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…

Simply require from the junior developers that each pull request has to satisfy a very high standard. If they are not sure about something, they may ask, but if they send you some pull request of bad quality to review, and you find something, they deserve a (small) tantrum. It is likely not possible to completely forbid junior developers from using AI tools, but any pull request that they create that contains (AI-gen…

The thing is that a "very high standard" is not a measurable criterion. The project can have test coverage requirements and strict linting to catch basic syntax and logic problems, but how do you enforce simplicity, correctness, robustness, or ergonomics? These are abstract concepts that are difficult to determine, even for experienced developers, so I wouldn't expect less experienced developers to consider them. A code review process is still important, with or without LLMs.

So we can ask everyone using these tools to understand the code before submitting a PR, but that's the best we can do. There's no need to call anyone out for not meeting some invisible standard of quality.

Re: Writing Code Was Never the Bottleneck

#292

Post by tomasreimers »

hakunin wrote: post #238
tomasreimers wrote: post #231

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…

I don't honestly know why most people do code reviews, because it's often presented as some kind of "quick sanity check" or "plz approve". Here's why we do code reviews where I get to lead the practice: 1. Collaborate asynchronously on architectural approach: (simplify, avoid wheel reinvention) 2. Ask "why" questions, document answers in commits and/or comments to increase understanding 3. Share knowledge 4. Bonus: f…

This.

Re: Writing Code Was Never the Bottleneck

#293

Post by kevmo314 »

hakunin wrote: post #238
tomasreimers wrote: post #231

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…

I don't honestly know why most people do code reviews, because it's often presented as some kind of "quick sanity check" or "plz approve". Here's why we do code reviews where I get to lead the practice: 1. Collaborate asynchronously on architectural approach: (simplify, avoid wheel reinvention) 2. Ask "why" questions, document answers in commits and/or comments to increase understanding 3. Share knowledge 4. Bonus: f…

I've found great benefit in voluntary code reviews. Engineers are self-aware enough that if they're at all worried about a change working they will elect for a voluntary code review. As a reviewer I also feel like my opinion is more welcomed because I know someone chose to do it instead of being forced so, so I pay more attention.

This really gets at the benefits you mention and keeps people aligned with them instead of feeling like code review should be rushed.

Re: Writing Code Was Never the Bottleneck

#294

Post by tomasreimers »

peterldowns wrote: post #243
tomasreimers wrote: post #231

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…

Hey Tomas, been a while! I like the approach that graphite is taking to AI code review — focus on automating the “lint” or “hey this is clearly wrong” or “you probably wanted to not introduce a security flaw here” type stuff, so that humans can focus on the more important details in a changeset. As your AI reviewers take on more tasks, have your answers to your question (“why do we do code review”) changed at all?

Certainly! A lot less proof reading and pair programming and a lot more architecture / "hey should we be going in this direction" / sharing tribal knowledge

Also hi Peter! Long time :)

Re: Writing Code Was Never the Bottleneck

#295

Post by hbn »

bob1029 wrote: post #176

I used to think authoring code was the bottleneck. It took a solid decade to learn that alignment of the technology to the business is the actual hard part. Even in the extreme case like a B2B/SaaS product wherein every customer has a big custom code pile. If you have the technology well aligned with the business needs, things can go very well. We have the technology to make the technology not suck. The real challeng…

> alignment of the technology to the business is the actual hard part

Yup. The tough part of my job has always been taking the business requirements and then figuring out what the business ACTUALLY wants. Users will tell you what they want, but users are not designers and usually don't think past what they currently want right now. Give them exactly what they say they want and it will almost never give a good result. You have to navigate consequences of decisions and level-set to find the solution.

LLMs are not good at this and only seem to get worse as "improved" models find users prefer constant yes-manning. I've never had an LLM tell me my idea was flawed and that's a huge issue when writing software.

Re: Writing Code Was Never the Bottleneck

#296

Post by afiodorov »

otabdeveloper4 wrote: post #287
afiodorov wrote: post #11

Even without LLMs, we were approaching a point of saturation where software development was bottlenecked by market demand and funding, not by a shortage of code. Our tooling has become so powerful that the pure act of programming is secondary. It's a world away from when the industry began. There's a great story from Bill Gates about a time when his ability to simply write code was an incredibly scarce resource. A co…

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

Re: Writing Code Was Never the Bottleneck

#297

Post by seanmcdirmid »

andrelaszlo wrote: post #22

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…

I don’t give my interns green field projects, and they are usually hack jobs like get A working with B, which means they can’t really rely on LLMs to do much of the coding, and must instead must try, run the test, adjust, try again. More like junior investigators who happen to write some code I guess. I imagine this is extremely group-specific though.

For junior devs, it’s about the same, I’m assigning hack jobs, because most of what we need to do are hack jobs. The code really isn’t the bottleneck in that case, the research needed to write the code is.

Re: Writing Code Was Never the Bottleneck

#298

Post by kpen11 »

Whether or not there was a claim that code _was_ the bottleneck, this raises some points that I've been talking over with people for a while now.

Introducing a lever to suddenly produce more code faster creates an imbalance in the SDLC. If our review process was already a bottleneck, now that problem is even worse! If the review bottleneck was something we could tolerate/ignore before, that's no longer the case, we need to solve for it. No, that doesn't mean let some LLM review the code and ship it. CI/CD needs to get better and smarter. As a reviewer, I don't want to be on the lookout for obscure edge cases. I want to make sure my peer solved the problem in a way that makes sense for our team. CI/CD should take care of making sure the code style aligns with our policies, that new/updated tests provide enough coverage for the new/changed functionality, and that the feature actually works.

The code expertise / shared context is another tough problem that needs solving, only highlighted by introducing a random graph of numbers generating the code. Leaning on that one engineer who has been on the team for 30 years and knows where all the deep dark secrets are was not a sustainable path even before coding agents. Having a markdown file that just says "component foo is under /foo. Run make foo to test it" was not documentation. The imbalance in the SDLC will light the fire under our collective asses to provide proper developer documentation and tooling for our codebases. I don't know what that looks like yet. Some teams are trying to have *good* markdown files that actually document where all the deep dark secrets are. These are doubly beneficial because coding agents can use those as well as your humans. But better markdown is probably a small step towards the real fix which we wont be able to live without in the near future.

Anyway, great points brought up in the article. Coding agents aren't going away, so we need to solve this imbalance in the SDLC. Fight fire with fire!

Re: Writing Code Was Never the Bottleneck

#299

Post by hnaccount_rng »

AnotherGoodName wrote: post #285
Henchman21 wrote: post #248

Earlier quoted context omitted.

We turned our back on VB. Do we have the collective will to turn our back on AI? If so I suspect it’ll take a catalyzing event for it to begin. My hunch tells me no, no we don’t have the will.

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.

Came here looking for this comment!

I think we will need to find a way to communicate “this code is the result of serious engineering work and all tradeoffs have been thought about extensively” and “this code has been vibecoded and no one really cares”. Both sides of that spectrum have their place and absolutely will exist. But it’s dangerous to confuse the two

Re: Writing Code Was Never the Bottleneck

#300

Post by tstrimple »

hn_throwaway_99 wrote: post #237
Sammi wrote: post #79

Earlier quoted context omitted.

I'm expecting to see so much more poor quality software being made. We're going to be swimming in an ocean of bad software. Good experienced devs will be able to make better software, but so many inexperienced devs will be regurgitating so much more lousy software at a pace never seen before, it's going to be overwhelming. Or as the original commenter described, they're already being overwhelmed.

I'm showing my age, but this is almost exactly analogous to the rise of Visual Basic in the late nineties. The promise then was similar: "non-programmers" could use a drag-and-drop, WYSIWYG editor to build applications. And, IMO, VB was actually a good product. The problem is that it attracted "developers" who were poor/inexperienced, and so VB apps developed a reputation for being incredibly janky and bad quality. T…

It's the exact same thing every time a technical bar is lowered and more people can participate in something. From having to manually produce your own film to having film processing readily available on demand to not needing to process film at all and everyone has a camera in their pocket. The number of people taking photos has absolutely exploded. The average quality of photos has to have fallen through the floor. But you've also got a ton of people who couldn't participate previously for one reason or another who go on to do great things with their new found capabilities.
Post reply on HN