Wow, fantastic read. The author seems to fully internalize and understand how when done well, it's not just junior engineers that grow but the senior engineers that mentor them and the organization as a whole:
"
Knowledge transfer isn’t something that just happens, it’s a skill. And like all skills you only get good at it by doing it over and over again. Consider this: in 2013 Sun Microsystems published the conclusions of a seven year study about the impact of mentorship that found that the people doing the mentoring experienced similar benefits to the junior colleagues being mentored. 25% of mentees saw a positive change in their salary growth, and so did 28% of mentors. Retention rate for the juniors rose from 49% to 72% and for the seniors it rose from 49% to 69%. When senior level people are able to grow junior colleagues, they are able to take on new responsibilities, build new skills, find new challenges without leaving the organization and ultimately everyone is better off.
So why aren’t you hiring junior engineers?"
The truth is, a lot of organizations either cannot see these decisions as long term investments (rather than liabilities), or have enough trouble hiring senior engineers in the first place that they're horrified of hiring junior engineers who will flounder without the right amount of mentorship.
> What were small, scrappy companies in 2010/2011 are now either dead or medium sized companies with mounds of poorly documented, idiosyncratic technical debt — the apparent cost of ninjas and rockstars.
This is somewhat of an aside to what the article mainly talks about, but I don't really know that all of this has to do with the engineers vs the companies.
Today's scrappy and small companies are still trying to find fit fast, and still have to be tactical. They can't avoid a pile of tech debt because they don't yet know what they need to build. Building a really fancy solution to a problem and then having that problem change out from under you is just another kind of tech debt.
So even without a focus on "rock stars", how can you avoid tech debt when you're in an exploratory phase?
Seems a bit of an instance of a common way for slightly-less-young-companies to shoot themselves in the foot. If your tech debt is just due to those other people who screwed up when building the initial systems, then of course it's a good idea to rewrite the world!
> how can you avoid tech debt when you're in an exploratory phase?
The tech debt becomes welfare if its whole purpose is to be a temporary benefit until eventually getting off of it. Abandon the old one and don't pay back the debt. But don't let zombie pets follow you to the next one... Legacy can be incredibly difficult to kill.
> "We have to upgrade right now because everything is on fire!",
I don't know exactly how it relates to the broader "tech debt" discussion, but one thing that can make a big difference is to design systems in such a way that there are obvious strain indicators.
To quote Firefly, ways the system can "let you know she's hurting before she keels.".
How exactly you do that depends on what you're building, but I think it's a worthwhile thing to keep in mind.
Can't think of any specific example off the top of my head, but I've noticed that lots of places talk about needing people to be "on call" all the time. We are a very small shop with some fairly high profile clients, and "everything's on fire" situations happen maybe once every year or two. And are then mitigated by fixing the code in such a way that there are diagnostics to let us know if we're ending up in dangerous territory again. Before everything goes Kaboom.
With DevOps you monitor [at least] four metrics: lead time for changes, deployment frequency, mean time to recover/restore service, and change failure rate. These indicators show if you're improving, stagnating, or straining. You can also track more specific service level indicators, the amount of toil to project work, and tech debt versus feature backlogs.
The "everything's on fire" metaphor also has a larger context. Sure, when people are getting woken up in the middle of the night because the site is down, shit's on fire. But also "we're constantly missing our deadlines" is shit's on fire, "our customers are not satisfied" is shit's on fire, "our overhead is way too high for what we're delivering" is shit's on fire. If you're out on the water and building a new boat because yours is on fire, it's a little late.
My experience echoes yours. We had 2 senior devs and 1 junior. We had one major event in 3 years -- a long weekend where things were on fire with code being updated on the half hour. But afterwards, we had so many indicators of when things were even approaching that level the job got almost boringly simple afterwards.
> You want to start hiring more juniors because juniors slow down the pace of new growth and you want things to slow down.
First time I've seen someone so accurately nail this effect of hiring junior engineers. I think this one is counter-intuitive to management, it's commonly believed that hiring more engineers leads to more manpower which leads to more work getting done and junior engineers are the ones that can be easily hired very quickly. I'm sure it's great for the careers of everyone involved, but it's awful for company productivity in the medium term.
Does any other industry have as much analysis on the workers themselves?
I worked in numerous other industries and my friends have as well and there's not near as much analysis of science lab workers or truck drivers or restaraunt workers or nurses or social workers.
Great question. This is just conjecture on my end, but I imagine it has to do with software engineering and tech in general having become one of the largest new destinations for a rewarding, stimulating, high compensation career. From what I can recall, I believe seeing the same amount of analysis applied to medicine, law, management consulting and banking.
To answer the latter half of your question, it is strange to not see that much analysis of science lab workers, truck drivers, restaurant workers, nurses or social workers, but I imagine that without the profit incentive there, the demand for research dries up. I wouldn't say that's a good thing, and it does indeed feel strange.
I can't decide if I want to be analyzed or not - on the one hand, I feel like the expectations that are put on me are often ridiculously unrealistic, so it'd be nice if there was some analysis that suggested so. On the other hand, I'd hate to find out that I'm just not that good compared to contemporaries...
I can guarantee that nurses are analyzed to hell and back; everything in healthcare is analyzed to hell and back. After all, every pill is billed, every machine is billed, etc.
Social workers are also very very analyzed on their day to day work, so much so that there are passed laws compelling reports of suspected activities to the police.
But there's a pretty established management structure, the roles are clearly defined, the output is clearly defined.
Only in tech is there a relentless drive to figure out how to get more and more productivity out of us, and who to hire that will produce the most at the lowest cost, instead of a fair sane career path.
At least in Biology, productivity depends a lot on junior lab techs, since there's a lot of "busy work" to generate results. Not really a peer-reviewed study, just common sense stuff from my own experience. Since I'm waiting on the output for data to analyze, not enough lower-level staff is something I tend to notice.
My own hunch is that this industry is one where the wrong management style or structure can very quickly result in $20MM spent on a team of engineers who produce nothing of value; whereas this tail risk is less acute in other industries.
Read up on Taylorism / "scientific management" - some industries, particularly ones with assembly lines, have had A LOT of detailed research done, down to the level of "it takes 1.27s to tighten this bolt".
there's plenty more from construction to factory workers to professional drivers to nurse and doctors but the literature is far from recent and the findings have been stable enough so it's not being discussed that much.
some concerns are specific of our industry, like efficiency from high level languages. some are more cross cutting, like communication efficacy. some are more universal, like optimal working hours per week.
if you pick some common metric like that last one you'll see all fields share a great deal of the same issue and same research
I agree! The research is available to how things should be run, what makes workers happiest, how much output is to be expected etc. etc.
There's decades of tech industry research and experience, and centuries of worker productivity data and management research.
However, there's a relentless drive in tech management to figure out how to squeeze more and more productivity out of the workers, all the while keeping them happy and maintaining quality products.
No other industry has that. Nurses would absolutely revolt if you told them that you were putting them in an Agile system in Jira and all of their productivity was going to be tracked down to the hour and once a month they had to hit crunch time and work an 80 hour week to meet deadlines and they had to meet everyday and justify their existence at a standup.
Nurses also have clearly defined goals, career stepping stones, licenses, specialties, etc.
Tech has none of that. The ideal hire is a ROCKSTAR developer that knows everything and doesn't need any wasted time on training, and would love to work their life away.
And management keeps trying to figure out how to make devs more and more like this.
> However, there's a relentless drive in tech management to figure out how to squeeze more and more productivity out of the workers, all the while keeping them happy and maintaining quality products.
"Behavior arising from class discontent, such as union activity, is derided as
destructive and damaging. An appeal is made for “intelligent labor leaders to
advocate efficiency in production to make possible the lowering of costs and
prices” (Spriegel, 1947: 590). Even as early as 1928, an author argues that industry
has moved past conflict and entered a period of “cooperative policies” (Anderson,
1928: 15), where harmony between workers and employers can reign."
> The ideal hire is a ROCKSTAR developer that knows everything and doesn't need any wasted time on training, and would love to work their life away.
"Frequently, the word “worker” is
preceded by adjectives of various types, modifying the qualities and attributes of the person to whom they refer and thus judging that person to be “good” or “bad.”
Spriegel (1947: 326) identifies “first class workers” in contrast to “substandard
workers.” Anderson (1928: 320) talks about “indifferent workers and slackers”
and “unintelligent workers” compared to “ambitious workers” (Anderson, 1928:
434). Folts (1938: 311) has “slow,” “medium,” and “superior workmen.” Balder -
ston and colleagues (1937: 245) discuss the importance of “mentally alert”
workers. "
Same. Nobody was born a senior engineer. I learned through building. We need to give everybody at least the same chances we were given. And hopefully to do better for them.
I distinctly remember the point in my career where I realized shortcuts aren't shortcuts if they increase the overall effort required in a project. Quite often the seemingly slower and more expensive way is the overall fastest and cheapest.
" Knowledge transfer isn’t something that just happens, it’s a skill. And like all skills you only get good at it by doing it over and over again. Consider this: in 2013 Sun Microsystems published the conclusions of a seven year study about the impact of mentorship that found that the people doing the mentoring experienced similar benefits to the junior colleagues being mentored. 25% of mentees saw a positive change in their salary growth, and so did 28% of mentors. Retention rate for the juniors rose from 49% to 72% and for the seniors it rose from 49% to 69%. When senior level people are able to grow junior colleagues, they are able to take on new responsibilities, build new skills, find new challenges without leaving the organization and ultimately everyone is better off. So why aren’t you hiring junior engineers?"
The truth is, a lot of organizations either cannot see these decisions as long term investments (rather than liabilities), or have enough trouble hiring senior engineers in the first place that they're horrified of hiring junior engineers who will flounder without the right amount of mentorship.