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

651–660 of 699 posts

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

#651

Post by 9rx »

layer8 wrote: post #557
9rx wrote: post #453

Earlier quoted context omitted.

Testing is not perfect, but what else is there? Even formal proofs are just another expression of testing. With greater mathematical guarantees than other expressions, granted, but still testing all the same; prone to all the very same human problems testing is burdened with.

The difference with proofs (whether formal or informal) is that they quantify over all possible cases, whereas testing is always limited to specific cases.

There is no difference. It is all testing. Testing captures the full gamut, from simply manually using the software all the way up to formal proofs. Although the advantages of formal proofs over other modes of testing was already written about, so it is unclear what you are trying to add. Perhaps you want to clarify?

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

#652

Post by gpderetta »

stephen_cagle wrote: post #417
theshrike79 wrote: post #395

Earlier quoted context omitted.

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.

You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.

This is not really a doctor that has done the same operation 10 times. This is a doctor that jumped form hospital to hospital 10 times and probably never actually stayed long enough to be entrusted to do an operation in any hospital.

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

#653

Post by shermantanktop »

colechristensen wrote: post #576
snarf21 wrote: post #431

Earlier quoted context omitted.

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.

That sounds like good advice for someone 1) in a less hierarchical organization, and 2) during a period when jobs are easy to get.

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

#654

Post by NDizzle »

lokar wrote: post #420
stephen_cagle wrote: post #417

Earlier quoted context omitted.

You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.

You want the Dr who has done the operation 10 times, and learned something each time, and incorporated that into their future efforts. You probably don’t want a Dr who will do their 11th surgery on you exactly the way they did the first. This is what that saying is about

I want the doctor who has performed the operation and was still with the hospital in 6m, 12m, 18m, 24m to see the results of the operations that they performed.

Not the one who does a few operations and is never around to see the results of their decisions and actions.

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

#655

Post by MathMonkeyMan »

robgibbons wrote: post #26

For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…

The amount of work that you put into this comment far exceeds what I typically see in a pull request.

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

#656

Post by KalMann »

jennyholzer2 wrote: post #80
davey48016 wrote: post #68

Earlier quoted context omitted.

A friend of mine has a junior engineer who does this and then responds to questions like "Why did you do X?" with "I didn't, Claude did, I don't know why".

no hate but i would try to fire someone for saying that

This but with hate.

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

#658

Post by AnimalMuppet »

ncruces wrote: post #232
nbaugh1 wrote: post #195

Earlier quoted context omitted.

Not at all. Submitting untested PRs is a wildly outside of my experience. Having tests written to cover your code is a pre-requisite for having your PR reviewed on our team. "Does it work" aka passing manual testing, is literally the bare minimum before submitting a PR

If it's all vibe coded, how do you know — without review — that the new tests, for a new feature, test anything useful at all?

When I was in a test-driven development environment, one of our rules was that you had to see the test fail. You had to prove that it would actually test what you were trying to test.

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

#659

Post by zahlman »

ozozozd wrote: post #586
zahlman wrote: post #110

Earlier quoted context omitted.

> They were most probably also written by AI, there's no other (human) way. Yes. They came from the existing project being ported, which was also AI-written.

They were not, and they did not. Those human tests are why your browser properly renders diversely messy HTML.

Oh, I misunderstood the previous submission, then.

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

#660

Post by drio »

zx2c4 wrote: post #76
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...

Voila: https://github.com/WireGuard/wireguard-android/pull/82 https://github.com/WireGuard/wireguard-android/pull/80 In that first one, the double pasted AI retort in the last comment is pretty wild. In both of these, look at the actual "files changed" tab for the wtf.

Scary stuff.

I’d love to hear your thoughts on LLMs, Jason. How do you use them in your projects? Do they play a role in your workflow at all?

Post reply on HN