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

301–310 of 400 posts

Re: Writing Code Was Never the Bottleneck

#301

Post by antonvs »

Henchman21 wrote: post #248
hn_throwaway_99 wrote: post #237

Earlier quoted context omitted.

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…

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.

> Do we have the collective will to turn our back on AI?

Why do you believe we should "turn our back on AI"? Have you used it enough to realize what a useful tool it can be?

Wouldn't it make more sense to learn to turn our backs on unhelpful uses of AI?

Re: Writing Code Was Never the Bottleneck

#302

Post by tstrimple »

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.

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 ran for years with so few issues it never rose to IT's attention before a major event literally took the entire regional company offices offline. It caused us some pain as we had to relocate PCs to buildings with sufficient backup power. But overall the effort was far smaller than building all of those apps with the "proper" tools and processes in the first place.

Large companies can be a red tape nightmare for getting anything built. The process overload will kill simple non-strategic initiatives. I can understand and appreciate less technical people who grab whatever tool they can to solve their own problems when they run into blockers like that. Even if they don't solve it in the best way possible according to experts in the field. That feels like the hacker spirit to me.

Re: Writing Code Was Never the Bottleneck

#303

Post by whattho »

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…

[dead]

Re: Writing Code Was Never the Bottleneck

#304

Post by whattho »

conartist6 wrote: post #219
mdaniel wrote: post #216

Earlier quoted context omitted.

Who is the consumer for the JSX noise that is happening here? https://github.com/bablr-lang/language-en-ruby/blob/550ad6fd... As two nits, https://docs.bablr.org/reference/cstml and https://bablr.org/languages/universe/ruby are both 404, but I suspect that latter one is just falling into the same trap as many namespaces make of using a URL when they meant it as a URN

We're cleaning up the broken links as time goes on, but it is probably obvious to you from browsing around that some parts of the site are still very much under construction. The JSX noise is CSTML, a data format for encoding/storing parse trees. It's our main product. E.g. a simple document might look something like ` 'true' `. It's both the concrete syntax and the semantic metadata offered as a single data stream.…

[dead]

Re: Writing Code Was Never the Bottleneck

#305

Post by ortusdux »

steveBK123 wrote: post #127
dizhn wrote: post #53

Earlier quoted context omitted.

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

I dealt with a 4x as expensive statement-of-work fixed price contract that was nearshored and then subbed out to a revolving cast of characters. The SOW was so poorly specified that it was easy to maliciously comply with it, and it had no real acceptance tests. As a result legal didn't think IT would have a leg to stand on arguing with the vendor on the contract, and we ended up constantly re-negotiating on cost for…

Nailing the SOWs and acceptance test requirements is key. They can mean the difference between toxic dog food or mail trucks that last decades.

https://en.wikipedia.org/wiki/2007_pet_food_recalls

https://en.wikipedia.org/wiki/Grumman_LLV

Re: Writing Code Was Never the Bottleneck

#306

Post by rightbyte »

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.

Drag and drop GUI builders were awesome. Responsive layouts ruined GUI programming for me. It made it too much of a fuss to make anything "professional".

Re: Writing Code Was Never the Bottleneck

#307

Post by singpolyma3 »

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…

Sounds like several fundamental workflow issues that the LLM is perhaps exacerbating but need to be fixed either way.

One, they need to run their code. Make sure it works before submitting a PR. If someone submits code to me that does not work I don't care if it came from an LLM or not, go run your code and come back when it works. If they routinely refuse to run their code and never learn their lesson then I might suggest they find another profession... Or require they submit a video of the code working.

Second, going away and coming back with a totally different PR I give the feedback of "what happened to the code we were working on before? We didn't need all new code." As the senior my time is worth (a bit) more than the intern's so I don't hesitate to make their bad choices their problem. Come back when you've made a serious attempt and then we can discuss it.

Re: Writing Code Was Never the Bottleneck

#308

Post by lubujackson »

m_mueller wrote: post #196
raincole wrote: post #169

Earlier quoted context omitted.

People think juniors submitting LLM-generated code to seniors to review is a sign of how bad LLM is. I see it as a sign of how bad juniors are, and the need of seniors interacting with LLM directly without the middlemen.

The main problem in this environment is IMO: how does a junior become a senior, or even a bad junior become a good junior. People aren't learning fundamentals anymore beyond what's taught, and all the rest of 'trade knowledge' is now never experienced, people just trust that the LLM has absorbed it sufficiently. Engineering is all about trade-offs. Failing to understand why from 10 possible ways of achieving somethin…

I think the solution becomes clearer - juniors need to worry less about knowing how to program in a void, since the LLM can handle most of that, but care more about how to produce code that doesn't break things, that doesn't have unintended 2nd order effects, that doesn't add unneeded complexity, etc.

In my experience I see juniors come out of college who can code in isolation as well as me or better. But the difference between jr/sr is much more about integration, accuracy and simplicity than raw code production. If LLMs remove a lot of the hassle of code production I think that will BENEFIT the other elements, since those things will be much more visible.

Personally, I think juniors are going to start emerging with more of a senior mindset. If you don't have to sweat uploading tons of programming errata to your brain you can produce more code abd more quickly need to focus on larger structural challenges. That's a good thing! Yes, they will break large codebases but they have been soing that forever, if given the chance. The difference now is they will start doing that much sooner.

Re: Writing Code Was Never the Bottleneck

#309

Post by vjvjvjvjghv »

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…

That's how it often works with offshore code. You get a huge pile of code that meets the spec, so not totally wrong, but with a lot of small issues that are hard to identify. And you as the senior dev are now in a bad situation: since project management has marked the task as "Done" already, you are the bad guy if you reject the code and ask for rework. At some point you are worn down by all the pressure and let the code through and you end up with a growing pile of questionable code that sort of works but requires a ton of maintenance and is hard to change. You can't win.

My only hope is that AI one day will be much better than humans in every aspect and produce super high quality code. I don't see why this wouldn't happen. The current tools are still primitive.

Re: Writing Code Was Never the Bottleneck

#310

Post by RedNifre »

lionkor wrote: post #82

The difference between AI as autocomplete and vibe coding couldn't be bigger. It's like the difference between having your phone with you on a trip somewhere to take pictures with, and just watching a video of the place on your phone at home. Autocomplete speeds up code generation by an order of magnitude, easily, with no real downside when used by experienced devs. Vibe coding on the other hand completely replaces t…

Strongly disagree. The only instance where autocomplete helped me was a situation where I would have required macros, so I typed out the first 3 cases manually and had autocomplete generate the next 20.

In all other cases, autocomplete was never faster than writing it myself.

Full code generation, where you can step away from the computer for 20 minutes, does save me time.

Post reply on HN