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

601–610 of 699 posts

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

#601

Post by baq »

Aeolun wrote: post #589
rootusrootus wrote: post #446

Earlier quoted context omitted.

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.

Why would you are about blank lines? Sounds like aborted attempts at a change to me. Then realizing you don’t need them. Seeing them in your PR, and figuring they don’t actually do anything to me.

More likely artifact of debug prints being removed.

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

#602

Post by baq »

bee_rider wrote: post #574
osn9363739 wrote: post #507

Earlier quoted context omitted.

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…

GPT 5+ high+ review bots find consistently good issues on average for me, sometimes they’re bogus, but sometimes they’re really, really good finds. I was impressed more than once.

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

#603

Post by rglynn »

theshrike79 wrote: post #426
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…

I've had calls with Principal Architects who couldn't code themselves out of a wet paper bag. And according to the company experience chart, they should've been a "thought leader" and "able to instruct senior engineers" My title? Backend Programmer (20 years of experience). Our unit didn't care about titles because there was a "budget" for title upgrades per business unit and guess which team grabbed all of them =)

How many civil engineers or architects know how to put up scaffolding or lay bricks?

That was a little tongue in cheek, but I am genuinely curious what you think the correct approach is? I have seen many teams that do need to have someone overseeing the overall architecture, even if that person isn't writing the code line-by-line.

If you have that capacity baked into "Backend Programmer", then great, but not every team is the same.

Is there something inherently wrong with an "architect" who hasn't written code in a decade but is instructing seniors? One might believe that the answer is self-evident, however, I would argue that the organisational structures we see in the world (functional or otherwise) do not bear this out.

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

#604

Post by baq »

vernrVingingIt wrote: post #465
nec4b wrote: post #354

Earlier quoted context omitted.

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.

Sure. The hang up here is SWEs belief those abstractions must be stored as some syntax they know; C, Python, RoR, Linux, Elixir... whatever. There is zero obligation to capture the concept of memory safety in traditional software notation. If it was possible to look inside the hardware at runtime no one is going to see Rust syntax. At runtime it's more appropriate to think of it as geometric functions redrawing elect…

> The hang up here is SWEs belief those abstractions must be stored as some syntax they know

Contracts need to be written down to be effectively enforced. We don’t like a he said she said in software, right?

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

#605

Post by baq »

vlowther wrote: post #365
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.

DOS, early Windows, and early MacOS worked more or less exactly that way. Somehow, we all survived.

MS Word had to be rewritten from ~scratch to get rid of a document losing crash. Yes, we survived, but at what cost?

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

#606

Post by simianwords »

newsoftheday wrote: post #332
simianwords wrote: post #255

Earlier quoted context omitted.

I would like to challenge this claim. I think LLMs are maybe accurate enough that we don't need to check every line and remember everything. High level design is enough.

My jaw hit the table when I read that. Just checking here but, are you being serious?

I absolutely believe this and follow what I said to an extent. You don't need to triple check every line of code and deeply understand what it has done - just the highlevel design.

I usually skim through the code (spot some issues like are they using modern version of language?), check the high level design like which interfaces and do manual testing. That is more than enough.

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

#607

Post by simianwords »

abathur wrote: post #318
simianwords wrote: post #255

Earlier quoted context omitted.

I would like to challenge this claim. I think LLMs are maybe accurate enough that we don't need to check every line and remember everything. High level design is enough.

I've been tasked with doing a very superficial review of a codebase produced by an adult who purports to have decades of database/backend experience with the assistance of a well-known agent. While skimming tests for the python backend, I spotted the following: @patch.dict(os.environ, {"ENVIRONMENT": "production"}) def test_settings_environment_from_env(self) -> None: """Test environment setting from env var.""" from…

If it is so obvious to you that there is a smell here then an agent would have caught it. Try it yourself.

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

#608

Post by user34283 »

ozozozd wrote: post #570
user34283 wrote: post #563

Earlier quoted context omitted.

There's a lot of functionality in the frontend that I am building that I did not review. If it worked in testing, that's good enough. You're free to review every line the model produces. Not every project is in healthcare or defense, and sometimes different standards apply.

I’m assuming you work in a setting where there is a QA team? I haven’t been in such a setting in 2008 so you can ignore everything I said. But I wouldn’t want to be somewhere where people don’t test their code, and I have to write code that doesn’t break the code that was never tested until the QA cycle?

No, in my day job I obsess over every line I add, although there is QA.

In my side project I'm building a frontend that, according to me, is the best looking and most feature rich option out there.

I find that I'm making great progress with it, even when I don't know every line in the project. I understand the architecture and roughly where what functionality is located, and that is good enough for me.

If in testing I see issues with some functionality, I can first ask the model to summarize the implementation. I can then come up with a better approach and have the model make the change. Or alternatively I edit some values myself. So far it wasn't often that I felt the need to write more than a few lines of code manually.

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

#609

Post by dayjaby »

theshrike79 wrote: post #538
ChrisMarshallNY wrote: post #534

Earlier quoted context omitted.

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome. It will usually home right in on the bug, or will give me a good starting point. It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed. I've probably done that at least a dozen times, today. I…

I've completed actual features by saying "look up issue ABBA-1234 and create a plan to implement it" to Claude. Then I wait, look through the plan and tell it to implement and go do something else. After a while I check the diffs and go "huh, yea, that's how I would've done it too", commit and push.

In 10 years this will be a "that's how I would've done it 10 years ago too...or?? I don't remember"

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

#610

Post by Ekaros »

jopsen wrote: post #274
tyrust wrote: post #243

Earlier quoted context omitted.

Code review is rarely done live. It's usually asynchronous, giving the reviewer plenty of time to read, digest, and give considered feedback on the changes. Perhaps a spicy patch would involve some kind of meeting. Or maybe in a mentor/mentee situation where you'd want high-bandwidth communication.

Doing only IRL code reviews would certainly improve quality in some projects :) It's probably also fairly expensive to do.

I would guess that 3 part code review would actually be most effective. Likely even save on costs. First part is walkthrough on call, next independent review and comments. Then per need an other call over fixes or discussion.

Probably spend more time on it, but would share the understanding and alignment.

Post reply on HN