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

Your job is to deliver code you have proven to work

simonwillison.net

Post reply on HN
Print view View original

151–160 of 699 posts

Re: Your job is to deliver code you have proven to work

#151

Post by rglover »

"Slow the f*ck down." - Oliver Reichenstein [1]

This only happens because the software industry has fallen into the Religion of Speed. I see it constantly: justified corner-cutting, rushing shit out the door, and always loading up another feature/project/whatever with absolutely zero self-awareness. AI is just an amplifier for bad behavior that was already causing chaos.

What's not being said here but should be: discipline matters. It's part of being a professional and always precedes someone who can ship code that "just works."

[1] https://ia.net/*

Re: Your job is to deliver code you have proven to work

#152

Post by 1-more »

evilduck wrote: post #24
wizzwizz4 wrote: post #8

Earlier quoted context omitted.

It's not a new phenomenon. Time was, people would copy-paste from blog posts with the same effect.

I would bet in most organizations you can find a copy-pasted version of the top SO answer for email regex in their language of choice, and if you chase down the original commit author they couldn't explain how it works.

I think it's impossible to actually write an email regex because addresses can have arbitrarily deeply nested escaping. I may have that wrong. I'd hope that regex would be .+@.+ and that's it (watch me get Cunninghammed because there is some valid address wherein those plusses should be stars).

Re: Your job is to deliver code you have proven to work

#153

Post by hnthrow0287345 »

endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

>It's even worse than that: non-junior devs are doing it as well.

This might be unpopular, but that is seeming more like an opportunity if we want to continue allowing AI to generate code.

One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. Obviously this gets worse if more total code is being produced.

We could eliminate that interruption by having someone doing more thorough code reviews, full-time. Someone who is not being bound by sprint deadlines and tempted to gloss over reviews to get back to their own work. Someone who has time to pull down the branch and actually run the code and lightly test things from an engineer's perspective so QA doesn't hit super obvious issues. They can also be the gatekeeper for code quality and PR quality.

Re: Your job is to deliver code you have proven to work

#154

Post by rcbdev »

vernrVingingIt wrote: post #126
reedf1 wrote: post #106

Earlier quoted context omitted.

it's even worse than that! non- devs are doing it as well

[flagged]

This sounds like the exact kind of profound pseudo-enlightenment that one gets from psychedelics. Of course, it's all electrons in the end.

Trying to create a secure, reliable and scalable system that enables many people to work on one code base, share their code around with others and at the end of the day coordinate this dance of electrons across multiple computers, that's where all of these 'useless' layers of abstraction become absolutely necessary.

Re: Your job is to deliver code you have proven to work

#155

Post by LandR »

0x500x79 wrote: post #111
dfxm12 wrote: post #6

there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. Is anyone else seeing this in their orgs? I'm not...

I am currently going through this with someone in our organization. Unfortunately, this person is vibe coding completely, and even the PR process is painful: * The coding agent reverts previously applied feedback * Coding agent not following standards throughout the code base * Coding agent re-inventing solutions that already exist * PR feedback is being responded to with agent output * 50k line PRs that required a 1…

Fire them?

Re: Your job is to deliver code you have proven to work

#156

Post by jennyholzer2 »

bluGill wrote: post #99
jennyholzer2 wrote: post #72

Earlier quoted context omitted.

From my vantage I would argue LLMs make good devs around 0.65x more productive

Good devs are still learning how to use LLMs, and so are willing to accept the 0.65x once in a while. Any complex tool will have a learning curve. Most tools improve over time. As such good devs either have found how to use LLMs to make them more productive (probably not 10x, but even 1.1x is something), or they try them again every few months to see if things are better.

[flagged]

Re: Your job is to deliver code you have proven to work

#157

Post by lowkeyokay »

endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

In the company I’m at this is beginning to happen. PM’s want to “prototype” new features and expect the engineers to finish up the work. With the expectation that it ‘just needs some polishing’. What would be your recommendation on how to handle this constructively? Flat out rejecting LLM as a prototyping tool is not an option.

Re: Your job is to deliver code you have proven to work

#159

Post by trevor-e »

> Your job is to deliver code you have proven to work.

Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.

Re: Your job is to deliver code you have proven to work

#160

Post by vernrVingingIt »

whattheheckheck wrote: post #136
vernrVingingIt wrote: post #126

Earlier quoted context omitted.

[flagged]

What process / path do you take to get to such an enlightened state? Like books or experience or anything more about this please?

Bachelors in electrical engineering, masters in math; elastic structures applied to modeling electrical systems.

Started career in late 90s designing boards for telecom companies network backbones.

Post reply on HN