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

531–540 of 699 posts

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

#531

Post by theshrike79 »

BadCookie wrote: post #436
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.

Maybe, but the typical person I have worked with in this industry is too smart to do something for 10 years and not learn much during that time. I am afraid that this “1 year of experience 10 times” mantra gets trotted out to justify ageism more often than not.

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 nights and weekends. It's just a day job for them that pays for their non-programming hobbies.

I've had colleagues who managed the same ASP+Access DB system for almost a decade, with zero curiosity or interest to learn anything that wasn't absolutely necessary.

We had to drag them to the ASP.NET age, one just wouldn't and stayed back managing the legacy version until all clients had moved to the new stack.

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

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

#532

Post by theshrike79 »

ChrisMarshallNY wrote: post #483
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.

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

There are a definitely few ulcer-inducing events in my past that would've taken me an afternoon to fix with a current SOTA LLM vs 2+ weeks of swearing, crying and stressing out.

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

#533

Post by theshrike79 »

abustamam wrote: post #497
3acctforcom wrote: post #489

Earlier quoted context omitted.

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.

Agreed. Meanwhile, many job postings out there looking for 10x full-stack developers who have deep experience in database, server, front end, devops, etc. I think the concept of Full-stack dev is fine, but expecting them to know each part of the stack deeply isn't feasible imo.

Expert Generalists are a thing: https://martinfowler.com/articles/expert-generalist.html

BUT they're completely wasted if you just use them to turn JIRA tickets into end to end features =)

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

#534

Post by ChrisMarshallNY »

theshrike79 wrote: post #532
ChrisMarshallNY wrote: post #483

Earlier quoted context omitted.

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

There are a definitely few ulcer-inducing events in my past that would've taken me an afternoon to fix with a current SOTA LLM vs 2+ weeks of swearing, crying and stressing out.

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome.

It will usually home right in on the bug, or will give me a good starting point.

It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed.

I've probably done that at least a dozen times, today. I guess I'm a rotten programmer.

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

#535

Post by WalterBright »

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.

I once asked an obstetrician how she could tell the sex of a fetus with those ultrasound blobs. She laughed and said she'd seen 50,000 of those scans.

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

#536

Post by beautiful_zhixu »

duxup wrote: post #449
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.

It’s always the developers who can break / bypass the rules who are the most dangerous. I always think of the "superstars" or "10x" devs I have met at companies. Yeah I could put out a lot of features too if I could bypass all the rules and just puke out code / greenfield code that accounts for the initial one use case ... (and sometimes even leave the rest to other folks to clean up).

[dead]

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

#537

Post by theshrike79 »

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.

If we extrapolate the Dr example:

There is the one doctor who learned one way to do the operation at school, with specific instruments, sutures etc. and uses that for 1000 surgeries.

And then there's the curious one who actively goes to conferences, reads publications and learns new better ways to do the same operation with invisible sutures that don't leave a scar or tools that are allow for more efficient operations, cutting down the time required for the patient to be under anaesthesia.

Which one would you hire for your hospital for the next 25 years?

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

#538

Post by theshrike79 »

ChrisMarshallNY wrote: post #534
theshrike79 wrote: post #532

Earlier quoted context omitted.

There are a definitely few ulcer-inducing events in my past that would've taken me an afternoon to fix with a current SOTA LLM vs 2+ weeks of swearing, crying and stressing out.

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome. It will usually home right in on the bug, or will give me a good starting point. It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed. I've probably done that at least a dozen times, today. I…

I've completed actual features by saying "look up issue ABBA-1234 and create a plan to implement it" to Claude.

Then I wait, look through the plan and tell it to implement and go do something else.

After a while I check the diffs and go "huh, yea, that's how I would've done it too", commit and push.

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

#539

Post by 9rx »

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

Earlier quoted context omitted.

The scare quotes are significant. Obviously nobody can ever see it all as taken in its most literal sense. But one can start to see enough that they can recognize the patterns. If your job is dependent on the weather, one year might be rainy, one year might be drought, one year might be a flood, etc. You need to see them to understand them. But eventually you don't have to need to see the year where it is exceptional…

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 Typescript, now has some concept of verification and can start to recognize some of the tradeoffs in the different approaches. With that past experience in hand, they can begin to consider if the new project in front of them needs Rocq, Dafny, or if Javascript will do. Couple that with other types of experiences to draw from and you can move beyond being considered a "junior".

> You might be able to have "seen it all" in a tiny corner of tech

Of course there being a corner of some sort is a given. We already talked about management being a different corner, for example. Having absolutely no experience designing a PCB is not going to keep you a "junior" at a place developing CRUD web apps. Obviously nobody is talking about "seeing it all" as being about everything in the entire universe. There aren't that many different patterns, really, though. As the terms are used, you absolutely can "see it all", and when you don't have to wait around for the season to return next year, you can "see it all" quite quickly.

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

#540

Post by neighbour »

SoftTalker wrote: post #374
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.

Title inflation?

I'm sympathetic to the title inflation issue but more on the problem of the "engineer" title, not to mention the "scientist" title.

For example, I work in Data & AI and we have:

- data engineer

- analytics engineer

- data scientist

- AI engineer

What I don't know is what's the alternative?

Data Engineers are basically software developers.

Analytics Engineers were Data Analysts or BI Analysts but the job has changed so much that neither of those titles fit.

My opinion is that basically everyone should just be a "Developer" or "Programmer" and then have the area suffixed:

- Data Engineer → Developer (Data Infrastructure)

- Analytics Engineer → Developer (Analytics)

etc.

Post reply on HN