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

661–670 of 699 posts

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

#661

Post by theshrike79 »

disgruntledphd2 wrote: post #622
theshrike79 wrote: post #531

Earlier quoted context omitted.

Depends a lot on the type of software you're doing. Startups will have hungry people willing to learn, more traditional companies won't in the same percentages. Not all people are curious, they go to school, learn to code and work their job like a normal 9-5 blue collar worker. They go to company trainings, but they don't read Hacker News, don't follow the latest language fads or do personal software projects during…

> ...and I just checked LinkedIn, the non-curious ones are still in the same company, managing the same piece of SaaS as a Software Developer. 20-26 years in the same company, straight from school. And honestly, this should be OK. For a lot of people, they work to put food on the table and keep a roof over their head, and our society is structured like this for whatever reasons. Not everyone needs to be learning and…

Some people’s brains are just wired for that.

There are people who are just fine being a cog in a machine doing the same thing all day for years on out.

My family is from a factory town and many of them were literally standing next to a conveyor doing a monotonic task that could’ve done by a robot.

I tried it for one summer job and my brain almost melted from the boredom and monotony.

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

#662

Post by filoeleven »

baq wrote: post #602
bee_rider wrote: post #574

Earlier quoted context omitted.

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.

This response fails entirely to answer the question.

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

#663

Post by wizzwizz4 »

lcnPylGDnU4H9OF wrote: post #582
wizzwizz4 wrote: post #564

Earlier quoted context omitted.

Believing you know how it works and why it works is not the same as that actually being the case. If the code has no author (in that it's been plagiarised by a statistical process that introduces errors), there's nowhere to go if you realise "oops, I didn't understand that as well as I had thought!".

> If the code has no author ... there's nowhere to go if you realise "oops, I didn't understand that as well as I had thought!" That's also true if I author the code myself; I can't go to anyone for help with it, so if it doesn't work then I have to figure out why. > Believing you know how it works and why it works is not the same as that actually being the case. My series of accidental successes producing working co…

> so if it doesn't work then I have to figure out why.

But it's built on top of things that are understood. If it doesn't work, then either:

• You didn't understand the problem fully, so the approach you were using is wrong.

• You didn't understand the language (library, etc) correctly, so the computer didn't grasp your meaning.

• The code you wrote isn't the code you intended to write.

This is a much more tractable situation to be in than "nobody knows what the code means, or has a mental model for how it's supposed to operate", which is the norm for a sufficiently-large LLM-produced codebase.

> My series of accidental successes

That somewhat misses the point. To write working code, you must have some understanding of the relationship between your intention and your output. LLMs have a poor-to-nonexistent understanding of this relationship, which they cover up with the ability to regurgitate (permutations of) a large corpus of examples – but this does not grant them the ability to operate outside the domain of those examples.

LLM-generated codebases very much do not lie within that domain: they lack the clues and signs of underlying understanding that human readers and (to an extent) LLMs rely on. Worse, the LLMs do replicate those signals, but they don't encode anything coherent in the signal. Unless you are very used to critically analysing LLM output, this can be highly misleading. (It reminds me of how chess grandmasters blunder, and struggle to even remember, unreachable board positions.)

Believing you know how LLM-generated code works, and why it works, is not the same as that actually being the case – in a very real sense that is different to that of code with human authors.

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

#664

Post by maerF0x0 »

IMTDb wrote: post #302
maerF0x0 wrote: post #286

> The first is manual testing. If you haven’t seen the code do the right thing yourself, that code doesn’t work. If it does turn out to work, that’s honestly just pure chance. Depending on exactly what the author meant here, I disagree. Our first and default tool should be some form of lightweight automated testing. It's explicit (serves a form of spec and docs how to use the software), it's repeatable (manual testin…

> Our first and default tool should be some form of lightweight automated testing Manual verification isn't about skipping tests, it's about validating what to test in the first place. You need to see the code work before you know what "working" even means. Does the screen render correctly? Does the API return sensible data? Does the flow make sense to users? Automated tests can only check what you tell them to check…

I suppose we could be talking circles around eachother, but I'd say many of what you've suggested as manual tests could be codified into an automated test just as easily.

Manual: `curl localhost:8080 | jq .` or whatever, brings value once.

Automated: `assert.ValidJSON(req.Body)` is basically identical, but can be repeated over and over again

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

#665

Post by necovek »

sodapopcan wrote: post #631
necovek wrote: post #629

Earlier quoted context omitted.

Pairing people together on a single task makes that task get done faster, with higher quality. However, when paired together, the people still pick up some of the same biases and hold the same assumptions and context, so it is really worse than having a single author + independent reviewer. So: single author, no review

Again, if you rotate pairs daily this doesn't happen. You could argue that creates a "team bias" but I call that cohesion.

Can you elaborate?

Is this pairing on small tasks that get done in (less than) a day? Or do you also have longer-running implementations (a few days, a week, or maybe even more?) where you rotate the people who are on it (so one task might have had 5 or 10 people on it during the implementation)?

If the latter, that sounds very curious and I'd love to learn more about how is that working, how do people feel about it, what are the challenges you've seen, and what are the successes? It'd be great to see a write-up if you've had this running for a longer time!

If it's only the former (smaller tasks), then this is where biases and assumptions stay (within the scope of that task): I still believe this is improved with an independent reviewer.

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

#667

Post by lcnPylGDnU4H9OF »

wizzwizz4 wrote: post #663
lcnPylGDnU4H9OF wrote: post #582

Earlier quoted context omitted.

> If the code has no author ... there's nowhere to go if you realise "oops, I didn't understand that as well as I had thought!" That's also true if I author the code myself; I can't go to anyone for help with it, so if it doesn't work then I have to figure out why. > Believing you know how it works and why it works is not the same as that actually being the case. My series of accidental successes producing working co…

> so if it doesn't work then I have to figure out why. But it's built on top of things that are understood. If it doesn't work, then either: • You didn't understand the problem fully, so the approach you were using is wrong. • You didn't understand the language (library, etc) correctly, so the computer didn't grasp your meaning. • The code you wrote isn't the code you intended to write. This is a much more tractable…

> "nobody knows what the code means, or has a mental model for how it's supposed to operate"

> Believing you know how LLM-generated code works, and why it works, is not the same as that actually being the case

This is a strawman argument which I'm not really interested to engage. You can assume competence. (In a scenario where one doesn't make these mistakes, what's left in your argument? It is a sufficiently strong claim to say these cannot be avoided such that it is reasonable to dismiss the claim unless supporting evidence is provided. In other words, the solution is as simple as not making these mistakes.) As I wrote up-thread, including the code is a choice and one should be mindful of it.

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

#668

Post by igouy »

jodrellblank wrote: post #466
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.

> " Why are we wasting so much time on abstractions like .. objects? " Aside: earlier this year Casey Muratori did a 2.5 hour conference talk on this topic - why we are using objects in the way they are implemented in C++ et al with class hierarchies and inheritance and objects representing individual entities? " The Big OOPs: anatomy of a 35 year mistake "[1]. He traces programming history back to Stroustrup learnin…

The previous HN comments are interesting.

https://news.ycombinator.com/item?id=44612313

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

#669

Post by fuzztester »

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.

My dad mentioned the same anecdote to me long ago, except that the context was manufacturing, and the number of years was 20, not 10.

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

#670

Post by andrewaylett »

9rx wrote: post #539
Yoric wrote: post #499

Earlier quoted context omitted.

In my experience, not really, no. You need a very different mindset to write in JS (or TS), in Rust, in Rocq, in Esterel or on a Quantum Computer. You need a very different mindset when coding tools that will be deployed on embedded devices, on user's desktops, in the Linux kernel, on a web backend or in a compiler. You need a very different mindset when dealing with open-source enthusiasts, untrusted users, defense…

> You need a very different mindset to write in JS (or TS), in Rust, in Rocq, in Esterel or on a Quantum Computer. "Senior", "principle", etc. are not about your ability to write. They speak to one's capacity to make decisions. A "junior" has absolutely no clue when to use JS, Rust, or Rocq, or if code should be written at all. But someone who has written (well-written) tests in JS, and maybe written some types in Ty…

In my experience, levels are more a question of delivery and trust than of technical skill. If a Senior is off down a rabbit hole, that's them doing their job. It's almost a defining feature of the level down (SE2, or local equivalent) that if they're off down a rabbit hole then something's probably gone wrong somewhere: if you could trust their judgement, they'd be a senior already.

(Yes, that's circular and overly reductive, don't take it too literally)

Where I've worked, "senior" has also meant being a final authority: more junior folk will come to you with questions about your team's codebases, and more senior folk will too. You might not have anyone else to ask that kind of question of.

Post reply on HN