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

351–360 of 699 posts

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

#351

Post by kragen »

marcosdumay wrote: post #183
hnthrow0287345 wrote: post #153

Earlier quoted context omitted.

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

A full-time code reviewer will quickly lose touch with all practical matters and steer the codebase into some unmaintainable mess. This is not the first time somebody had that idea.

Linus Torvalds is effectively a full-time code reviewer, and so are most of his "lieutenants". It's not a new idea, as you say, but it works very well.

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

#352

Post by bonesss »

ryandrake wrote: post #88
fnands wrote: post #21

Earlier quoted context omitted.

A friend of mine is working for a small-ish startup (11 people) and he gets to work and sees the CTO push 10k loc changes straight to main at 3 am. Probs fine when you are still in the exploration phase of a startup, scary once you get to some kind of stability

I feel like this becomes kind of unacceptable as soon as you take on your first developer employee. 10K LOC changes from the CTO is fine when it's only the CTO working on the project. Hell, for my hobby projects, I try to keep individual commits under 50-100 lines of code.

Templates and templating languages are still a thing. Source generators are a thing. Languages that support macros exist. Metaprogramming is always an option. Systems that write systems…

If these AIs are so smart, why the giant LOCs?

Sure, it’s cheaper today than yesterday to write out boilerplate, but programming is about eliminating boilerplate and using more powerful abstractions. It’s easy to save time doing lots of repetitive nonsense, stopping the nonsense should be the point.

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

#353

Post by nunez »

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 feel like a story about some open-source project getting (and rejecting) mammoth-sized PRs hits HN every week!

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

#354

Post by nec4b »

jjmarr wrote: post #303
kridsdale3 wrote: post #244

Earlier quoted context omitted.

Okay. Go write an operating system and suite of apps with global memory and no protections. Why are we wasting so much time on abstractions like processes and objects? Just let let everyone read and write from the giant turing machine.

Embedded systems that EEs code for are like this. I have to explicitly opt into processes and objects in Keil RTX. I also get to control memory layout. Abstraction layers are terrible when you need to understand 100% of the code at all times. Doesn't mean they're not useful. Heck, the language for just implementing mathematical rules about system behaviour into code exists. It's called Matlab Simulink.

You are comparing a personal computer with a general purpose OS running 100s of processes and 1000s threads with a small micro-controller with a single process compiled together with an OS running at most a couple of threads. My PC has 100s of apps that need to coexist on the same hardware at the same time, your micro-controller only runs 1 designated app for eternity.

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

#355

Post by nunez »

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…

> 50k line PRs that required a 10-20 line change

This is hilarious. Not when you're the reviewer, of course, but as a bystander, this is expert-level enterprise-grade trolling.

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

#356

Post by gaigalas »

sodapopcan wrote: post #313
gaigalas wrote: post #235

Earlier quoted context omitted.

It does not eliminate code reviews. In practice, you should have at least one independent reviewer who did not actively worked on the PR. That reviewer should also download the entire code, run it, make tests fail and so on. In my experience, it's also good that this is not a fixed role "the reviewer", and a responsability everyone in the team shares (your next task should always be: review someone else's work, only…

> It does not eliminate code reviews. Yes it does. There are many ways to do things, of course, and you can institute that there must be an independent reviewer, but I see this is a colossal waste of time and takes away one of the many benefits of pairing. Switch pairs frequently, and by frequently I really mean "daily," and there is no need for review. This also covers "no fixed responsibilities" you mentioned (whic…

Mixed-level pairs (senior/junior), for example, are more about mentoring than reviewing. Those sessions do not qualify for "more than one pair of eyes".

Excited (or maybe even stubborn) developers can often win their pairs by exhaustion, leading to "whatever you want" low effort contributions.

Pairs tend to under-document. They share an understanding they developed during the pairing session and forget to add important information or details to the PR or documentation channels.

I'm glad it has been working for you. Maybe you work in a stellar team that doesn't have those issues. However, there are many scenarios that benefit a lot from an independent reviewer.

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

#357

Post by ozim »

There is whole range of “proven to work” - regarding testing you cannot prove that there are no bugs.

Your job is to the deliver code up to specifications.

Not even checking the happy flow at least is of course gross negligence. But so is spending too much time on edge cases that no one will run into or person asking doesn’t want to pay for covering.

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

#358

Post by nec4b »

vernrVingingIt wrote: post #265
nkohari wrote: post #236

Earlier quoted context omitted.

> I know exactly what those layers of abstraction are used for. Why so many? Jobs making layers of abstraction. This is a perfect example of Chesterson's Fence. Is it true that there are too many levels of abstraction, that YAML configuration files are a pain in the ass, and so on? Yes. But it's because this stuff was created organically, by thousands of people, over decades of time, and it isn't feasible to just sta…

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.

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

#359

Post by groby_b »

analog31 wrote: post #208
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.

Where are the junior devs while their code is being reviewed? I'm not a software developer, but I'd be loath to review someone's work unless they have enough skin in the game to be present for the review.

I think we've moved on from the times where you brought a printout to the change control board to talk it through.

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

#360

Post by newsoftheday »

agentultra wrote: post #51

There’s an anecdote from one of Djikstra’s essays that strikes at the heart of this phenomenon. I’ll paraphrase because I can’t remember the exact edw number off the top of my head. A colleague was working on an important subsystem and would ask Djikstra for a review when he thought it was ready. Djikstra would have to stop what he was doing, analyze the code, and would find a grievous error or edge case. He would po…

Princess Bride, small excerpt, "Vizzini: You'd like to think that, wouldn't you? You've beaten my giant, which means you're exceptionally strong, so you could've put the poison in your own goblet, trusting on your strength to save you, so I can clearly not choose the wine in front of you." and the dialog goes on with Vizzini dominating it and arguing with himself. In the end, it came down to a coin toss, he picked up a goblet, drank and died.

Anyone who allows a 10K LOC LLM generated PR to be merged without reviewing every single line, is doing the same thing, a coin toss.

Post reply on HN