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

441–450 of 699 posts

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

#441

Post by crabmusket »

layer8 wrote: post #138

I’d go further and say while testing is necessary, it is not sufficient. You have to understand the code and convince yourself that it is logically correct under all relevant circumstances, by reasoning over the code. Testing only “proves” correctness for the specific state, environment, configuration, and inputs the code was tested with. In practice that only tests a tiny portion of possible circumstances, and omits…

> "proves"

I like using the word "demonstrates" in almost every case where people currently use the word "proves".

A test is a demonstration of the code working in a specific case. It is a piece of evidence, but not a general proof.

And these kinds of narrow ad-hoc proofs are fine! Usually adequate.

To rephrase the title of TFA, we must deliver code that is demonstrated to work.

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

#442

Post by array_key_first »

layer8 wrote: post #138

I’d go further and say while testing is necessary, it is not sufficient. You have to understand the code and convince yourself that it is logically correct under all relevant circumstances, by reasoning over the code. Testing only “proves” correctness for the specific state, environment, configuration, and inputs the code was tested with. In practice that only tests a tiny portion of possible circumstances, and omits…

I agree - it's trivial to write 100% test coverage if your code isn't robust and resilient and just does "happy path" type stuff.

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

#443

Post by epiccoleman »

unbalancedevh wrote: post #300
rootusrootus wrote: post #249

Earlier quoted context omitted.

As someone else mentioned, the process is async. But I achieve a similar effect by requiring my team to review their own PRs before they expect a senior developer to review them and approve for merging. That solves some of the problem with people thinking it's okay to fire off a huge AI slop PR and make it the reviewer's responsibility to see how much the LLM hallucinated. No, you have to look at yourself first, beca…

> requiring my team to review their own PRs before they expect a senior developer to review them I'm having a hard time imagining the alternative. Do junior developers not take any pride in their work? I want to be sure my code works before I submit it for review. It's embarrassing to me if it fails basic requirements. And as a reviewer, what I want to see more than anything is how the developer assessed that their c…

> I want to be sure my code works before I submit it for review.

No kidding. I mean, "it works" is table stakes, to the point I can't even imagine going to review without having tested things locally at least to be confident in my changes. The self-review for me is to force me to digest my whole patch and make sure I haven't left a bunch of TODO comments or sloppy POC code in the branch. I'd be embarrassed to get caught leaving commented code in my branch - I'd be mortified if somehow I submitted a PR that just straight up didn't work.

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

#444

Post by rootusrootus »

cesarb wrote: post #373
rootusrootus wrote: post #253

Earlier quoted context omitted.

It could be a death-by-a-thousand-cuts situation and we don't have enough context. My company has spent the last few years really going 1000% on the capitalization of software expenses, and now we have to include a whole slew of unrelated attributes in every last Jira ticket. Then the "engineering team" (there is only one of these, somehow, in a 5K employee company) decrees all sorts of requirements about how we test…

> But putting the ticket number in the commit ... that's basically automatic, I don't know why it should be that big a concern. The branch itself gets created with the ticket number and everything follows from that, there's no extra effort. That poster said "attach a JIRA Ticket to the PR", so in their case, it's not that automatic.

A lot of Jira shops use the rest of the stack, so it becomes automatic. The branch is named automatically when created from a link on the Jira task. Every time you push it gives you a URL for opening the PR if you want, and everything ends up pre-filled. All of the Atlassian tools recognize the format of a task ID and hyperlink automatically.

I haven't dealt with non-Atlassian tools in a while but I assume this is pretty much bog standard for any enterprise setup.

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

#446

Post by rootusrootus »

alfons_foobar wrote: post #393
rootusrootus wrote: post #316

Earlier quoted context omitted.

> Do junior developers not take any pride in their work? Yes. I have lost count of the number of PRs that have come to me where the developer added random blank lines and deleted others from code that was not even in the file they were supposed to be working in. I'm with you -- I review my own PRs just to make sure I didn't inadvertently include something that would make me look sloppy. I smoke test it, I write comme…

> added random blank lines and deleted others from code that was not even in the file they were supposed to be working in. Maybe some kind of auto-formatter?

That is my charitable interpretation, but it's always one or two changes across a module that has hundreds, maybe thousands of lines of code. I'd expect an auto-formatter to be more obvious.

In any case, just looking over your own PR briefly before submitting it catches these quickly. The lack of attention to detail is the part I find more frustrating than the actual unnecessary format changes.

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

#447

Post by vernrVingingIt »

nec4b wrote: post #358
vernrVingingIt wrote: post #265

Earlier quoted context omitted.

Well starting over from first principles is exactly what the chip design and manufacture industry is doing. We also cannot afford, in non-finance terms, to burn all the resources on conservation of the existing software mess. Automation is making it pretty easy to generalize all the abstraction into math automatically to inform how to evolve the manufacturing process. Using American principles against Americans, it w…

>> Well starting over from first principles is exactly what the chip design and manufacture industry is doing. No, there are thousands of hardware libraries (HDLs, IP cores, Standard cell libs) which chip designers use. Hardly anyone builds chips from first principles. They are using same layers of abstractions as software does.

I meant they aren't sticking with obligation to software history.

Of course they have not dumped their own methods.

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

#448

Post by Yoric »

9rx wrote: post #428
tensor wrote: post #381

Earlier quoted context omitted.

IMO tech suffers pretty horrible title inflation. If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? It's pretty ridiculous. But this sort of thing is really typical. The average tenure of someone in tech is probably about 2 years and each year the expectation is to see "big" career progression. Very often "When is my title going to change" is asked literally in th…

> If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? There is nothing left. Not everyone puts in the same dedication towards the craft, of course. It very well might take someone 30 years to reach "principle" (and maybe even never). But 5 years to have "seen it all" is more than reasonable for someone who has a keen interest in what they are doing. It is not like a…

Er...

I've been programming since I was 7 and I'm old enough to remember the previous AI summer. Somewhere along the way, I've had impact on a few technologies you have heard of, I've coded at almost all levels from (some very specialized) hardware to Prolog, Idris and Coq/Rocq, with large doses of mainstream languages in-between, and I don't think I'll ever be close to having seen in all.

If anyone tells me that they've seen it all in 5 years, I'm going to suspect them of not paying attention.

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

#449

Post by duxup »

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 always the developers who can break / bypass the rules who are the most dangerous.

I always think of the "superstars" or "10x" devs I have met at companies. Yeah I could put out a lot of features too if I could bypass all the rules and just puke out code / greenfield code that accounts for the initial one use case ... (and sometimes even leave the rest to other folks to clean up).

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

#450

Post by ambicapter »

sharkjacobs wrote: post #350
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.

Maybe I'm not late enough in my career to understand what you're saying, but what kind of problems are you helping the business solve with code that hasn't been proven to work?

Getting a big sale by hacking together a demo that wouldn't scale up in the slightest without a complete rework of your backend.
Post reply on HN