Live data from Hacker News

Your job is to deliver code you have proven to work

simonwillison.net

381–390 of 699 posts

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

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

Title inflation?

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 the first year performance review.

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

#382

Earlier quoted context omitted.

> pseudo-enlightenment one gets from psychedelics I like that, I’ve also heard it referred to as “unearned wisdom”

You all really believe PhDs and principle hardware engineers at Samsung, nVidia, etc have not worked around any abstract problem you all can come up with? We need a layer of abstraction not endless layers. Nothing says unearned wisdom than script kiddies who intentionally had money thrown at them to reinforce belief their mastery of RoR CRUD app dev is genius beyond all comprehension. Zomg you know Linux admin? Here'…

The way you make such broad assumptions and jump right into highly charged politics with nary a connection really does make me wonder about your emotional well being.

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

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

Since we can't really formally prove most code, I think property based testing such as with hypothesis[1] would make sense. I have not used it yet, but am about to for stuff that really needs to work.

[1] https://news.ycombinator.com/item?id=45818562

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

#385

Earlier quoted context omitted.

Yep. Remember, people not posting on this website are just grinding away at jobs where their individual output does not matter, and entire motivation is work JUST hard enough not to get fired. They don't get stock grants, extremely favorable stock options or anything else, they get salary and MAYBE a small bonus based off business factors they have little control over. My eyes were wide open when 2 jobs ago, they sai…

They don't have phones?

They do but obviously laptop is easier than doing it on their phone. That’s what most of them ended up doing.

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

#386

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

> Strong disagree here, your job is to deliver solutions that help the business solve a problem.

Sure. That is every job though. It is interesting to muse on. Hard for us to solve a problem without a computer (or removing one!)

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

#387

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

> In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned That is an insane distinction that you are trying to do there. In which cases delivering code that doesn't satisfy the requirements would solve a business problem?

When you can ship Redis for example instead of rolling your own cache.

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

#388

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

A senior dev should be mentoring and talking to a junior dev about a task well before it hits the review stage. You should discuss each task with them on a high level before assigning it, so they understand the task and its requirements first, then the review is more of a formality because you were involved at each step.

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

#390

Earlier quoted context omitted.

Yep, that's why very accomplished, widely regarded developers like Mitchell Hashimoto and Antirez use them. They need to make programming more challenging to keep it fun.

[flagged]

Mitchell shares the Amp threads on how he delivered some smaller features/fixes.
Post reply on HN