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

131–140 of 400 posts

Re: Writing Code Was Never the Bottleneck

#131

Post by MaxBarraclough »

dizhn wrote: post #53
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…

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

This sounds like a tale of failed 'waterfall model' software development.

Was it not possible to sees the quality issues before the project was finished?

Re: Writing Code Was Never the Bottleneck

#132

Post by 2OEH8eoCRo0 »

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…

Why isn't your first question, "how did you test this?"

Re: Writing Code Was Never the Bottleneck

#133

Post by AbstractH24 »

imiric wrote: post #116
fhd2 wrote: post #93

Earlier quoted context omitted.

In my experience, it was. And if we're getting real for a moment, the vast majority of programmers gets paid by a company that is, first and foremost, interested in making more money. IMHO all technical decisions are business decisions in disguise. Can the business afford to ship something that fails for 5% of their users? Can they afford to find out before they ship it or only after? What risks do they want to take?…

I agree with your sentiment, but not with the conclusion. Sure, technical decisions ultimately depend on a cost-benefit analysis, but the companies who follow this mentality will cut corners at every opportunity, build poor quality products, and defraud their customers. The unfortunate reality is that in the startup culture "move fast and break things" is the accepted motto. Companies can be quickly started on empty…

To play devils advocate for a second, the law of averages states nobody should ever found a startup. Or any business for that matter.

It’s rare that startups gain traction because they have the highest quality product and not because they have the best ability to package, position, and market it while scaling all other things needed to mane a company.

They might get acqui-hired for that reason, but rarely do they stand the test of time. And when they do, it almost always because founders stepped aside and let suits run all or most of the show.

Re: Writing Code Was Never the Bottleneck

#135

Post by Cthulhu_ »

stoneyhrm1 wrote: post #125
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…

> "good catch, I'll fix that" I see this a lot and even done so myself, I think a lot of people in the industry are a bit too socially-aware and think if they start a discussion they look like they're trying too hard. It's stupid yes, but plenty of times I've started discussions only to be brushed off or not even replied to, and I believed it was because my responses were too long and nobody actually cared.

I feel the same way; we use Gitlab in our day to day, and often I find myself writing a long reply after fixing a code review issue, describing what I changed, resources used, etc... then hitting the "resolve" button, which collapses the comment and unless the reviewer has enabled notifications and actually reads them, I doubt they would ever see my well thought-out response.

But then, for me, writing is a way to organize thought as well, plus these remarks will stay in the thread for future reference. In theory anyway, in practice it's likely they'll switch from Gitlab to something else and all comments will be lost forever.

Which makes me wish for systems that archive review remarks into Git somehow. I'm sure they exist, but they're not commonly used.

Re: Writing Code Was Never the Bottleneck

#137

Post by aleph_minus_one »

gortok wrote: post #94
AbstractH24 wrote: post #78

Earlier quoted context omitted.

If you are writing code to solve a one off task the first category is ok. What boggles my mind is people are writing code that’s the foundation of products like that. Maybe it’s imposter syndrome though to think it wasn’t already being done before the rise of LLMs

Developers have always loved the new and shiny. Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell. LLM “vibe coding” is another continuation of this “new hotness”, and while the more seasoned developers may have learned to avoid it, that’s not the majority view. CEOs and C-suites have always been disconnected from the first order effects of their cost-cutting edict…

> Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell.

This depends a lot on the "programming culture" from which the respective developers come. For example, in the department where I work (in some conservative industry) it would rather be a tough sell to use a new, shiny framework because the existing ("boring") technologies that we use are a good fit for the work that needs to be done and the knowledge that exists in the team.

I rather have a feeling that in particular the culture around web development (both client- and server-side parts) is very prone to this phenomenon.

Re: Writing Code Was Never the Bottleneck

#138

Post by jameshart »

thisoneisreal wrote: post #39
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 think this is going to look a lot like the same problem in education, where the answer is that we will have to spend less time consuming written artifacts as a form of evaluation. I think effective code reviews will become more continuous and require much more checking in, asking for explanations as the starting point instead of "I read all of your code and give feedback." That just won't be sustainable given the r…

Evaluating written artifacts is broken in education because the end goal of education is not the production of written artifacts - it is the production of knowledge in someone’s mind and the artifacts were only intended to see if that knowledge transfer had occurred. Now they no longer provide evidence of that. A ChatGPT written essay about the causes of the civil war is not of any value to a history professor, since he does not actually need to learn about the civil war.

But software development is about producing written artifacts. We actually need the result. We care a lot less about whether or not the developer has a particular understanding of the world. A cursor-written implementation of a login form is of use to a senior engineer because she actually wants a login form.

Re: Writing Code Was Never the Bottleneck

#139

Post by Cthulhu_ »

stpedgwdgfhgdd wrote: post #96
Foreignborn wrote: post #44

Earlier quoted context omitted.

I have a team that’s somewhat junior at a big company. We pretty much have everyone “vibe plan” significantly more than vibe code. - you need to think through the product more, really be sure it’s as clarified as it can be. Everyone has their own process, but it looks like rubber ducking, critiquing, breaking work into phases, those into tasks, etc. (jobs to be done, business requirement docs, domain driven design pl…

“We typically making very very detailed plans” - this is writing code in English without tests. Admittedly, since generating code is faster, you get faster feedback. Still, I do not think it as efficient as an incremental, test driven approach. Here you can optimize early on for the feedback loop.

You get faster feedback in code, but you won't know if it actually does what it's supposed to do until it's in production. I don't believe (but have no numbers) LLMs speed up the feedback loop.

Re: Writing Code Was Never the Bottleneck

#140

Post by Aeglaecia »

khazhoux wrote: post #58

Yet another article trying to take away from the impact of LLMs. This one is more subtle than most, but still the message is "this problem that was solved, was never actually the problem." Except... writing code is often a bottleneck. Yeah, code reviews, understanding the domain, etc, is also a bottleneck. But Cursor lets me write apps and tools in 1/20th the time it would take me in an area where I am an expert. It…

I feel like the author gave a pretty balanced take by recognising multiple ends of the equation ... do you yourself recognise that such the speedup described in your perspective is contingent on the environment that you have applied llms to? regarding frontend , wysiwyg , this is an environment where edge cases are deprioritized and llms thus excel. on the other hand working in an environment reliant on non publicly available technical documentation , llms are borderline useless. and in an environment where edge cases are paramount , llms actively cause harm , as described elsewhere in the thread. these three environments are concurrently true , they do not detract from each other ..
Post reply on HN