Live data from Hacker News

Your job is to deliver code you have proven to work

simonwillison.net

541–550 of 699 posts

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

#541
It comes out of the AI, that is proof enough. Why would I have prompted it and gave it to you if I didn't think that the AI could handle it? The real risk is closer to "people carry some preconceived notion about code that doesn't map to AI code." such as, for example, the person who contributed the code knows about the problem in enough detail to be accountable in the short term. Or at the very least be able to tell you why they made a PR at all

How to prove it has been subject to some debate for the past century, the answer is that it's context dependent to what degree you will or even can prove the program and exposed identifiers correct. Programming is a communication problem as well as a math problem, often an engineering problem too. Only the math portion can be proved, the a small by critical amount engineering portion tested.

Communication is the most important for velocity it's the difference between hand rolling machine code and sshing into a computer halfway across the world having every tool you expect. If you don't trust that webdevs know what they are doing then you can be the most amazing dev in the world you but your actual ability to contribute will be hampered. The same is true of vibe coding, if people aren't on the same page as to what is and isn't acceptable velocity starts to slow down.

Languages have not caught up to AI tools, since AI operates well above the function level, what level would be appropriate to be named and signed off on? pull request and link to the chat as a commit? (what is wrong with that that could be fixed at the name level)

Honest communication is the most important. Amazon telling investors that they use TLA+ is just signaling that they "for realz take uptime very seriously guize", "we know distributed systems" and engineering culture. The honest reality is that they could prove all their code and not IMprove their uptime one lick, because most of what they run isn't their code. It's a communication breakdown if effort gets spent on that outside a research department.

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

#542
post #520

Earlier quoted context omitted.

New career path unlocked — reverse prompt engineering — trying to determine what someone prompted the AI given the slop they put into a ticket

Plot twist: this universe (planet) was created in order to reverse engineer what the prompt of the previous one was.

It's not that much of a twist, given that it was basically the plot of THGTTG.

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

#543

Earlier quoted context omitted.

Your manager should be on their ass for wasting your time.

Worse yet, these were done by the managers of the Marketing team and the Mapping team. Plus, these are high profile issues that (somehow) required getting the CEO involved too! (Obviously there is a lot of dysfunction in our organization, lol.)

[deleted]

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

#544
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'm not either But LLMs don't really perform well enough on our codebase to allow you to generate things that even appear to work. And I'm the most junior member of my team at 37 years of age, hired in 2019. I really tried to follow the mandate from on high to use Copilot, but the Agent mode can't even write code that compiles with the tools available to it. Luckily I hooked it up to gptel so I can at least ask it qu…

> And I'm the most junior member of my team at 37 years of age

This sounds fucking awesome.

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

#545

> 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.

There's no distinction there, proving the work is correct is within the scope of helping the business solve a problem; not without and not beside it. So your point is hot air, making a distinction where none exists.

The distinction does matter. Requirements can be and often are wrong when the rubber meets the road. If the cost of implementing requirements correctly is $1,000,000 and the value of the product is $1000 then even choosing to clarify requirements has failed the business. The non failure mode here is to write the code for less than $1,000. Even if the code doesn't work at all!

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

#546
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…

Came to leave the same comment. It’s very possible to deliver code that’s proven to work, that is still shit.

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

#547
post #152

Earlier quoted context omitted.

I would bet in most organizations you can find a copy-pasted version of the top SO answer for email regex in their language of choice, and if you chase down the original commit author they couldn't explain how it works.

I think it's impossible to actually write an email regex because addresses can have arbitrarily deeply nested escaping. I may have that wrong. I'd hope that regex would be .+@.+ and that's it (watch me get Cunninghammed because there is some valid address wherein those plusses should be stars).

TIL Cunningham's Law[0]. I knew about that phenomenon but not the proper name. Thanks!

[0] https://en.wikipedia.org/wiki/Ward_Cunningham#Law

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

#548
post #416
post #411

Earlier quoted context omitted.

> IMO tech suffers pretty horrible title inflation It began with "software engineer "

Don't get me started on "software architect".

On classic big waterfall projects, you can find actual architects. Those are the ones drafting interfaces and delineating components/teams before the first source file is even committed.

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

#549
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…

if your tests cover the acceptance criteria as defined in the ticket, why is all htat other stuff necessary?

Because AC don’t cover non-functional things like maintainability/understandability, adherence to corporate/team standards etc.

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

#550

Earlier quoted context omitted.

Complaining about including a ticket number in the commit is a new one for me. Good grief.

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…

> The branch itself gets created with the ticket number and everything follows from that, there's no extra effort.

Only problem there is the potential for a deeply-ingrained assumption that the Jira key being in the branch name is sufficient for the traceability between the Jira issue and commits to always exist. I've had to remind many people I work with that branch names are not forever, but commit messages are.

Hasn't quite succeeded in getting everyone to throw a Jira ID in somewhere in the changeset, but I try...

Post reply on HN