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.
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.
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.
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.
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?
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.
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.
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.
> 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.
I've seen it legitimately happen quite a few times, but these are rare. Examples of the sorts of people it applies to:
* Taking graduate CS classes at Ivy League universities while in high school
* Nationally/internationally ranked competitive programmers
* 4.0 GPAs in tough majors at elite schools without grade inflation
* Maintainer of parts of the Linux kernel while still in high school
It's not typical, but I've known many dozens of people like this who are legitimate tech leads at very selective companies with 1-3 years of professional employment experience. (edited: formatting)
In my view seniority is about breaking the mold you described above and learning about economics, politics, staffing, real world design constraints etc.
The people above have their tech chops perfected on day 1 of their professional employment.
They get the economics, politics, staffing, real world design constraints polished while most juniors are learning about algorithms, design, and unit testing.
This applies to me. I'm ~9 years into my career, 5 in my current specialty. I'm titled as a senior developer, mainly because I am the only developer for my product at the company (I maintain our warehouse management system).
Honestly, it sucks, because I do not have senior levels of industry experience but am still required to make decisions as if I did. I don't like the situation, but I make the best of it and try to source second opinions from those wiser than myself, which usually means contacts outside my current employer.
I'm not sure how common my situation is, but I'm sure I'm not the only one to title creep more rapidly than is perhaps sane.
I think this is a lot more common than one might think. The trend of hiring "Only Seniors" puts a downwards pressure on both engineers and those managing them to focus on titles over pay increases. The engineer gets the title thinking they can leverage it for more pay at a different position, but in reality they end up trapped at their current employer because they are from then on interviewed as a senior level engineer and unable to pass merit by that benchmark. Should they aim for a non senior role, they automatically face negative hiring bias because the hirer assumes (probably accurately) that they will demand more pay for the same role compared to non-senior applicants with the same years of experience.
Strange catch 22 situation where the title promotion actually locks them in where they are for at least another few years.
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?
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.
0-3 analyst
3-7 Associate (mid) to Vice President (senior to staff/manager)
7+ if they're good, Managing Director (staff to senior staff/manager to senior manager)
> 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.
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.
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.
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.
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
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.