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

571–580 of 699 posts

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

#571

Post by ozozozd »

trevor-e wrote: post #159

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

Didn’t know your code could satisfy requirements without working. /s

My priorities are as follows: 1) code works 2) code satisfies requirements

Not sure how anyone can prove their code satisfies requirements when it doesn’t run.

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

#572

Post by JambalayaJimbo »

simonw wrote: post #11
andy99 wrote: post #5

I think the problem is in what “proven” means. People that don’t know any better will just do that all with LLMs and still deliver the giant untested PRs but with some LLM written tests attached. I vibe code a lot of stuff for myself, mostly for viewing data, when I don’t really need to care how it works. I’m coming around to the idea that outside of some specific circumstances where everyone has agreed they don’t ne…

That's why I emphasized the manual testing component as well. Attaching a screenshot or video of a feature working to your PR is a great way to prove that you've actually seen it work correctly - at least once, which is still a huge improvement over it not actually working at all.

This might be useful when working on a low trust team but I can’t imagine doing that in my job, unless specifically working a poc or presentation.

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

#573

Post by nijave »

theshrike79 wrote: post #395
xnx wrote: post #368

Earlier quoted context omitted.

Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.

A coworker had this anecdote decades ago. There's a difference between 10 years of experience and 1 year of experience 10 times. YOE isn't always a measurement of quality, you can work the same dead-end coding job for 10 years and never get more than "1 year" of actual experience.

Reminds me of something I heard at a conference to the effect "10-15 years of experience is usually a red flag because the only people that have that have been pressing button over and over again learning nothing"

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

#574

Post by bee_rider »

osn9363739 wrote: post #507
postflopclarity wrote: post #337

Earlier quoted context omitted.

I do this all the time. I pass my code into "you are a skeptic and hate all the code my student produces: here is their latest PR etc.. etc.."

I have devs that do this and we have CI AI code review. Problem is, it always finds something. So the devs that have been in the code base for a while know what to ignore, the new devs get bogged down by research. It's a net benefit as it forces them to learn, which they should be doing. It def slows them down though which goes against some of what I see about the productivity boost claims. A human reviewer with the…

I don’t use any of these sorts of tools, so sorry for the naive questions…

What sort of thing does it find? Bad smells (possibly known imperfections but least-bad-picks), bugs (maybe triaged), or violations of the coding guides (maybe known and waivered)?

I wonder if there’s a need for something like a RAG of known issues…

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

#575

Post by ozozozd »

simonw wrote: post #11
andy99 wrote: post #5

I think the problem is in what “proven” means. People that don’t know any better will just do that all with LLMs and still deliver the giant untested PRs but with some LLM written tests attached. I vibe code a lot of stuff for myself, mostly for viewing data, when I don’t really need to care how it works. I’m coming around to the idea that outside of some specific circumstances where everyone has agreed they don’t ne…

That's why I emphasized the manual testing component as well. Attaching a screenshot or video of a feature working to your PR is a great way to prove that you've actually seen it work correctly - at least once, which is still a huge improvement over it not actually working at all.

If someone opened a PR, and it obviously doesn’t work but they claim they tested it, maybe that’s ok for the first time.

The second time it happens they gotta go.

I would find the expectation that I need to attach a screenshot insulting. And the understanding that my peers test their code to produce a screenshot would be pretty demoralizing.

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

#576

Post by colechristensen »

snarf21 wrote: post #431
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.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…

You close the ticket and ping the manager of the nontechnical person submitting the ticket. Then you have a discussion with management about the arrangement and expectations. If it doesn't go well you polish your resume.

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

#577

Post by biglost »

snarf21 wrote: post #431
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.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

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

#578

Post by SchemaLoad »

rcxdude wrote: post #559
rootusrootus wrote: post #242

Earlier quoted context omitted.

One thing I've pushed developers on my team to do since way before AI slop became a thing was to review their own PR. Go through the PR diff and leave comments in places where it feels like a little explanation of your thought process could be helpful in the review. It's a bit like rubber duck debugging, I've seen plenty of things get caught that way. As an upside, it helps with AI slop too. Because as I see it, what…

Yeah, I always think it's kinda rude to throw something to someone else to review without reviewing it yourself, even if you were the one to write it. Looking at it twice yourself can help with catching things even faster than someone else getting up to speed with what you were doing and querying it. Now it seems like with LLMs people are putting code up for review that hasn't even been looked at once.

My coworker does this. PRs with random files from other changes left in, console logs everywhere. Blatent issues everywhere.

I find it extremely rude they chuck this stuff at me without even having read it themselves. At least these days I can just chuck the AI reviewer thing on it and throw it back to them.

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

#579

Post by SchemaLoad »

immibis wrote: post #424
georgeburdell wrote: post #173

Earlier quoted context omitted.

My manager asked me to disable CI and gating code owner reviews “for 2 weeks” 6 months ago so people could commit faster. Just because it is in your job description doesn’t mean it won’t get shoved aside when it’s perceived as the bottleneck for the core mission. Now we have nightly builds that nobody checks the result of and we’re finding out about bugs weeks later. Big company btw

That's his right. In capitalism, company owners have the power (which they delegate to managers) to fuck up the company as much as they see fit. On the upside, it means it's their responsibility and not yours. Once you've said it's going to cause horrible problems, and they say do it anyway, and you have a paper trail of this and it's backed up onto your own storage medium, then you just do it and bring popcorn. If y…

Yep, who cares. You put your 2 cent in and if the business leaders see otherwise, that's their problem. You get paid on a schedule, if the app crashes and burns because the leaders demanded to remove PR reviews, that's not your problem.

Too often I see developers getting personally invested in business outcomes which they don't have a stake in. Getting frustrated when they don't have the final say.

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

#580

Post by neutronicus »

notpachet wrote: post #544
neutronicus wrote: post #116

Earlier quoted context omitted.

I'm not either But LLMs don't really perform well enough on our codebase to allow you to generate things that even appear to work. And I'm the most junior member of my team at 37 years of age, hired in 2019. I really tried to follow the mandate from on high to use Copilot, but the Agent mode can't even write code that compiles with the tools available to it. Luckily I hooked it up to gptel so I can at least ask it qu…

> And I'm the most junior member of my team at 37 years of age This sounds fucking awesome.

Would be nice to have someone enthusiastic junior to me.

Most of the team is comfortable in their wheelhouse and when new stuff comes down the pipe it's hard to get them mobilized. I had leadership on a big green-field project and felt like we could have really used a junior.

Post reply on HN