5 ms·

Hiring ONLY seniors is the worst policy in the software industry

40 points by samspenc 3y ago

iainctduncan 3y ago
So the article doesn't site sources, but it looks to me like another dev sharing "expertise" based on 1 data point (his experience of one team, one product). I work in technical diligence, we assess companies getting purchased, getting ready to exit, raising money, etc. I've done 50+ myself, read reports for hundreds more, and Crosslake (my employer) has done thousands. This is not our experience. Overspend on dev team is occasionally an issue. Key person risks, tech debt, and other symptoms of lack of expertise are frequently serious issues. (No amount of juniours eliminates key person risk on a senior, only a similarly expert senior does). The companies I have seen that made policies of hiring smaller teams of the best people they can find and paying them well were, in general, kicking ass. I would argue this article has it completely backwards. My opinion, based on anecdotal (because I didn't run stats on it) but much larger sample size is that the difference to your company over the long term of senior vs junior dwarfs the difference in cost. We are constantly saying "hire more seniors in X,Y,Z". We are rarely saying "cut dev spend". My advice: for your core offering, buy the best devs you can and make them happy. For all the peripheral commodity stuff (the "not rocket science"), outsource to Eastern Europe and have a full time senior based locally who job is to run that team, interfacing with their lead and managing integration with your core. Especially right now. Preferring juniors when the market is full of freshly unemploye ace seniors would be terrifically stupid.
- wtatum 3y ago
  Having been the target of a Crosslake report a few times it felt like the process was actually almost entirely focused on points like this. Key person risk, talent acquisition pipeline, process maturity, "definition of done", etc. It felt like "hard" tech debt items around code quality, measured SLA performance, etc were present for the sake of completeness but were of almost no consequence to the Crosslake team or those who would read the report. Does that mirror your experience working in DD?
  - fisf 3y ago
    There is a reason for that. Tech debt, code quality, poor SLA metrics are symptoms, and proxies for various things (that can be fixed). Failures in the other areas are root causes and more fundamental issues.
  - iainctduncan 3y ago
    It's a complex question. First, every diligence has very limited time, so for code and arch diligence, we get enough time to know if it's really good, or really bad. In the middle, you need weeks, not hours. Second, every client has different priorities, but in general, they want to know what the potential risks are of tanking the investment, and what they need to do to make sure this can't hapen. PE firms aren't like VCs... they don't want a 1 in 10 chance of unicorn, they want a 90% chance of a solid return with zero chance of losing the entire thing. When you're spending $50M to a $1B, a low-but-avoidable risk of disaster is not OK. Finding those is our number one priority. If the code is not awful, then the people, process, and org risks are much more likely to do this. I'm one of the first to say tech debt kills companies - I've literally seen it. But.... dysfunctional organizations kill companies worse and faster. And those are much easier to sniff out in two days of interviews.
- Justsignedup 3y ago
  Yeah came here to say that. I've never been part of a highly senior team. The BEST i've seen is a 1 sr to 2 jr ratio. And I've seen engs who have like 2 years of experience, clearly upper jr but talented, get sr titles.
  - tharkun__ 3y ago
    If a customer service agent you just hired is called an "Executive Client Account Manager" what do you expect the talented software people to be called?
deleted 3y ago
[deleted]
thesnide 3y ago
Best is to hire a mix, but code like only juniors come in. As a senior is always a temporary junior at first when hired. https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies.html https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...
- tjr 3y ago
  When I was a junior myself, I wanted to do fancy tricks with code and use Lisp or Ocaml or whatever. Now as a principal engineer, I want to keep code boringly simple and use languages that are likewise simple.
  - derwiki 3y ago
    Boring is the new clever
tester756 3y ago
>Tons of developers became seniors in < 3 years Senior in less than 3 years? Sure, he/she may have "senior" title, but this is nowhere even close to actual senior. They are señors. What developer could do in less than 3 years? I'm not talking about highly skilled/talented people Started at his/her first company, ramped up, got familiar with all the stuff like tools, processes, culture, code base, software development life cycle, learned stuff that he didnt know but needed (e.g tools, libs, frameworks, langs) It took like 3-6 months, after that he's reasonable contributor to the projects And now we have 2.5 years left - what you can do in that time? Participate in one bigger project? Participate in 2 mid size projects from the beginning to the end? Participate in 5 small projects from the beginning to the end? This is your seniority? You have seen whole software dev. life cycle in 2 mid size projects? or You have seen some part of software dev. life cycle in one bigger project? It is a joke. Exp != Knowledge, and seniority is about exp and responsibility, so for me it is: 0-3 junior 3-7 mid 7+ senior and above that you have other fancy things like leaders/principals/etc Of course, those aren't hard rules, senior with 6 years is ok too, but let's dont be ridiculous with seniors BELOW 3 years.
- cqqxo4zV46cp 3y ago
  “They”/“Their” is a 100% accepted and easier to read alternative to writing “he/she” all the time.
  - deleted 3y ago
    [deleted]
- arp242 3y ago
  > 0-3 junior, 3-7 mid, 7+ senior What do people use outside of software dev for these kind of titles? Because to me even 7 years for "senior" seems very fast. I don't think people outside of software dev progress up the ladder that fast?
  - tonyarkles 3y ago
    So… I’ve been writing software professionally since 2002 and was programming for fun/some open source for about 10 years prior to that. I’m still an IC, by choice (and spend a fair bit of time mentoring/doing architecture, but also writing code and laying out circuit boards). If we’re going to do job titles in increments of 3-4 years, I’m going to have the most ridiculous titles soon because all of the usual ones will have come and gone. But all of that is just to say that I don’t think years of experience is a good metric at all for job titles. By far the best metric I’ve come across over the years is “how long can you trust this person to work on something without worrying that we’re going to have to throw away a significant chunk of their work?” Junior developers? Maybe a day or two before they might need a course correction or feedback. Mid, maybe a week, tops. Senior, maybe two weeks. Staff/principal (depending on how you even order those in seniority) can be longer although they still need to check in with the business/peers on a regular basis just to verify that we’re all going in the same useful direction.
giovannibonetti 3y ago
One thing that makes companies focus so much on hiring senior devs is tech stack complexity. Resume-driven development overcomplicates it, and then only senior devs are able to work with it. On the other hand, nimble companies that resist the complexity urge and keep the tech simple (KISS principle) will have an easier time working with less experienced devs. I've seen some great examples of profitable bootstrapped companies running their apps on Heroku with a small engineering team. Frameworks like Rails and Elm help a lot as well.
- iainctduncan 3y ago
  Frameworks like Rails with an inexperienced team are a good way to see paralyzing tech debt five years in. As in, so stuck the company is barely treading water and will die or get sold for pennies on the dollar to a competitor buying their customer base.
arp242 3y ago
> Tons of developers became seniors in < 3 years Complete lunacy. A major reason we have to deal with a never-ending stream of hype vomit is because people implement stuff and leave before they have to suffer the consequences of their decisions. It's easy to argue for $thing if you're not the one having to deal with it 5 years down the line. I don't care how smart you are or what you were doing when you were 12; if you haven't dealt with consequences from your decisions (and some consequences from other people's decisions) a few times in a real-world business context with real customers then you're not a "senior". Your "CV-driven-development" CV may be dripping with the right keywords, but that doesn't make you a "senior" either. Their "5 reasons why hiring a great junior is the right bet for you" is even more lunacy to the point of being ageist wank. In what kind of universe is "reuse the same technologies from previous companies" bad in and of itself? Using stuff you know works well, so you know where the problems are, instead of betting on some unproven tech that may or may not work well and that may or may not cost the company millions. Just because "it's a bit nicer" or whatever. The largest group should be the new blood" just translates to "most people should be unfamiliar with the code base and have no idea what they're doing". Worst article I've seen posted to HN in a long time, by a considerable margin.
- iainctduncan 3y ago
  It's a classic example of start-up scene tunnel vision. If you are in that scene, it's very easy to think the whole industry is like you, hyped about the latest javascript framework and "passionate" about whatever is hip today. In reality, measured by dollars or by developers, the vast majority of the industry is run by folks in their 40's to 60's solving unglamourous business problems in .Net or Java for millions of dollars. I say this as someone who came from Python and JS and startups and so on and got into doing tech deligence for big funds - I was gobsmacked by a) how much of it was .NET and Java and b) how much god-damned money people make solving the most unglamorous and boring business problems you can think of. (And c) how much they spend on cloud services.... OMFG.) What folks in startups read in the blogosphere and hear from others in the same scene is not really reflective of the larger industry at all.
BugsJustFindMe 3y ago
> Software Development is not rocket science. Tons of developers became seniors in <3 years, some of them even without a degree. Ugh. I wish people would treat it more like rocket science instead of having an entire industry of people who insist on calling themselves senior engineers but who haven't learned the first thing about how the computer actually works, who have no meaningful depth or breadth of experiences, and who can't architect creative elegant solutions to novel problems, and who pretend like none of that matters. The flat skill to experience curve shown in the blog post is extremely wishful thinking vs the average of what's considered normal.
devaiops9001 3y ago
Today I am in two executive roles but don't reveal this "status" or whatever to others. I prefer to let them be unaware who they are talking to and for them to go ahead and show me if they are a piece of shit or not. Role titles are very demoralizing because the people who care about them are there for the wrong reason. The same people who get caught up in titles are the same ones who think setting up a Kanban board is more of a technical process than a human one. When I was in individual contributor roles.. - For the interview process my third role I put "Senior Systems Administrator" on the resume for the previous role, even though that role's "real" title was "Tech Support Administrator". - By the time I got to role number 4, I removed "Senior" from anything on the resume/LinkedIn. - One of the roles I served in the last three years had "Principal" in the title. But that company sucked ass and everyone had these overly inflated bullshit because the heads of the company were basically hiring their friends with inflated salaries who sat around and didn't do much work. This really pissed off the people who did do the work and did earn their role titles. So I didn't put "Principal" on it when sending the resume out. Fuck those people. If I were sending out the resume today, I would just put one of my former colleague's consulting company on there instead.
PeterStuer 3y ago
Obviously the author has somehow never seen the much more common "hiring only juniors" environments.
swaggyBoatswain 3y ago
I find titles to be a social construct we use, the meaning of "senior" I feel has been diluted over the years much like the word "engineer" has been as well I think the more important question is whether or not the person you are hiring can do the given job and task, regardless of years of experience

40 points by samspenc 3y ago

So the article doesn't site sources, but it looks to me like another dev sharing "expertise" based on 1 data point (his experience of one team, one product). I work in technical diligence, we assess companies getting purchased, getting ready to exit, raising money, etc. I've done 50+ myself, read reports for hundreds more, and Crosslake (my employer) has done thousands. This is not our experience. Overspend on dev team is occasionally an issue. Key person risks, tech debt, and other symptoms of lack of expertise are frequently serious issues. (No amount of juniours eliminates key person risk on a senior, only a similarly expert senior does). The companies I have seen that made policies of hiring smaller teams of the best people they can find and paying them well were, in general, kicking ass. I would argue this article has it completely backwards. My opinion, based on anecdotal (because I didn't run stats on it) but much larger sample size is that the difference to your company over the long term of senior vs junior dwarfs the difference in cost. We are constantly saying "hire more seniors in X,Y,Z". We are rarely saying "cut dev spend". My advice: for your core offering, buy the best devs you can and make them happy. For all the peripheral commodity stuff (the "not rocket science"), outsource to Eastern Europe and have a full time senior based locally who job is to run that team, interfacing with their lead and managing integration with your core. Especially right now. Preferring juniors when the market is full of freshly unemploye ace seniors would be terrifically stupid.

wtatum 3y ago
Having been the target of a Crosslake report a few times it felt like the process was actually almost entirely focused on points like this. Key person risk, talent acquisition pipeline, process maturity, "definition of done", etc. It felt like "hard" tech debt items around code quality, measured SLA performance, etc were present for the sake of completeness but were of almost no consequence to the Crosslake team or those who would read the report. Does that mirror your experience working in DD?
- fisf 3y ago
  There is a reason for that. Tech debt, code quality, poor SLA metrics are symptoms, and proxies for various things (that can be fixed). Failures in the other areas are root causes and more fundamental issues.
- iainctduncan 3y ago
  It's a complex question. First, every diligence has very limited time, so for code and arch diligence, we get enough time to know if it's really good, or really bad. In the middle, you need weeks, not hours. Second, every client has different priorities, but in general, they want to know what the potential risks are of tanking the investment, and what they need to do to make sure this can't hapen. PE firms aren't like VCs... they don't want a 1 in 10 chance of unicorn, they want a 90% chance of a solid return with zero chance of losing the entire thing. When you're spending $50M to a $1B, a low-but-avoidable risk of disaster is not OK. Finding those is our number one priority. If the code is not awful, then the people, process, and org risks are much more likely to do this. I'm one of the first to say tech debt kills companies - I've literally seen it. But.... dysfunctional organizations kill companies worse and faster. And those are much easier to sniff out in two days of interviews.
Justsignedup 3y ago
Yeah came here to say that. I've never been part of a highly senior team. The BEST i've seen is a 1 sr to 2 jr ratio. And I've seen engs who have like 2 years of experience, clearly upper jr but talented, get sr titles.
- tharkun__ 3y ago
  If a customer service agent you just hired is called an "Executive Client Account Manager" what do you expect the talented software people to be called?

deleted 3y ago

[deleted]

thesnide 3y ago

Best is to hire a mix, but code like only juniors come in. As a senior is always a temporary junior at first when hired. https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies.html https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...

tjr 3y ago
When I was a junior myself, I wanted to do fancy tricks with code and use Lisp or Ocaml or whatever. Now as a principal engineer, I want to keep code boringly simple and use languages that are likewise simple.
- derwiki 3y ago
  Boring is the new clever

tester756 3y ago

>Tons of developers became seniors in < 3 years Senior in less than 3 years? Sure, he/she may have "senior" title, but this is nowhere even close to actual senior. They are señors. What developer could do in less than 3 years? I'm not talking about highly skilled/talented people Started at his/her first company, ramped up, got familiar with all the stuff like tools, processes, culture, code base, software development life cycle, learned stuff that he didnt know but needed (e.g tools, libs, frameworks, langs) It took like 3-6 months, after that he's reasonable contributor to the projects And now we have 2.5 years left - what you can do in that time? Participate in one bigger project? Participate in 2 mid size projects from the beginning to the end? Participate in 5 small projects from the beginning to the end? This is your seniority? You have seen whole software dev. life cycle in 2 mid size projects? or You have seen some part of software dev. life cycle in one bigger project? It is a joke. Exp != Knowledge, and seniority is about exp and responsibility, so for me it is: 0-3 junior 3-7 mid 7+ senior and above that you have other fancy things like leaders/principals/etc Of course, those aren't hard rules, senior with 6 years is ok too, but let's dont be ridiculous with seniors BELOW 3 years.

cqqxo4zV46cp 3y ago
“They”/“Their” is a 100% accepted and easier to read alternative to writing “he/she” all the time.
- deleted 3y ago
  [deleted]
arp242 3y ago
> 0-3 junior, 3-7 mid, 7+ senior What do people use outside of software dev for these kind of titles? Because to me even 7 years for "senior" seems very fast. I don't think people outside of software dev progress up the ladder that fast?
- tonyarkles 3y ago
  So… I’ve been writing software professionally since 2002 and was programming for fun/some open source for about 10 years prior to that. I’m still an IC, by choice (and spend a fair bit of time mentoring/doing architecture, but also writing code and laying out circuit boards). If we’re going to do job titles in increments of 3-4 years, I’m going to have the most ridiculous titles soon because all of the usual ones will have come and gone. But all of that is just to say that I don’t think years of experience is a good metric at all for job titles. By far the best metric I’ve come across over the years is “how long can you trust this person to work on something without worrying that we’re going to have to throw away a significant chunk of their work?” Junior developers? Maybe a day or two before they might need a course correction or feedback. Mid, maybe a week, tops. Senior, maybe two weeks. Staff/principal (depending on how you even order those in seniority) can be longer although they still need to check in with the business/peers on a regular basis just to verify that we’re all going in the same useful direction.

giovannibonetti 3y ago

One thing that makes companies focus so much on hiring senior devs is tech stack complexity. Resume-driven development overcomplicates it, and then only senior devs are able to work with it. On the other hand, nimble companies that resist the complexity urge and keep the tech simple (KISS principle) will have an easier time working with less experienced devs. I've seen some great examples of profitable bootstrapped companies running their apps on Heroku with a small engineering team. Frameworks like Rails and Elm help a lot as well.

iainctduncan 3y ago
Frameworks like Rails with an inexperienced team are a good way to see paralyzing tech debt five years in. As in, so stuck the company is barely treading water and will die or get sold for pennies on the dollar to a competitor buying their customer base.

arp242 3y ago

> Tons of developers became seniors in < 3 years Complete lunacy. A major reason we have to deal with a never-ending stream of hype vomit is because people implement stuff and leave before they have to suffer the consequences of their decisions. It's easy to argue for $thing if you're not the one having to deal with it 5 years down the line. I don't care how smart you are or what you were doing when you were 12; if you haven't dealt with consequences from your decisions (and some consequences from other people's decisions) a few times in a real-world business context with real customers then you're not a "senior". Your "CV-driven-development" CV may be dripping with the right keywords, but that doesn't make you a "senior" either. Their "5 reasons why hiring a great junior is the right bet for you" is even more lunacy to the point of being ageist wank. In what kind of universe is "reuse the same technologies from previous companies" bad in and of itself? Using stuff you know works well, so you know where the problems are, instead of betting on some unproven tech that may or may not work well and that may or may not cost the company millions. Just because "it's a bit nicer" or whatever. The largest group should be the new blood" just translates to "most people should be unfamiliar with the code base and have no idea what they're doing". Worst article I've seen posted to HN in a long time, by a considerable margin.

iainctduncan 3y ago
It's a classic example of start-up scene tunnel vision. If you are in that scene, it's very easy to think the whole industry is like you, hyped about the latest javascript framework and "passionate" about whatever is hip today. In reality, measured by dollars or by developers, the vast majority of the industry is run by folks in their 40's to 60's solving unglamourous business problems in .Net or Java for millions of dollars. I say this as someone who came from Python and JS and startups and so on and got into doing tech deligence for big funds - I was gobsmacked by a) how much of it was .NET and Java and b) how much god-damned money people make solving the most unglamorous and boring business problems you can think of. (And c) how much they spend on cloud services.... OMFG.) What folks in startups read in the blogosphere and hear from others in the same scene is not really reflective of the larger industry at all.

BugsJustFindMe 3y ago

> Software Development is not rocket science. Tons of developers became seniors in <3 years, some of them even without a degree. Ugh. I wish people would treat it more like rocket science instead of having an entire industry of people who insist on calling themselves senior engineers but who haven't learned the first thing about how the computer actually works, who have no meaningful depth or breadth of experiences, and who can't architect creative elegant solutions to novel problems, and who pretend like none of that matters. The flat skill to experience curve shown in the blog post is extremely wishful thinking vs the average of what's considered normal.

devaiops9001 3y ago

Today I am in two executive roles but don't reveal this "status" or whatever to others. I prefer to let them be unaware who they are talking to and for them to go ahead and show me if they are a piece of shit or not. Role titles are very demoralizing because the people who care about them are there for the wrong reason. The same people who get caught up in titles are the same ones who think setting up a Kanban board is more of a technical process than a human one. When I was in individual contributor roles.. - For the interview process my third role I put "Senior Systems Administrator" on the resume for the previous role, even though that role's "real" title was "Tech Support Administrator". - By the time I got to role number 4, I removed "Senior" from anything on the resume/LinkedIn. - One of the roles I served in the last three years had "Principal" in the title. But that company sucked ass and everyone had these overly inflated bullshit because the heads of the company were basically hiring their friends with inflated salaries who sat around and didn't do much work. This really pissed off the people who did do the work and did earn their role titles. So I didn't put "Principal" on it when sending the resume out. Fuck those people. If I were sending out the resume today, I would just put one of my former colleague's consulting company on there instead.

PeterStuer 3y ago

Obviously the author has somehow never seen the much more common "hiring only juniors" environments.

swaggyBoatswain 3y ago

I find titles to be a social construct we use, the meaning of "senior" I feel has been diluted over the years much like the word "engineer" has been as well I think the more important question is whether or not the person you are hiring can do the given job and task, regardless of years of experience