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

471–480 of 699 posts

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

#471

Post by gopher_space »

stephen_cagle wrote: post #417
theshrike79 wrote: post #395

Earlier quoted context omitted.

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.

You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.

“This person is incurious” would be more apt but also more likely to apply to everyone else in the room too.

Didn’t Bruce Lee famously say he fears the man who’s authored one API in ten thousand different contexts?

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

#472

Post by geodel »

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 =)

Its an epidemic all over in IT departments and s/w industry in general. Nowadays people whose sum total knowledge would be managing some packaged Oracle/SAP software installation are holding title of CTO/SVP/EVP of software organization with thousands of developers.

Since they bring a certain cluelessness and ignorance as honor to whole orgs actual technical expertise among engineers could be detriment to one's jobs and career.

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

#473

Post by 9rx »

otterley wrote: post #440
sunsetMurk wrote: post #377

Earlier quoted context omitted.

Acceptance criteria are often buggy themselves, and require more context to interpret and develop a solution.

If you don't have sufficiently detailed acceptance criteria, how can anyone be expected to write code to satisfy them? That's why you have to start with specifications. See, e.g., https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

I wonder how many more times we'll rebrand TDD (BDD, SDD)?

Just 23 more times? ADD, CDD, EDD, DDD, etc.

Or maybe more?! AADD, ABDD, ACDD, ..., AAADD, AABDD, etc.

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

#474

Post by [deleted] »

9rx wrote: post #473
otterley wrote: post #440

Earlier quoted context omitted.

If you don't have sufficiently detailed acceptance criteria, how can anyone be expected to write code to satisfy them? That's why you have to start with specifications. See, e.g., https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

I wonder how many more times we'll rebrand TDD (BDD, SDD)? Just 23 more times? ADD, CDD, EDD, DDD, etc. Or maybe more?! AADD, ABDD, ACDD, ..., AAADD, AABDD, etc.

[deleted]

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

#475

Post by wiml »

simonw wrote: post #219
Avicebron wrote: post #211

Earlier quoted context omitted.

How are you measuring productivity these days Simon? Do you have a boss that has certain expectations? If you don't hit those are you going to lose your house?

I work for myself, so mainly through guilt and self-doubt.

One of the things LLMs are demonstrably good at is eliminating self-doubt. That's why they're so disastrous.

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

#476

Post by pydry »

9rx wrote: post #473
otterley wrote: post #440

Earlier quoted context omitted.

If you don't have sufficiently detailed acceptance criteria, how can anyone be expected to write code to satisfy them? That's why you have to start with specifications. See, e.g., https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

I wonder how many more times we'll rebrand TDD (BDD, SDD)? Just 23 more times? ADD, CDD, EDD, DDD, etc. Or maybe more?! AADD, ABDD, ACDD, ..., AAADD, AABDD, etc.

BDD is different, it is a way of gathering requirements.

As is, SDD it is some sort of AI nonsense.

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

#477

Post by lokar »

SoftTalker wrote: post #439
lokar wrote: post #421

Earlier quoted context omitted.

Yeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision. And honestly, this will depend on the environment and kind of work being done.

If that's what you're looking for you can find it in academia. Universities have no problem paying people to stay around forever without promotion. Of course the pay won't be great, but the benefits are decent, PTO is usually excellent, and the work environment usually very low stress.

Are we talking about the same thing?

The point of the terminal level rule is that there is a point, bellow which you are not actually contributing all that much more in output then it takes to supervise and mentor you. At some point you need to be clearly net positive. This generally means you can mostly operate on your own.

If it becomes clear you won't make it to that level, then something is wrong. Either you are not capable, or not willing to make the effort, or something else. Regardless, you get forced out.

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

#478

Post by wiml »

babarock wrote: post #404
simonw wrote: post #44

Earlier quoted context omitted.

100%. There's no difference at all in my mind between an AI-assisted PR and a regular PR: in both cases they should include proof that the change works and that the author has put the work in to test it.

You're not wrong, however the issue is that it's not always easy to detect if a PR includes proof that the change works. It requires that the reviewer interrupts what they're doing, switch context completely and look at the PR. If you consider that reviewer bandwidth is very limited in most projects AND that the volume of low-effort-AI-assisted PR has grown incredibly over the past year, now we have a spam problem. S…

I don't think we're talking about merely "AI-assisted" PRs here. We're talking about PRs where the submitter has not read the code, doesn't understand it, and can't be bothered to describe what they did and why.

As a reviewer with limited bandwidth, I really don't see why I should spend any effort on those.

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

#479

Post by ChrisMarshallNY »

In my last job (engineering manager for a Japanese high-Quality hardware manufacturer), we were expected to deliver software that works.

In fact, if any bugs were found by the official "last step" QA Department, we (as a software development department) were dinged. If QA found bugs, they could stop the entire product release, so you did not want to be responsible for that.

This resulted in each software development department setting up their own, internal "QC team" of testers. If they found bugs, then individual programmers (or teams) would get dinged, but the main department would not.

Our software got a lot of testing.

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

#480

Post by lokar »

jghn wrote: post #401
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…

The important thing here is for people to understand that at best titles only indicate relative rank within a company. And even then that's tenuous. Titles are effectively meaningless when comparing outside of a company.

You get (finite) periods where several large / influential companies have a reasonably high level of rigor for their own levels, and there is a pretty stable mapping between the companies.

One such period seems to have ended sometime around the start of Covid, or a bit before.

Post reply on HN