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 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 is what that saying is about
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.
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.
Not the one who does a few operations and is never around to see the results of their decisions and actions.
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.
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.
BUT they're completely wasted if you just use them to turn JIRA tickets into end to end features =)
Didn’t Bruce Lee famously say he fears the man who’s authored one API in ten thousand different contexts?
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?
(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.
You haven't but thanks :D
It's humbling, but I do tend to pick up a lot of stuff.
https://littlegreenviper.com/miscellany/thats-not-what-ships...
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.
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.
Their solution usually benefits from some simplification.
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.
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
I am afraid that this “1 year of experience 10 times” mantra gets trotted out to justify ageism more often than not.
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 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.
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.
My career trajectory is wild. At this rate I'll be CTO soon, then back to mid-level.
Aptitude paves the way for exploration: learning languages, paradigms, modeling techniques, discovering gotchas and so on. Skills follow from practice and practice requires a tough mindset where you don't give up easily.
So many software engineers learn to code just to pass exams and interviews. They claim they have strong logical reasoning. However, they have only been exposed to ideas and patterns from competitive programming rut. They have never even seen code more complex than a few hundred lines. They haven't seen problems being modeled in different languages. They haven't had the regret of building complex software without enough design. They have not had the disappointment of overengineering solutions. They have never reverse-engineered legacy code. They have never single-stepped in a debugger. All they have learned is to make random changes until "It works on my machine".
Yes, software is complex, disposable, ever-changing and often ugly but that is no excuse for keeping it that way.
I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on staff engineer as the first "terminal" position.
Someone should explain to the people who dream up these policies that the Peter Principle is not something we should aim for.
It's even worse when you combine this with age. I'm nearing 47 years old now and have 26 years of professional experience, and I'm not just tired, but exhausted by the relentless push to make me go higher up on the ladder. Let me settle down where I'm at my most competent and let me build shit instead of going to interminable meetings to figure out what we want to build and who should be responsible for it. I'm old enough to remember the time when managers were at least expected to be more useful in that regard.
And honestly, this will depend on the environment and kind of work being done.
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.
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 =)
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.
That was a little tongue in cheek, but I am genuinely curious what you think the correct approach is? I have seen many teams that do need to have someone overseeing the overall architecture, even if that person isn't writing the code line-by-line.
If you have that capacity baked into "Backend Programmer", then great, but not every team is the same.
Is there something inherently wrong with an "architect" who hasn't written code in a decade but is instructing seniors? One might believe that the answer is self-evident, however, I would argue that the organisational structures we see in the world (functional or otherwise) do not bear this out.
in last week I resolved a few legal/regulatory problems that could have cost company tens of millions of dollars in fines/direct spend/resources and prevented few backend teams from rolling out functionality that could have negative impact on stability/security/performance. I did offer them alternative ways to implement whatever they needed and they accepted it
It began with "software engineer"
There is nothing left. Not everyone puts in the same dedication towards the craft, of course. It very well might take someone 30 years to reach "principle" (and maybe even never). But 5 years to have "seen it all" is more than reasonable for someone who has a keen interest in what they are doing. It is not like a job dependent on the season, where you only get one each year. In computing, you can see many different scenarios play out in milliseconds. It doesn't need years to go from no experience to having "seen it all".
That is why many in this industry seek management roles as a next step. It opens a new place to find scenarios one has never seen before; to get the start the process all over again.
I've been programming since I was 7 and I'm old enough to remember the previous AI summer. Somewhere along the way, I've had impact on a few technologies you have heard of, I've coded at almost all levels from (some very specialized) hardware to Prolog, Idris and Coq/Rocq, with large doses of mainstream languages in-between, and I don't think I'll ever be close to having seen in all.
If anyone tells me that they've seen it all in 5 years, I'm going to suspect them of not paying attention.
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 exceptionally rainy, but not to the point of flood, to be able to make good decisions around it. You can take what you learned in the earlier not-quite-so rainy year and what you learned during the flood year and extrapolate from that what the exceptionally rainy year entails. That is what levels up someone.
Much the same is true in software. For example, once you write a (well-written) automated test in Javascript and perhaps create something in Typescript, you also have a pretty good understanding of what Rocq is trying to do well enough to determine when it would be appropriate for you to use. It would no doubt take much, much longer to understand all of its minutia, but it is not knowledge of intimate details that "senior", "principle", etc. is looking for. It is about being able to draw on past experience to make well-reasoned choices going forward.
I've seen a lot. But the more I see, the more I find to see.
One such period seems to have ended sometime around the start of Covid, or a bit before.
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.