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.

You want the Dr who has done the operation 10 times, and learned something each time, and incorporated that into their future efforts. You probably don’t want a Dr who will do their 11th surgery on you exactly the way they did the first.

This is what that saying is about

Fair enough. I guess I am making a bit of a straw-man in that I feel I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years. They are signals, and depending on what we are attempting, they just mean different expected outcomes. One isn't necessarily worse than another, but in this case it seems to be implying it is the distinction between Midlevel and Senior.

> I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years.

I always read it as making the same mistakes as you initially did and either failing to learn from them or not even trying to improve. Maybe you haven’t even explored enough approaches to see what actually works and what doesn’t and most importantly, in which circumstances.

For example, someone might do CI/CD with manually created pipelines in Jenkins (the web UI variety) with stuff like JDK configured directly on the runner nodes. They might never have written a Jenkinsfile, or tried out Docker for builds and therefore are slow and have to deal with brittle plugins and environment configuration. They might also be unaware of how GitHub Actions could benefit them, or the more focused approach of GitLab CI or even how nice Woodpecker CI can be, especially for simpler setups.

>Fair enough. I guess I am making a bit of a straw-man in that I feel I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years.

Different things doesn't need to mean "different domains" which is how you read it.

It can be "things revealing different aspect/failure cases of the same domain" too.

If someone has done the same narrow kind of CRUD app 10 times, they're not CRUD-app experts - they never seen lots of different aspects of CRUD apps.

I want the doctor who has performed the operation and was still with the hospital in 6m, 12m, 18m, 24m to see the results of the operations that they performed.

Not the one who does a few operations and is never around to see the results of their decisions and actions.

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

Haha agreed. Thanks for the link, will give it a read. I feel like expert generalists should be founders or CTOS, and they are probably not applying for the positions that claim to be wanting expert generalists.

“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?

for context, he was referring to a physical methodology, which requires a lot of training and knowledge of usage application.

As analogy, I don't think you'd treat "using API XYZ 10,000 times" the same as "serving an ace in tennis, 10,000" times.

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.

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?

The one with the smaller cemetery.

This is not really a doctor that has done the same operation 10 times. This is a doctor that jumped form hospital to hospital 10 times and probably never actually stayed long enough to be entrusted to do an operation in any hospital.

My favourite saying is: "dumb people get old too".

When interviewing candidates I'm always shocked and a little depressed talking to someone with a pumped up resume and 15 years in the field when I realize they can't do much at all.

Yeah, I run into this a lot too, hah. It's depressing but also pretty funny when you've got enough distance from it. My favorite was an ex-girlfriend working in HR interviewed a candidate with 15 years of experience, and was told to ask him to solve FizzBuzz in a language of his choice.

(This is obviously a silly test for various reasons, but she was following orders.)

She called me later that day because the guy couldn't do it, so he instead blew the fuck up at HR and accused them of ambushing him with a super complex interview question. From his reaction, she thought that the company had tricked her into making totally unreasonable demands of someone who hasn't had a month to prepare.

God knows what the hell that guy did at his previous role.

PS: I have laughed every time I've seen your username for the past year, and can't remember if I've told you this before.

> PS: I have laughed every time I've seen your username for the past year, and can't remember if I've told you this before.

You haven't but thanks :D

Jean-Lukewarm Picard, they call him

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.

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.

In 10 years this will be a "that's how I would've done it 10 years ago too...or?? I don't remember"

There's a gut feeling that comes from having gotten your hands dirty enough that tells you if the LLM is being smart or spitting out bullshit.

The main issue I have with LLM-generated solutions, is that LLMs never seem to know about “Occam’s Razor.”

Their solution usually benefits from some simplification.

I feel like ive been stuck in that cycle, and I know its partially just me being in my head about my career, but I really have been basically doing CRUD apps for a decade. Ive made a lot of front end forms, Ive kept up on the latest frameworks and trends, but at the core it really hasnt been dramatically different.

If you really distill it, I've been doing API Glue for about a quarter century.

I connect to a 3rd party API with shitty specs and inconsistent output that doesn't follow even their spec, swear a bit and adjust my estimates[0]. Do some business stuff with it and shove it to another API.

But I've done that now in ... six maybe seven different languages and a few different frameworks on top of that. And because both sides of the API tend to be a bit shit, there's a lot of experience in defensive coding and verification - as well as writing really polite but pointed Corporate Emails that boil down to "it's your shit that's broken, not ours, you fix it".

At this point I really don't care what language I have to use, as long as it isn't Java (which I've heard has come far in the last decade, but old traumas and all that =).

[0] best one yet is the Swedish "standard" for electricity consumption reports, pretty much every field is optional because they couldn't decide and wanted to please every company in on the project. Now write a parser for that please.

another 'anyone but Java' developer! For me its not even the language or syntax, its the way people code it. Not every line of python ive ever read is gold, but every time i delve into Java code its like the developer was mad, at me specifically.

Reminds me of something I heard at a conference to the effect "10-15 years of <tool> experience is usually a red flag because the only people that have that have been pressing <tool run> button over and over again learning nothing"

My dad mentioned the same anecdote to me long ago, except that the context was manufacturing, and the number of years was 20, not 10.

Experience is knowledge of what not to do.

It's the old saying: "$10 for the part, $990 for knowing where to put it"

You get a feel for what works and what doesn't, provided you know the relevant facts. Doing a 10RPS system is completely different than 300RPS. And if the payload is 1kB the problems aren't the same as with the one with a 10MB payload.

And if (when) you're using a cloud environment, which one is cheaper, large data or RPS? It's not always intuitive. We just had our AWS reps do a Tim "The Toolman" Taylor "HUUH?!" when we explained that the way our software works is 95% cheaper to run using S3 as the storage rather than DynamoDB :D

True. I remember myself spending weeks just to figure out what not to do next because I can't afford a redo.

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.

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

And honestly, this should be OK. For a lot of people, they work to put food on the table and keep a roof over their head, and our society is structured like this for whatever reasons.

Not everyone needs to be learning and growing all the time. I personally like this, but I've worked with incredibly competent people who just had other interests outside of work, and had no desire to get promoted or work on different things.

Personally, I prefer (often) working with the learning and growing people, but sometimes you can learn a bunch from the stable people as they'll often have lots of hard won lessons caused by staying in the same place for a long time.

Some people’s brains are just wired for that.

There are people who are just fine being a cog in a machine doing the same thing all day for years on out.

My family is from a factory town and many of them were literally standing next to a conveyor doing a monotonic task that could’ve done by a robot.

I tried it for one summer job and my brain almost melted from the boredom and monotony.