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

481–490 of 699 posts

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

#481

Post by johnea »

I couldn't agree more with the sentiment.

If you, the development engineer, haven't demonstrated the product to work as expected, and preferably this testing is independently confirmed by a product test group, then you can't claim to be delivering a functional product.

I would add though, that management, specifically marketing management setting unreasonable demands and deadlines, are a bigger threat to testing than LLMs.

Of course the damage done by LLM generated code not being tested, is additive to the damage management is doing.

So this isn't any kind of apologism, the two sources are both making the problem worse.

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

#483

Post by ChrisMarshallNY »

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.

I'm constantly working on stuff I don't know (the Xcode window behind this browser window is full of that kind of code). I have found LLMs are a great help in pushing the boundaries.

It's humbling, but I do tend to pick up a lot of stuff.

https://littlegreenviper.com/miscellany/thats-not-what-ships...

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

#484

Post by otterley »

pydry wrote: post #476
9rx wrote: post #473

Earlier quoted context omitted.

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.

Developers who aren't yet using AI would benefit from specs as well. They're good to have whether it's you or an LLM that's writing code. As a general rule, the clearer and less ambiguous the criteria you have, the better.

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

#485

Post by chasd00 »

tete wrote: post #396
vladsh wrote: post #309

We should get back to the basic definition of the engineering job. An engineer understands requirements, translates them into logical flows that can be automated, communicates tradeoffs across the organization, and makes tradeoff calls on maintainability, extensibility, readability, and security. Most importantly, they’re accountable for the outcome, because many tradeoffs only reveal their cost once they hit reality…

Okay, then software engineers are not engineers. The whole reliability, etc. to many is not of much priority. Things got an absolutely shitshow and still everyone buys it. In other words the only outcome will be that people don't have or don't want to have engineers anymore. Companies are very much not interested in someone who does the above, but at most someone who sells or cosplays these things - if even. Cause th…

> I believe what we need to wake up to or come to terms with is that our industry (everything that would go into NASDAQ) is a farce.

the thing is, with software development, it's always been this way. Developers have just had tunnel vision for decades because they stare into an editor all day long instead trying to actually sell a product. If selling wasn't the top priority then what do you think would happen to your direct deposit? Software developers, especially software developers, live in this fantasy land where the believe their paycheck just happens automatically and always will. I think it's becoming critical that new software devs entering the workforce spend a couple years at a small, eat what you kill, consultancy or small business. Somewhere where they can see the relationship between building, selling, and their paycheck first hand.

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

#486

Post by jobs_throwaway »

ChrisMarshallNY wrote: post #479

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…

What does 'get dinged' mean? It seems like this would lead to a strong incentive against making any changes, lest you introduce bugs, perhaps due to no fault of your own.

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

#487

Post by lokar »

CodeMage wrote: post #459
SoftTalker wrote: post #439

Earlier quoted context omitted.

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.

FWIW, I'm starting to seriously consider this as a strategy that will allow me to get to retirement without completely messing up my health due to stress and burnout. That said, there's something deeply wrong with our industry if that's the way we expect things to work. I never felt that teaching was my calling, but I might end up being forced into it anyway and taking up a job that someone with proper passion and vo…

But the point of the rule is that unlimited growth is not expected. There is a fairly clear point you need to get to, and then you can stay put if you like.

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

#488

Post by 3acctforcom »

xnx wrote: post #368
endorphine wrote: post #104

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

Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.

Titles in of themselves are meaningless, I've seen a kid hired straight from uni into a "senior" position lol

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

#489

Post by 3acctforcom »

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.

Ops vs Dev

Situational Leadership gets into this. You want a really efficient McDonalds worker who follows the established procedure to make a Big Mac. You also want a really creative designer to build your Big Mac marketing campaign. Your job as a manager is figuring out which you need, and fitting the right person into the right job.

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

#490

Post by [deleted] »

lokar wrote: post #480
jghn wrote: post #401

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN