I officially mentored someone at my previous company and helped him move from a support tech role into a software dev position. It was incredibly rewarding.
But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted. One might argue that if everyone put more fish in the pond, then we'd all be better off (true), but we have a standard collective action problem where the free riders benefit at the expense of the fish growers.
I see two (partial) ways out of this trap.
1. Pay more than everyone around you. (Obviously, not generally viable.)
2. Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy at every level so people will see a path to grow.
>To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.
Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
So these companies put all this effort into raising a better developer, and then refuse to pay them what they're now worth and basically force them to go elsewhere.
It's not "what if they go elsewhere" under that situation, it's "when".
I'd argue that you don't even have to "pay more than everyone around you". Simply coming close to parity is enough to stop most people from going through the pain of a job search. But these companies don't even get that close.
The last time I switched jobs, I got a 40% pay increase. That's ridiculous. I even told the company I was underpaid and they asked if I could wait a year for a raise. I didn't even answer the question. I just walked away and started looking for a job.
They weren't surprised when I found one and quit.
And a couple weeks before I left, they put in a job ad for 7 developers, offering what I was making at my new job for each of them. I've been at this new job as a senior developer for 8 years now.
Could I make more? Almost certainly. But they gave me decent raises and have a good culture (almost zero overtime in 8 years) and benefits, and I don't feel like leaving.
Currently switching jobs for a personal record 57% increase in total compensation.
And I was NOT poorly compensated before. I was already in the 99th percentile for individual income.
The harder I push on comp the more I get each time.
I am not going to lie and say that it didn't take years to build to this point in terms of skill, work record, professional network, and interview ability. It took three FAANG companies bidding against each other.
Meanwhile I get offered nothing in terms of growth from every employer I have ever worked for ever. Literally never happened my entire career. Just this time after I already had an undisclosed offer in hand I got a promotion with no meaningful compensation increase. It was the first promotion of my 15 year career!
Sure they were willing to match, but who wants to try and soak blood from a stone.
> Sure they were willing to match, but who wants to try and soak blood from a stone.
I've never tried it myself, but it's supposed to be common knowledge that perhaps more than half the time a company is forced into granting you a raise to match an offer you have in hand, they're only doing it long enough to arrange replacing you. There are certainly many reported exceptions to this, but why take a chance with a company that's already shown they don't respect you?
I am very wary of making this about respect or the individuals in the company who didn't grant you better compensation. It's toxic for yourself and if other people find out you think that way it can spoil relationships. Never underestimate how the people you work with at your old jobs can end up being stepping stones to bigger and better things later on.
I believe no one in my management chain could have done significantly better. They had their budget and even if they had moved things around in my favor it would have just been a different level of inadequate.
Structurally the entire industry is biased towards preventing you from achieving what I call equilibrium. Equilibrium is where you can't leave your current job for a >10% raise.
I believe it's just a cost saving measure (assuming the ability to pay exists which it may not) and the industry has decided that the average wage suppression is more valuable then the cost of the turn over it creates. I'm not going to pass judgement on whether they are right or wrong.
Ability to pay is a big factor. Most of my prior employers could only offer a fraction of what I currently make.
The bottom line the US is that respect is ultimately measured in dollars. I won't argue there isn't some toxicity to that, but a company that doesn't reward the vastly increased value of its developer employees as they move from entry level to journeymen to experts will suffer greatly from it, often fatally.
If employers can't afford market salaries, they should think very hard about the issue and see if they can't address it in other way, or accept that they're going to deserve and get no loyalty from most of their employees.
It kind of reminds me of the Brain Drain Microsoft experienced in the mid 2000s and saw them fall behind apple and google as the top of the tech food chain.
I agree. No need to make it emotional and confrontational with a “respect” interpretation in my opinion. Of course this is hard but if I can do it I imagine the best approach will be to simply make the best choices for my career while recognizing management has their own bizarre incentives I will never understand.
Off topic - but your username and the vast majority of your commenting history is primarily on salaries. Curious - is there some backstory to it? Feel you got severely underpaid?
To each and his own, but bay area engineers pissing about making ONLY 300K has always come off as being a bunch of spoilt brats - especially considering the vast majority just gem/npm/pip install this and that and glue all the code together. Of course the market deserves to pay accordingly but I think it's just a big bubble that's going to crash soon - since there is a huge mismatch between demand and supply of CRUD glue programmers (which most programmers are).
My guess is that once Lambda School, Make School, ISAs all become mainstream and the pool of CRUD glue programmers matches the demand all salaries will come crashing down. I think overall it's a good thing for society in general (and especially the tech towns).
ps: Pardon my tone. I work in the space industry. Maybe I have an axe to grind ;)
This is an alt specifically for discussing compensation because I know it elicits that reaction and I don't want that associated with my professional identity.
I think discussing compensation frankly and openly is very important. People have no idea what is possible. Two people on the same team at the same company can have wildly different compensation. My goal with this alt is to get people to take the biggest slice of the pie they can for themselves and avoid wasting their precious time doing lousy work for lousy money.
I have wasted a lot of time and life opportunities working for less then what I am capable of getting. I wish my future self had been around to tell me to push harder and be more mindful and efficient with my time.
I don't think CRUD glue programmers are at the top of the market right now. You could flood the market with them and it might not move compensation for people in my space. Even so, that is just another argument for pushing hard right now. Strike while the iron is hot. No one knows how long this will last.
Any advice on learning your true worth? Assume for a minute that Glassdoor is useless, as the "salary range" it displays shows that the maximum is 2-2.5x the minimum.
There is no "true worth" that you can look up on a website. Your salary is your cost in the labor market. And like any market, worth is determined by what people are willing to pay. Go out and interview, get some offer sand see who is willing to compete for you. That's how you get your true worth.
The only thing that matter is what they think you can get elsewhere. eg. what others are willing to pay. Think of it as an auction. Something might be worth $100 but if the highest bid is $10 you are only going to bid $15 not $100.
> To each and his own, but bay area engineers pissing about making ONLY 300K has always come off as being a bunch of spoilt brats
I think your entire attitude is wrong. Not in the sense of "you're being mean"; rather, in the sense of your orientation toward engineer pay. Any money that doesn't go to salary will generally go to the owners of the business. If engineers can get more, why shouldn't they? Imagine someone saying professional sports stars make too much money and should be perfectly happy to make $1 million per year. What you're actually arguing for is that even-richer people (the team owners) should make EVEN MORE money than they already do.
> but bay area engineers pissing about making ONLY 300K has always come off as being a bunch of spoilt brats - especially considering the vast majority just gem/npm/pip install this and that and glue all the code together. Of course the market deserves to pay accordingly but I think it's just a big bubble that's going to crash soon - since there is a huge mismatch between demand and supply of CRUD glue programmers (which most programmers are).
Seriously? Why the hate?
300k is Tier 1 (FAANG) and 2 companies. They don't just do CRUD. Those that do CRUD probably work on the SETI/Infra/Tooling division for the BigCos and even some of these "Tool-Devs" created amazing OSS tools. Do you suggest they should be treated as 2nd class citizens and get paid half of the "product" people and creating an old-time rift?
I've seen a few Bootcampers that get a job in Tier 1 and 2 companies but they have "solid" background/previous experience (hardcore Math, Stats, Data Scientist switching to SWE, greybeard embedded software engineers), just not up to date skill set.
This whole "salaries" will crash down demise has been around forever and it hasn't happened yet just like any other "demise" prediction.
I'd suggest people not to hate the situation: our sector/field is getting paid serious money, why the envy/jealousy/negativity?
Do you like the situation where hi-tech industry as a cutthroat, no-union, rampant ageism, low-paying wage?
“This whole "salaries" will crash down demise has been around forever and it hasn't happened yet just like any other "demise" prediction”
- agreed, lots of people can some problems the naive way but you need to be at a deeper level of understanding and experience to know what will and wont work before you build it
Thank you. I wonder sometimes if that's me and I'm unaware. I currently write REST applications and work on a lot of the stack around that. But it's not as simple as Create Read Delete Update. Well it can be, but it's far more complex in my industry.
The hard part of engineering isn't the ability to glue packages and microservices together. Those tasks are literally done by entry level, bottom of the totem pole engineers. You're saying that all bankers do is run models and spit out valuations, and all a chef does is put stuff in a pan.
I'm not speaking toward your argument of a bubble bursting, but engineering isn't going anywhere. And where else would an entry level engineer start than at the bottom, npm installing the package that solves their problem? It's using these concepts every day that builds good engineers who think of tomorrow's solutions, and can architect it both technically and socially. That is the line between software development and computer science.
Engineers paid under 120k that whine aren't doing anything beyond their immediate usefulness, i.e. 'just doing their jobs.' The engineers that get paid 300k are usually the ones running the show, and writing significantly less / no code.
$300K to live on the west coast is really not that appealing to someone who is living in a major city, with the stereotypical house in the burbs in a good school system with 2.1 kids where on the higher end you can make $150K to $160K as an architect/team lead/principal. Especially if you are married with two incomes where you can easily put the lower income completely toward increasing net worth or cash flowing your kids college expenses.
Engineers getting paid $300K could easily be the stereotypical r/cscareerquestions “learn LeetCode and work for a FAANG” type graduating from college.
I think you are perhaps too focused on the immediate salary, and not thinking long-term.
Yeah, $300k in the Bay Area isn’t that much. But if you work for a Tier 1/2 company for a few years, it can have a drastic impact on your future employment prospects and salary levels. Furthermore, the street cred can open many doors that otherwise would remain closed to you.
I think my reply would have had more context in response to a sibling reply made by another poster:
Consider the scaling factor for salaries; My salary is on the high end in my area, but would be on the low end of a living wage in the Bay Area.
My salary is in the neighborhood of 120k; I'm a senior-level engineer with almost a decade of experience...
So think about the trade offs. If you’re young and single, the tradeoff between a one bedroom in a major city anywhere not on the west coast and the west coast and the difference in the salary you can make is well worth it.
In most major cities a junior developer will make $60K and can probably find an apartment for $900/month in a decent part of town. If they work on the west coast and get $250K and find an apartment for $2400K/month, that’s a tradeoff worth making.
10-15 years into your career, you may already be married with kids. That $120K he’s making can easily buy a 3000 square foot house in the burbs, brand new build, great school system and close to work for $350K. This is from personal experience (not the salary, the price of the house). Now that tradeoff between $150K and $300K-$400K doesn’t look so appealing when you can’t live nearly the same lifestyle on the West Coast that you could live on much less money
If he’s like me, he’s probably built a local network where any door he wants to open locally is probably already open to him.
In my case, I’m 45, but because of $bad_life_decisions, I only started taking my software development career seriously a decade ago. But I do have a great local network, skills that match what the market demands and the house in the burbs with the wife, the white picket fence and 2.1 kids.
I don’t really need new doors opened to me. As soon as the youngest graduates and I’m willing to travel, I am already in the position of being a high earning “consultant”. Not bragging, I have been working over 20 years, I should be able to consult somebody
> Furthermore, the street cred can open many doors that otherwise would remain closed to you.
The assumption here is that technical screenings actually work. As many here have pointed out, technical interviews today are highly capricious and pretty have no correlation with actual technical qualifications. "Street cred" and even superb interview performance don't seem to matter anymore.
I’ve found that people who work for large companies are often not a fit for smaller companies. They may be good developers, but most of the time they come in with prebuilt infrastructure, processes, separate departments to handle the infrastructure parts etc.
Most small companies I’ve worked for, I’ve had to go back and forth between every layer of the stack - currently including the infrastructure set up. You just don’t get your hands dirty with multiple parts of the stack at a large company.
Anyone who is making $135K+ in any city that is not on the west coast or NYC, is probably 10 years into their career and may already have a family. In that case, they probably don’t want to make the sacrifices needed to go from making enough to live an upper middle class lifestyle - ie the nice house in the burbs to downgrading to a small apartment.
In my case, I’m 45, why would I move to the west coast for $300K when I can just stay in $major_city and work for a consulting when my younger son graduates and can make $180K-200K+ and still have the same lifestyle?
And then go back to being just a developer anytime I wanted to and still live comfortably?
But you're assuming with 10-15 years of experience you're stuck at 250-300k.
People who advanced in their career at Bay Area can make 500k or more (IC, not management), solving challenges that did not exist in the first place too (that alone might potentially put you in top 1-5%?). There are more startup opportunities (whether IPO or just the technical challenges, that's up to you) with higher chances of success.
I’m not denying that different people have different goals. But if you already are living a life free from worry, can work part of the year, doing what you enjoy, paid off house, what’s really the difference between 2 million and 15 million? (not saying I am there yet).
It’s not like I go to work everyday hating software development and hating what I have been doing since I was 12 years old. My wife works for the government and we have guaranteed access to health care whether she works or quits tomorrow.
I can have technical challenges and jump from opportunity to opportunity in two years once my youngest graduates.
Outside of the west coast/HN bubble, people retire comfortably all the time with a million in the bank, I paid off house, and social security.
Married couple wanting more children? yes, it matters.
Parents who want their kids to enjoy life? yes, it matters.
Parents who need to take care both in-laws and kids? absolutely, it matters a lot.
2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 100-200k left. Certainly not enough for retirement. In Seattle (USA), I suppose it depends on the area of your chosen.
How long do you have to work to reach the point of no-mortgage (nice house), kids done college paid by parents, and $2 mills for retirement?
But this is just what might be one dimension of the discussion: financial => lifestyle.
> I can have technical challenges and jump from opportunity to opportunity in two years once my youngest graduates.
We both live in different cities. I don't know your city as well as you do but where I live, there's definitely a ceiling to that technical challenges. Now before we go further with examples... I live in a city that certainly have huge hi-tech ecosystems and quite well known internationally.
I don't see Facebook/Google/Uber/Netflix/AirBnB anywhere nearby. My coworker would love to do impactful ML work. There's zero companies in my city that does ML meaningfully (more than just gluing OSS solutions or calling 3rd-party APIs). I personally would love to work on tackling scaling challenges. These opportunities just don't exist here.
The companies here are quite good compare to major cities out there, but certainly there's a virtual ceiling/limit due to a mix of VC, culture, talent, etc.
Just to wrap things up and to put things into perspective, I'm not a workaholic or ambitious person. I see those challenges as opportunity to invest my skill to stay relevant for years to come so I can take my foot off the pedal a bit. Otherwise, I'd be just an Engineer like everybody else in this city...
2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 100-200k left. Certainly not enough for retirement. In Seattle (USA), I suppose it depends on the area of your chosen.
That was kind of the point of my replies. I live in metro Atlanta. Not exactly small town America. We just bought a house in the burbs two years ago - 5 bedrooms, 3-1/2 bath almost 3000 square feet, brand new build for less than $350K.
Parents who want their kids to enjoy life? yes, it matters.
And somehow kids manage to “enjoy life” where the average household income in the US is $60K a year.
How long do you have to work to reach the point of no-mortgage (nice house), kids done college paid by parents, and $2 mills for retirement?
Let’s talk about a stereotypical couple. Someone brought up that they were making $120K in a low cost city and they were in their early 30s. Let’s also say the spouse was grossing $50K (about average for a college educated person in the US).
According to paycheckcity.com. The lower earning spouse would bring home $3400 a month. The higher earning spouse would bring home a little over $6000 after maxing our his 401K (pretax) at $19K a year for retirement. Many couples I know in that situation live completely off the higher earners income. That’s what I would have done if I got married at the average age of around 30.
If they were just hitting their stride at 30 with no kids. That $350K-$400K 5 bedroom house could be paid off in around 10-12 years.
If the developer just put $2083 a month (that includes the $1583/month in his 401K) in an S&P Index fund that historically earned 11% a year, they would have 2.1 million in today’s dollars adjusted for inflation (2.9%) by the time he was 52.
Getting the kids through college? Let’s add some variables. The wife could take a year or two off when they had kids and the house would still be paid off by the time they graduated from college and they could put her income toward cash flowing the kids through college. I also didn’t take into account that hopefully they will get more than inflation adjusted wages.
We both live in different cities. I don't know your city as well as you do but where I live, there's definitely a ceiling to that technical challenges. Now before we go further with examples... I live in a city that certainly have huge hi-tech ecosystems and quite well known internationally.
While the numbers for income I quoted above were theoretical, the fact that I have plenty of opportunities to work for a consulting company after my youngest graduates in two years and I’m willing to travel isn’t. I live in the same city as the world’s busiest airport. Getting a direct flight to almost anywhere isn’t a problem. Even Amazon is hiring AWS consultants who live in most major cities.
I personally would love to work on tackling scaling challenges. These opportunities just don't exist here
Even if the challenges don’t exist where I live, one or two of my friends/former coworkers work remotely. As I said above, I’m willing to travel.
But I know people, like my former manager who is in his late 50s, that wanted and did just the opposite, he changed jobs, self demoted to a developer and is doing your basic Microsoft/Azure full stack development. Once you have “enough”, you can get off the hedonic treadmill and make different life choices, you can take a pay cut to have a less stressful life, a better work life balance, etc.
I didn’t make nearly the same “good life choices” as the idealized couple I wrote about above but even I can say no to consulting companies that would pay me more than I am making now because I just really don’t want the headache at this point in life.
One final point. My parents are in their 70s, they retired in their mid 50s in the small town south with less than a million in the bank. My mom was a teacher (with a pension) and my dad was a factory worker (no pension). They aren’t struggling. They had 5 years left on their 30 year mortgage when they retired - they were paying $600/month for their mortgage.
Why is that the only definition of complex? Most complexities in business comes from process complexities or even business complexities. I once worked with a software as a service company that provided software for the car repair industry. We had to translate these rules for both the repair shop and the car owner.
Did we have millions of users? No. The rules were complicated, and most processing happened once a month. There is a central exchange that both sides go through.
I’ve had three jobs in healthcare. While the scale of users weren’t anything crazy. The business requirements were complex.
Because that definition of complex opens tons of doors to companies that are leading tech industry?
My background has always been in Enterprise software (healthcare, insurance, BI, etc, almost a decade). At some point I felt that translating complex biz reqs are no longer interesting.
I find dealing with scalability (and hopefully build my own system library) is more interesting and challenging that the Enterprise market.
Consistent Hashing algorithms, Distributed Systems, System programming, build your own programming languages, maybe build my own messaging/background processing?
Consider the scaling factor for salaries; My salary is on the high end in my area, but would be on the low end of a living wage in the Bay Area.
My salary is in the neighborhood of 120k; I'm a senior-level engineer with almost a decade of experience, involved in some of the high-level planning tasks you describe.
I feel for people working in video games and in the space industry. Often they enter those industries because of passion, although I think in aerospace it's more common to stay for longer because you end up working with technologies that just don't apply well to most other industries (lots of DSLs that most businesses don't care about).
As for CRUD glue...hard call about long term labor market. There's a lot of slip-shod working being done to hold up other slip-shod work. I think there's a good analogy in "unregulated construction." You can hire anybody off the street to build you a shed. If you have money to throw at it, though, you still might be willing to pay 15x to hire a well-vetted professional who will make something both beautiful and lasting.
I would seriously have to think about giving up my lifestyle where I don’t make nearly $300K to move to the west coast and work for a FAANG. I like my short commute, good school systems, and my big affordable house in the burbs that would cost at least four times as much if we moved.
No. If you give your current salary during a negotiation, the other end is going to come right back with that salary +5% (at best).
Hidden information is your friend in any negotiation, but especially here, since the hiring folks also know how variable industry salary ranges are. You want to put the first move in their court - decline to give your current salary at all costs, and ideally also avoid offering up your preferred compensation number until they've made a first offer.
The only point where quoting your current salary makes sense is if the company offers less than you are currently making, and you are in such a bad situation at your current where you'd be willing to absorb the pain of changing jobs for no additional money.
This advice functionally doesn’t work. They’ll just intentionally lowball the first offer and then say well they can’t read your mind so you need to tell them what you want.
A better strategy is to really research competitive wages and anchor high by honestly saying what you want. If they can’t come close, then walk away. If they ask you to compromise, tell them you’re not going to negotiate against yourself by stating any specific compromises, that you arrived at what you stated by considering what you’re worth, and that you’re happy to consider any kind of offer they would like to make, but that to accept an offer you have to believe it is competitive for the value you can add.
Any arguments about salaries at different cohorts of companies, or salary bands based on years of experience, just outright ignore and tell them if it’s a dealbreaker, you understand but aren’t going to compromise just because of their pay bands or random assertions about market analysis.
First of all, they cannot force you to give them your current salary. My standard answer to such question is a slightly more polite version of "it's none of your bussiness". And if they don't want to provide a salary range, and ask you to come up with the number, then just give them your current salary +50% and see how they react. Of course you might then need to step down a little, and accept your current salary + 20-30% instead, but that's still pretty good.
They won’t try to force you. They’ll just lowball the first offer, and if you say “that’s not close to what I’m seeking” then they’ll say, “well we can’t read your mind, so it’s unreasonable for you to expect us to just repeatedly guess until we hit the number you want, so you need to outline your expectations.”
If you still decline to discuss a range of expectations at that point, they will usually just drop interest in you and decline to interview you further, assuming that you might just be fishing for a high offer to use to negotiate somewhere else, or that you want way more than they could possibly offer, etc.
Thing is in many cases their low ball offer might still be more than you thought you could get. It gives a lower line, on their terms. From there you can negotiate upwards. After all it is their first offer.
They won't lowball a good candidate. People know that lowballing is a good way to lose a good candidate, that's why most companies will try to get you to state a number first rather than give out a too-high or too-low number.
If you want to know what I have in spending money, I expect the other party to show me what they have as well. It's not a fair negotiation if you play with lopsided rules.
This is the "common knowledge" thing to do, but I don't think it's always applicable. If you have an advantage in the market (e.g. are sought after), you can simply present a high figure and either they accept or you move on to the next. By playing the let-them-go-first game, you're implicitly signalling that you don't know where the ceiling is. On the other hand, if you say a high figure with confidence, they may accept it even if they weren't really prepared for that to begin with. Information asymmetry can also go the other way.
> Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
This is not just IT, this is the entire job market. The reason is because jobs are "sticky" — it's a pain to apply for jobs, arrange interviews, deal with the possibility of getting rejected. If you're successful you also have to deal with possibility of leaving colleagues that may be friends, the risk that the new position is less stimulating, or having to move house or deal with a new commute.
There is a very real salary range between "low enough that I'll think about applying for other jobs" and "so low I'll actually start applying for jobs". Employers are aware of this and are paying salaries accordingly. It sucks for everyone in that salary band but — ethics and long-term viability aside — it's still the rational economic choice for employers. Every now and again someone will quit and get their deserved 40% increase, but many will delay leaving for years, or simply put up with it indefinitely.
edit: Side-note: if you happen to find interviewing and changing jobs more tolerable than most then congratulations! — You've won the job-market pain-of-change-vs-salary arbitrage game and will enjoy above-average year-on-year salary increases.
I think the problem is largely isolated to companies in decline or stagnant -- which unfortunately is most companies.
At a growing company, if you're a growing individual, there's room for you to rise.
At a stagnant or declining company, if you're outperforming your boss, there's a strong incentive for your boss to want to keep you down to keep his/her job.
In a growing company, your boss might be happy to get your promoted to his/her level. Instead of subordinate, now you're a potential ally on the same level. I think in a healthy environment almost anyone would see that as appealing. In a stagnant company, that could be mean your boss loses the job. Almost anyone would see that as unappealing.
> I think the problem is largely isolated to companies in decline or stagnant -- which unfortunately is most companies.
I don't think that's the case at all. I think it's just that typical corporate culture (in the US at least) is not accustomed to giving large internal raises to employees based on increases in that employee's market value.
Most companies base their annual compensation on giving people a few percentage points for cost of living adjustment, then a few more percentage points based on performance. They standardize those numbers so they can say, 'you did average, you get 4%' 'you did great this year, you get 6.5%'.
Many, many companies don't factor in at all that employee value on the market can increase much, much faster than 2-8% per year. Even companies making money hand over fist. The usual way of approaching annual raises is wildly unsuited for compensating talent that is in high demand.
Allies versus competitors. I just made the same observation up thread.
Only once has this gone badly for me, but it went really bad. Tried to mentor a guy, two years later he’s our boss and everybody hates him. Like we go out for coffee to talk about how much we hate him.
Ladder climber extraordinaire. Gotta learn to watch out for those, but in this case he only connived in private and nobody caught on but one and he left.
I keep looking back on past comments and finding stuff like that. I wonder if someone has come up with a homophone/typo mistake filter? Being able to turn that on for opponents one would like to discredit would be really insidious and evil. What if some evil genius at Google has come up with a hidden way to do this in Chrome? Would we ever know? Maybe not, if the frequency was kept low enough.
> Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
From what I've noticed, companies really want to avoid raising salary of an employee in a meaningful way, because it means they will have to increase pay of others also
So 10% increase of salary of 1 employee would eventually equal 10% in crease for the whole team or company, which gets expensive.
This seems to be why they really really hate giving out meaningful raise. They'd rather lose an employee and suffer the consequences, than give 10% raise to one and inevitably end up raising salary for the entire team/company.
And yet, they want to higher senior devs, who obviously left old company to seek higher pay.
> Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
Can confirm. I just got a 54% raise by switching companies. It's absurd. I think a lot of companies just get complacent and don't keep up with the pace of developer salaries, then start leaking talent until it becomes a problem.
My personal best was a 100% pay increase, when I went from being young and naive to "know your worth and negotiate aggresively" attitude :) That was almost 8 years ago, I changed the jobs few times since then, for additional aggregate 50% increase in salary.
> The last time I switched jobs, I got a 40% pay increase. That's ridiculous. I even told the company I was underpaid and they asked if I could wait a year for a raise.
As far as I can tell, management that can see beyond the idea that your current payscale is what you should be payed is pretty rare. There's just something about anchoring on a price once it's negotiated.
My experience is that one of the reasons people will leave is feeling trapped. If they feel like they can easily leave they will stay longer. Not a lot longer, maybe six to eight months. But that’s still up to 20% longer.
> Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
This is a very US-centric perspective. At least in Germany, the situation is somehwat different. Here, changing companies too regularly, often bears a social stigma.
> Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
There's nothing curious or special about the IT industry. It's the same effect as you getting gas at the local gas station rather than driving a few miles to the cheaper station.
I've worked for enough crappy managers that I know how much that affects my job satisfaction and work-life balance. I'm at a point where I'd probably (and, currently do) sacrifice 10-15% of my salary just to work for someone who is respectful and interested in my development and wellbeing. I'd bet others are like me, and if you truly mentor and develop someone, you won't need to pay Netflix-level salaries to retain them.
An employee wants more than money. If I have the feeling that I grow, I stay longer. If I get the feeling that they want to keep me down, I leave sooner. Simple as that.
If you increase the skillset of your employees you get back something along the way, so it's not just money wasted but also collecting a lot of interest. Also you become attractive for employees who want to grow. It's easy for the beancounters to count all the wasted money but it's not so easy to evaluate the real productivity that such employees give back. Maybe if companies were allowed to trade employees like cattle that mindset would change.
Perhaps msluyter was thinking of big companies that smaller ones can't match on spending power.
Either way - if you trained/grown someone to become much more valuable for other companies and still can't create enough value working for you... Then you have a different problem.
This the technically true, but also a very tough starting position.
If my six person startup has issues squeezing as much value out of my Dev than FANG companies with all their support structure and research into this, this is only to be expected, imo.
So yeah, it's a problem, one on the list of many problems most companies have though, so it's oversimplified to simply say:"Let's just pay for expensive training and hope they stay."
Yes, you can foster a culture, build a sense of loyalty etc.
but at some point in time even the most loyal employee feels underpaid if he's paid below market because the company can't afford someone at the stage they've reached by working there. I've seen this play out too often to ignore the counter argument.
The incentives of the company and the worker often simply don't align when it comes to career growth.
Let’s imagine that I work a job for three years, and a company spends $30,000 training me over that time period, when I then leave because that training helped me reach a better career position.
If they hadn’t paid for that benefit, I would have left after only two years — because the need to transfer for career advancement would happen sooner. This would save them $20,000-30,000 depending on how you count.
So what’s the net difference?
In scenario 1, they received a ROI of 1 year of improved labor, and 1 year of doubly improved labor. Additionally, the fixed costs of hiring are amortized over three years instead of two, and so decrease by 33%.
So for $30,000 they decreased my hiring costs by 33% and received two years of increased quality labor — say 5-10% productivity. Hiring an engineer is 25-50% of their yearly salary, so they’re saving 8-15% of my salary over three years. The productivity of an engineer is going to be like twice their salary, just to pay overhead and profit. So we’re looking at a boost of 10-20% my salary in their revenues.
So they’re looking at ~15-25% of my salary as the return for spending $10k/year. Naively, it seems like that pays off in many cases: it just requires you operate in a trust based manner.
> If they hadn’t paid for that benefit, I would have left after only two years — because the need to transfer for career advancement would happen sooner.
That depends on whether employees will switch just to get training, and not just for a bigger salary. If not, then training you will just increase your market value, making you more likely to switch.
What infrastructure do you have in mind? I guess if you employ people from everywhere, there's a bunch of overhead for handling international work contracts, payment etc.
All kinds. From your mentioned international work contracts and payments over structuring the work/code so that in can easier be distributed worldwide,using standardized hardware and software configurations so that adminstration/updating can be done automatically etc.
Maybe in US you do. In UK "laying off" a programmer for anything other than major breach of contract(like being caught red handed stealing) and without making the position demonstrably redundant, takes about ~6 months and it's not a pretty process. Laying off should be the option of last resort, purely because of how incredibly costly it is(not just financially - going through the right steps takes time from both HR and other engineers).
> ...takes about ~6 months and it's not a pretty process.
This fact is clearly expressed in the UK contractor market which seems to consistently pay a 2x premium over salaried employees. Whilst some of this premium may be based on skills I'd wager a lot of it is buying the right to end employment at short notice (either due to poor performance, or simply in response to changing business requirements making the role obsolete).
In the US it’s quite common in a lay-off for 2/3rds of the victims to be unpopular people anyway.
No boss is gonna fight for someone who is getting the stink eye already. The lay-off lets then fire with cause without actually doing it. Kinda cowardly, but I’ve worked at places that cut proactively and things got even more toxic. Conversations speculating about who will get laid off next shouldn’t be a weekly thing. It’s paralyzing.
#2 doesn't work if the company can't get anywhere close to #1.
With no work experience, I was hired as a junior dev with a $40k salary, which I gladly accepted. A senior dev mentored me throughout the year and it was fantastic.
Coming up on my 1-year anniversary with the company, I was thoroughly enjoying my job, the people, and the culture. I was hoping to get a raise up to at least $60k, though, since I was significantly more valuable to the company than I was when I first joined. They offered me $50k.
I started applying for other jobs and got an offer for $90k and I accepted it. I still talk with my mentor from my previous job. He's pissed that his company won't pay enough to keep the developers he mentors.
Great question. I unfortunately don't have a mentor at my new job and it definitely hurt at first. However, I don't regret leaving as I've still learned a great deal independently, perhaps akin to a kid leaving home for the first time to go to university.
I do find mentorship to be invaluable and hope to have a mentor again in the future, though. I am forever grateful to my mentor from my previous job for the foundation he provided. He instilled good habits and philosophies in me that pleasantly surprised some of my new co-workers and we've even implemented some improvements based on what I learned from him.
IMO that devil's advocate argument is incorrect. There is no trap in working to increase an employee's skills.
If you train someone at work and level them up-- they're not in class 8 hours a day not contributing. They are working on a project.
All software mentorship is based around the idea of growing skills while meaningfully contributing to a project. Actually it's much harder to train someone without a project. I have never once in my career seen a scenario where a person isn't contributing and just learning skills.
After said project is done a trained person might leave. But an untrained employee might leave as well-- for a place that offers meaningful mentorship.
> There is no trap in working to increase an employee's skills.
There's absolutely a trap if the now bigger fish stays in your pond for a while and the even bigger management shark decides you can be replaced by him for much less money. As I detail in another subthread in this discussion.
Given the near absolute absence, at least in the US, of rewarding employees who have become much more valuable because of the experience they've gained in doing very real work, you're absolutely right that it needs to be tied to a real project, what you should generally do is complicated even before you factor in the vastly increased probability of it getting you fired. Is the greater productivity your company enjoys for a short period of time worth the shorter tenure of the mentee in it?
> But an untrained employee might leave as well-- for a place that offers meaningful mentorship.
It sounds like we've just had really different workplace experiences in software.
I've never seen a scenario where a trained employee replaces a more senior one. I'm not saying it doesn't happen, but it's just not something I've seen in my career (e-commerce, a food delivery startup gone global and now a consultancy).
Also, I've seen people take jobs that promise mentorship multiple times. I've seen multiple people take entry level apprenticeships that offer rigorous software development training. I've also seen multiple mid and senior level devs leave for jobs that offer meaningful mentorship in management and offer clear career growth options.
So I guess it really just comes down to this: mentoring others can be a trap if the industry or company makes it a trap. It's up to a company to embrace mentorship and training and ensure it works for both mentor and mentee.
Maybe you're lucky, or very good a picking companies and having the luxury of doing so, or maybe you just haven't worked in the field long enough, through multiple nasty downturns in the market. I started my career four decades ago, for "big ones", rode down one metro area's effective end as a high tech region, and lived through the dot com bubble and bust.
I would say it's a mix of all of those things. I have been lucky in my career, but before I went into development I was most assuredly unlucky. I do pick good companies, I've declined jobs from places that paid more but were a quality of life hit. I do have a luxury of choice since I'm younger, but I'm planning my family and saving sensibly so that choice isn't a luxury I can't afford down the line.
But the more I reflect on this thread, the more certain I become that mentorship is important and cost-effective for any industry.
A company that can't justify training and mentorship is either two things: financially poor or culturally rotten.
This is American capitalism, for all it's good and bad, this is a company first society we live in. A company that can't plan to have enough money to train employees is irresponsible. A company that won't train employees is pernicious. Either way, count me out. In the competition of employers I'll take the one that invests in me, and as I've said earlier, I've seen others follow suit.
This isn't some hippy dippy stuff. I don't want a company to cradle me. A company that can't or won't see the value in training its employees to be more effect in the industry its in has to be a special type of near-sighted. For a variety of reasons this is hardly a death knell for them. Plenty of places consider you a liability and glorified typist, they do just fine, but the rot is there and even if it won't kill them, they are a company diminished.
Very few things will work in the presence of incompetent and/or destructive management. This approach can fail that way? Yeah, so can almost everything else. That doesn't actually tell us much about the viability of this approach.
If you have a culture of leveling up people you consequentially level up your whole team... and no matter who leaves, that culture and standards you've set for the team remains.
To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.
The question is why would someone leave your company once you train them? If someone is more valuable on the open market than you are paying them, pay them market rates. HR compensation policies need to be in line with the market, not the old “we have a policy of not giving more than 5% raises”.
I’ve been working in development for a $long_time but I restarted my career about 10 year ago and my rise is about the same as you would see from someone just graduating from college 12 years ago. Out of the four job changes I had, two were partially because the next company was willing to offer me $25K more (not talking crazy west coast salaries here).
One other went out of business and the other because they decided “they didn’t want to be a software company” and they just wanted report writers a year and a half after I was hired as the dev lead.
1. Pay more than everyone around you. (Obviously, not generally viable.)
You don’t have to pay the most, but don’t pay so much under the market that everytime the employee sees a random job posting or a recruiter call they know they can make signifactly more just by picking up the phone/responding to an email.
2. Make mentoring/growth a central strategy at every level so people will see a path to grow.
I'd be curious to hear other possibilities.
That helps. But why would I spend a year a two “growing” at your company, when I could both “grow” and make a lot more money some place else?
I’m at a happy place where I work now, and I am decently compensated compared to the market, but even now if someone was willing to pay me $25K more, all other things being equal (work life balance, no travel, short commute), I would jump ship. But the only realistic way I could make significantly more is by going into management (not interested) or being a consultant (not interested right now).
>>Not only is this a self-fulfilling prophecy, if you don't invest in your employees, the level of waste is larger.
In the long-run, yes. The issue is that most companies optimize for short-term. Managers and executives can receive significant bonuses for keeping their costs down, and by the time the disadvantages of that approach (i.e. people leaving) become obvious, they too have bailed for the next gig.
People choose where to work, and money is only a small part of that decision.
Invest in an employee, give them meaningful and interesting work, and the resources to grow, and you will generate a lot of value that doesn't show up on the books: loyalty.
From the financial perspective, it is almost always cheaper to get more out of a current employee than to go into the market and find someone new.
IMO there are two types of companies: those that know how to develop talent, and those that only know how to import it. The former are often the ones that have a long bright future and create a big impact on the world.
> by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.
This only holds true in a zero-sum game, which the economy is not. Improving the skills of employees actually makes the entire pond bigger.
A business that pursues a poaching strategy will not develop the practices to identify in-house talent. Ergo, you have a hard time understanding anything about employee performance other than you pay a lot.
When you are the one adding the fish to the pond. You know exactly what type of fish it is as it grows. Whereas the fish that you catch may be a catfish rather than a sockeye. The free rider problem is a real thing, but so is the market for lemons.
> But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.
Most good employees don't quit for at better job unless there's a dysfunctional workplace. Partly they don't know if there's better jobs, and partly it's just a lot of effort, but mostly because other companies don't know they're good employees. The labor market is a market for lemons. If you own a $2000 car that drives OK you don't sell it because other people won't believe it's any good.
What I have personally experienced is that since I had an awesome mentor, I've been willing to follow them along anywhere they go and which in turn helps the mentor to get into a leadership role since over time they are effectively leading a group of mentees.
> Make mentoring/growth a central strategy at every level so people will see a path to grow.
I have been following hackernews for 15 years. 20 years since I saw an stallman interview in local pc magazine, blown away by the intensity of the man. I am an artist. I love to read plt stuff and haskell lisp code, I cried over sussman lectures.. It expands my mind, finding ways to express my thoughts so that common people in my world can understand me better, for their sake. I dont write programs, a lot of the code feels unmusical, not ergonomic, my musical background made me aware of how unmusical a keyboard feels like. Learning functional programming has made me aware how most people use imperative chain rule sequences to generate their thought patterns. I would love to work with inspired people just building new ways to express thoughts. But I quietly read and try to translate visions and feelings into code. Writting linear sentences is becoming a drag. It feels as if the time is ripe to raise our conversations to a more constructive functional level. It is happening. It is a slow progress. I can't see myself working in IT because of business deadline material oriented approach. So I continue to quietly read plt stuff. I do not want to understand anything because the other is usually limited to a smaller temporal frame. I read code and apply different real life variables to it and see how the interactions develop within my interaction space. How would you mentor me? /rant
I don't think everyone leaves with the next best salary upgrade if you pay fair. Leveling up a junior should be rewarded in time. Part of the mentoring is to teach them how to fight for your upgrade, right?
Good culture is good, but no culture fits all personalities.
In the end you probably have to accept that some portion of mentees will leave and try to minimize the rate.
What I would be afraid of that grown up juniors may get stuck in their learning environment and remain junior for way too long.
I’m surprised there is not a compensation scheme something like what follows:
Setup: Bring on promising “apprentice” and have 3 year roadmap to reaching “solid individual contributor” status
- year 1: pay at market rate for standard recent college grad but payout 60% in year 1, 10% in year 2, 10% in year 3, 10% in year 4, 10% in year 5
- year 2: beginning of year give merit raise to full salary amount based on market rates but payout 75% in year 2, 5% in year 3, 10% in year 4, 10% in year 5
- year 3: beginning of year give merit raise to full salary but payout 90% in year 3, 5% in year 4, 5% in year 5
- beginning in year 4 get merit raise and receive 100% of salary cash that year as well as the 10% from year 1 and 5% from year 2
- year 5: includes 10% from year 1, 10% from year 2, 5% from year 3
If you can’t keep your employee after that, it’s on you, but they’ve def stuck around long enough to pay you back in productivity
(edit: I realize my math is a bit off but I’m on a cellphone on the move, you’re gonna have to mentally fix the math, but you get the idea)
> Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy at every level so people will see a path to grow.
I think this only goes so far. There are better companies and worse companies, sure, but even the best companies have their issues and after enough time, most people want to move on. People also change, and what seems awesome to a fresh graduate may not be great for someone older, so it's always hard to keep everyone happy.
Pay, however, seems to be a motivator that keeps a lot of people in place (certainly not everyone, but a lot). I know plenty of talented people who feel trapped at their jobs because their jobs pay very well. It's common enough that there's a term for it, "golden handcuffs".
While a developer is being mentored and improving, they’re still contributing to the company for the same salary even though their market value is rising.
Eventually, without a raise in salary, they’ll move to a company that pays market value. So developers aren’t free riders because the aforementioned; the new companies are free riders because they pay market rates.
Edit: it may be a free rider issue if the mentorship / training is orthogonal to their tasks. For example, if Starbucks started to offer their baristas CS classes, it’d be a free ride for employees. But what are perks classified as?
> Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy at every level so people will see a path to grow.
This is why company culture is so important. You may not be able to compete on financial compensation right away, but if you have a culture thats great, enables people to learn and grow and work with other great folks, its very attractive as compared to simply throwing more money.
Not to mention: many folks _want_ that kind of mentorship and culture. They desperately want to learn from smart, experienced developers.
I tend to mentor people I see as promising. Those with leadership potential. Folks I see as future peers with similar values (ethics, quality, teamwork).
If they get far I have a good reference or referral in my future. In the meantime I can offload some of my troubles onto them and worry about other things.
To put it another way, if you think good software requires vigilance, and you worry that there’s a shortage of it, these people aren’t competition. They’re allies.
3. Treat all workers as cogs in a machine that can be replaced at any moment if they are disobedient or fail to do their job right. After all, there are plenty of qualified people lined up to take their place anyway. Bonus points for incorporating foreign workers that can be locked into indentured servitude for many years. If you do it right, your fish can never leave the pond!
> Your mentees will support you and promote you for the rest of your life.
The problem I've seen is that this is rarely true. We've had a big set of grads we've trained that quit for a 20% pay rise, or a project that they happen to like better. Many regretted it but it didnt stop the next guys from doing the same. I'm really burnt out over teaching green newbies again and again.
It's absolutely challenging when you're mentoring people and work starts to look like a revolving door. I've learned over time to reframe my thinking around mentoring and I believe that it has led me to a better place (or, I'm perfectly willing to accept that perhaps I've just deluded myself).
I mentor the juniors and intermediates on my team (and others in the company), but I also consider the activity to be a sort of mentorship for myself, in an abstract way. By mentoring, I'm frequently discovering better ways to teach and better ways to learn. I also seek their feedback about designs and code on the spot and those conversations that I have, with people who aren't encumbered by a lengthy career in technology, help me keep a sort of "beginner's mind," as it were.
The primary motivators that most people appear to have when they talk about mentorship, i.e., tangible benefits to the company, on-boarding, leveling up juniors, etc... are the side-effects to me. The primary motivator that I have when I mentor others is instead the learning and growth, career and otherwise, that I get to experience that would otherwise be off limits to me.
In fairness, all other things being equal, wouldn't you move for a 20% pay rise? Especially at the more junior level, where that kind of increase could probably afford them a significant boost in living standards.
His point may be that devs that are constantly job-hopping for better pay will "experience the same year 10 times" and not grow in skills.
I'm not sure I agree with that viewpoint.
Not devs, but junior devs in particular. Jumping 10 times a year may be for different reasons for experienced people, although some may see it as a red flag.
There is a huge difference between devs that do development for the money and devs that do development because it's engineering. Nothing wrong with this, but it's not a recipe for becoming great developers.
Would you want to work with code monkeys that do whatever they are told to keep/get job or craftsmen that care about what they do?
Why is it either or? Yes I work for the money first and foremost. I don’t learn anything that isn’t going to either make me more money by being better at my job, keep me competitive in the market, or make more money in the future.
Yes I started programming in the mid 80s in my bedroom. But I keep up to date strictly for the money.
Of course not, they should be comfortable to be able to pursue this, but I don't think it's a recipe for becoming great developers. They may become great managers, CEOs, etc.. but not craftsmen.
Would you rely on someone that started their tech career thinking about pay instead of engineering challenges, problems and solutions?
This is simple - pay people by the value they bring to the company upon every annual compensation review.
Yes, it costs money to train people. Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that.
But that’s not the trick. The trick should be that you train your employees how to do your business, and then you pay them more than what they’re worth to someone else. Since you’ve trained them in the ways of your business, they’re worth more than that, but only to you, and that’s the trick. Nobody else could squeeze as much value out of these people as you could (since the training is specific to what your business does), so you can afford to keep them, and the people have no monetary reason to leave.
I never thought about this, but this definitely seemed to be the original thinking at one company I worked for.
As far as I know, the company was started in 2003. The founder wrote a custom IDE, VM and compiler. This was the only company that used it.
He hired a bunch of people from a well known but not well regarded private for profit college and paid them below market rates. Of course developers on this proprietary platform were completely useless anywhere else.
By the time I came aboard in 2008 and the rest of the “adult supervision” - a new CTO and developers - they were in the process of transitioning to C#.
Once the bottom fell out of the market with the 2008 recession, they laid off most of the developers working on the proprietary stuff who hadn’t learned C# on their own. They also forced the founder out. They kept me around because I was the only person who both knew C# and knew enough C++/MFC to maintain the old system.
With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level.
You pay them market when they need to be trained, you pay them market when they move up the skill food chain.
And as such, junior developers don't get hired, because the first 2-3 months of their career, a junior developer is at negative productivity, considering the work the team is doing to start getting them up to speed.
Some of HN works in areas that are harder than the bog-standard CRUD app. So, do you give up on hiring junior developers at all? I believe our whole industry suffers if we come to that conclusion.
This whole CRUD app crap is a cop-out - please don't insinuate it's my lack of experience that has me making this assertion. I've been an engineer for 23 years and spent the first 16 years largely working on large enterprise systems in C/C++, then C#, primarily in the health care space often with some hardware component. Regardless, the work I've done over the past 7 years with modern web tooling is some of the most difficult I've done in my career.
It's a failure of the organization to not utilize entry levels from the first week. At any company. After all, the FAANGs of the world have a different bar of entry.
People keep talking about this like you're literally training people how to program. That's BS. Every org has refactor work, tests to write, processes to improve, tasks to research, low hanging fruit bugs to tackle, systems to blueprint, all sorts of stuff that's a strain on the more sr. staff that's been pushed aside but needs to be addressed. You can strategically bring entry levels up in a way that's a net gain in any environment.
The truth, however, is that a senior developer is $140,000 and a junior developer is $80,000, and that same junior developer will be $100,000 in two years. (This is assuming salaries in one market.) That junior developer will take 3-4x the time to handle the same task as a senior engineer, and will take some of the senior engineer's time to guide the solution, provide feedback, and mentor.
That doesn't mean that we shouldn't hire junior developers - in fact, it's our duty as an industry to hire and mentor. However, it is with open eyes knowing that junior developers are not cost efficient in many areas for the first year.
But we go back to the original statement: "With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level."
If you have $320,000, and can have 3 junior developers or two senior developers with the same budget, the 3 junior developers will be a net loss for the first year. They can be productive, but you have to compare on budget.
___
But I find that as a bizarre set of work that you call out.
* Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback.
* My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers.
* I'm curious what processes you see that junior developers can improve.
* Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break?
* Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit.
* What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.
Pretty much all the things you call out as bizarre I've seen some better interns slice right though.
* Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away.
* Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance.
* Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task.
* Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up.
AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the work that needs to be done. If you run as tight a ship as you imply the sr. devs will be a better bet every time from a value basis - but that's rarely the real world. I wouldn't add more than 1 junior at a time to a team of < 6 devs.
Lastly, addressing "that junior developer will take 3-4x the time to handle the same task as a senior engineer". Well duh, don't give juniors the same work as your seniors. The whole point of hiring lower level staff is you have work that is better suited for lower level staff, or rather, work that is too costly to give your sr. staff. This whole it's our duty to train the next generation... you're running a business, not a charity. And then you get caught up in this cancerous notion of people being in debt to you because you don't know how to properly utilize them.
Not every company is using popular, widely available tech, that folks can learn in their spare time.
In this regard, unfortunately, we are using a proprietary platform and there is no chance to learn anything until you have access to the bits and docs. Due to that, fresh hires are completely useless to be utilized in any way, until they learn at least basics.
You're conflating ramp up time of business domain knowledge with skill level. Yes, a sr. dev will come up quicker than an entry because they have the wisdom and experience of past companies, but all devs need some sort of ramp up in an environment like that. You don't hold back pay from your sr. staff until they've ramped up, right? Of course not, they would take a better offer elsewhere. As would your entry levels that have now risen to mid-levels once they get the chance.
But all the same, any company should be able to make any dev useful from pretty much the very beginning. Whether it's rote refactoring work, research tasks that are too time consuming for more sr. folks, tasks that are in the domain of data entry that can be automated with simple scripts, low-hanging fruit bugs, etc. It's a failure of the org not to properly utilize the abilities of a smart person who knows how to program.
> pay people by the value they bring to the company
That's a fun game. Most people can argue endlessly about who is responsible for what and then you get to disclose where the money (and how much) is actually coming in. It necessarily constrains the management to a whole new slew of in-fighting and disclosure control. Never gonna happen.
> pay people by the value they bring to the company upon every annual compensation review.
how do you determine the value they bring to the company? Presumably it must be a % of the revenue or valuation growth but I cannot come up how you derive the value.
How do you determine the value of any candidate you interview? You have a job req. Do they match that req? Yes, good, you make them an offer. What level of pay do you negotiate? What is market. If they're otherwise happy going toward the bottom of market is feasible, esp. if it's a large bump.
If this person goes out the door, you're going to be paying their replacement roughly the same as what they'll negotiate elsewhere... and on top of that, you have to deal with the cost of turnover. You basically just lost a ton of $$ by letting them walk. This is not hard. Just run the thought experiment of what it would cost to find a suitable replacement.
Simple. How much would it cost you to pay someone to replace them at market rates and then add the amount it would cost you to give them time to ramp up on the institutional knowledge and codebase.
Well, not really. The phrase was specifically about how much value they bring to the company. Market rates have no meaning in this context. E.g. how is "if a team works on a product that no customer seems to use/purchase/pay for, what is the value that team brings to the company" connected to market value? I would say it isn't.
If you want to keep the employee you have to pay market rates or they can easily leave. If the team works on a product that no one wants, that’s the fault of the business side. It’s up to the business to either find something for the tea to work on or let them go.
You’re taking the use of that word too literally. I meant it as what perceived impact would the addition/omission of an engineer of that level have on a company? The stuff that factors into determining annual budgets.
The end result is hiring trained developers for the price of trained developers, and sending the inexperienced developers to be trained somewhere else. Where? That's their problem.
See? Looking just for one's interests works both ways.
You act like you’re doing them a favor by hiring them. You’re not. You’re trying to get cheap labor, and expecting them to feel indebted to you and work at below market rate. It’s not going to happen.
Pay them cheap during training. After they’re trained, pay a premium to the ones you want to keep. Let the rest go to a competitor. It’s simple.
If you can’t afford that, that’s a problem with your business, not the employees.
We are not trying to have cheap labor. We are trying to have more labor. However, the experienced people are limited resource, so the next step is to find inexperienced ones and train them.
However, that doesn't work that way so easily. If you train someone for 6-12 months (during that time the trainee not only isn't making you any money, but other people, who otherwise would, are not either), you are investing into these people. If they leave before you break even, you are at loss. If you would pay them market rate as soon as they finish training, you would never break even.
That's why some companies insist on contract, that the trainee will stay with the company for specified time, if they take the training.
Very carefully, during interviewing. Until now, it worked, even though mistakes happen. It is not scalable long-term, so we will have to find something else.
The truth: I’ll leave for a large enough increase in salary all other things being equal.
What I say at interview: “I love building things. I’ve been interested in computers since the mid 80s when I was writing 65C02 assembly language on an Apple //e. I guess you could say that I have always been a computer geek. I’m still amazed after all of this time that I get paid for doing something that I enjoy this much. On my way to work everyday and while I am working out I’m listening to $list_of_tech_podcasts. I try to spend at least 1 hour a day outside of work just keeping up with technology.”
Any developer with a modicum of emotional intelligence can get pass behavioral interview questions because really, the interviewerer doesn’t expect much from computer geeks and most developers.
How would you know that I am really just in it for the money? I’ve been on the interviewer and interviewee side of the table just as long or longer than most people who interview me. I’ve been through $big_company “how to interview candidates” training. Of course I know the answers you’re looking for.
Oh and the old geek who likes to continuously learn helps to answer the question am I keeping up with technology and why I am not in management.
Yes, they train full time. That's what a proprietary platform (not ours, third party, but hey, at least it has its own wikipage) will get you. Not even the build system is standard. Yes, they are paid salary. Very few people can afford to go several months without salary, that would filter out some candidates that proved to be right match in the end.
And that's the reason why the wage ramp up is slower, even after finishing the training.
That's a different situation then. A lot of companies make trainee employees sign a bond. To my knowledge all the Indian software consulting giants have one. If an employee leaves before the term is fulfilled (typically 2 years) they have to pay the company. It's usually on the order of 20-40% of an entry-level employee's annual salary. Otherwise the company can withhold references and experience letters, which are usually needed in future.
If you already have a bond/contract system in place and employees are still leaving, then IMO you're still paying them too little. If they are happy to pay 20-40% of their annual pay just to leave the company, it means they can make 50-100% more elsewhere. Loyalty is worth something but it's not worth passing up a pay raise that high.
What type of training program would be worth signing a contract for? Alternatively do like Amazon and offer deferred compensation that takes four years to fully vest.
Right now, we directly outline the plan: for now, you will be getting less, once you start working on the client work, your pay will ramp up, depending how much weight you can pull.
Do you not see how there is value in having someone who is trained to your specifications? You're still getting labor out of someone but when they move to being a proper dev you don't have to worry about any training issues because you trained them.
I truly doubt you hire developers who are productive from day one, when your mentees will be productive from day one as a real dev AND will probably have less growing pains from having learned bad habits or a different standard at another company.
if you pay them better they won't leave. But you've basically said that even after training they are worth less than someone you hire in at first. This distinction is why people leave. You trained these people in the way you'd like them to work, Tailor-made to your processes but you still say they aren't worth the same as the people you hire-in. No wonder they leave and go some place where they've now been hired in without needing to be trained. If you don't value your own training highly enough to pay these people the market rate, what reason do you expect them to stay and work for you for?
Because it is still more expensive than just hiring b).
If you decreased a) wages during their initial training to cover the costs and be able to break even with b)-like wages at the end of the training, you wouldn't be able to hire anyone as a) at all.
I take the world how it is; including human behavior. On the other hand, you assume someone owes you a training and a then immediately a wage that is the same as someone's who came with all the skills needed.
Put yourself in the shoes of the board of directors and you'll find they too don't want to overpay for CEOs. But paychecks are market driven, and lowering the pay means you'll end up with a less experienced or worse CEO.
I guess that would be a problem if board members were willing to take a hit on profitability to load up their pal. Maybe shareholders don't notice, or while the market is doing well they don't question it.
> the companies run by the CEOS who were paid at the top 10% of the scale, had the worst performance. How much worse? The firms returned 10% less to their shareholders than did their industry peers
By that metric isn't Amazon the worst company there is?
To their credit, Amazon is pretty diligent about making sure that high performing employees get pay raises to match their market. My record is a 30% raise, mostly by switching job functions from non-tech to a tech role.
Right but you're already paying out the money it sounds like, in terms of burnout and churn in employees. 20% could be cheaper.
And I guess people are grateful for training, but not if they're effectively paying 17% of their pay for that training indefinitely. They'd be idiots to take that deal.
Can't afford a good raise, but can afford to spend 60% of their time interviewing people every 6mos. Does anybody track the lost wages from the hiring process as a cost of employee churn?
You should be following their lead. There is no reason to expect mentees to stick around for a long time if they can go command a meaningful salary and quality-of-life bump somewhere else.
I understand the psychology around not putting more resources into your existing staff -- it's basically "why buy the cow when you're getting the milk for free?" -- but as long as this "5% per year is a great raise!" crap is going around, no one a) upper-mid-level or lower; with b) market value; and c) corresponding self-esteem; is going to stay in a specific job more than 2-3 years. There's no reason to expect anything else. If this is going to change, companies are going to have to start working hard to curb the "impulse buy" psychology at work in racing to get $BUZZWORDY_CANDIDATE_X.
Despite this, there is great personal value in mentoring people. You learn a lot and establish a supportive substructure within the community. It's better to have your mentees move around. That way, they can throw you an escape line if you need it.
People who stay at one company for too long end up with a rusty skillset and a heavily distorted perspective on how things operate. Companies may not notice it, but their cheapness is probably a much better thing for the goose than it is for the gander. Circulation is healthy.
Sounds like you’re managing to get the work done, even with the constant churn. If you can make it work, why should the boss pay your mentees more? May be time to look at other options yourself.
Sometimes their value to you is less than their value to someone else. You may need them, but the value they bring to the business has to pay off. That puts a hard limit on what you can pay for that skill.
It can suck to run a business - sometimes there's no good solution. I'd suggest more contracting for necessary-but-non-critical skills, but contracting's a jungle too.
Takes a while for people to learn. That time is way more expensive for everyone involved because it also costs you on the mentor side. I've figured out a thing: lots of strong engineers want to work with other strong engineers. They want to execute. So I give them that and they leave places where they spend most of their time trying to support or teach other people.
And if someone is too junior based on our initial phone call, I just direct them elsewhere and hit then up two years later when those guys have mentored them. Way easier.
Assuming a perfect market (or good enough market), you could just raise the pay for the position and hire someone experienced enough to justify that price rather than grow someone into that role.
The market incentivizes this behavior perfectly well. People are just unwilling to admit the true cost of turnover, mostly for psychological reasons. There's a lot of ego to protect when a colleague says "I'd rather work somewhere else".
In my experience, if you narrow the focus of "you" from the company to you the mentor, "will support you and promote you for the rest of your life" can happen. Although it sounds like a certain amount of delicacy is required in the vast majority of companies like your current one where they have to move to get rewarded for their increased value.
There also might be some relevant variations in corporate cultures around the world, what you say rings true for the US, but the author is in Estonia.
I feel for you, but then again, why do you keep hiring newbies? You get what you pay for.
Also, maybe the employee is worth the 20% pay bump after you’ve trained them? It sounds like you’re letting another company enjoy the fruits of your labor at a relatively cheap price.
The distinction here is between a hunter-gatherer mentality and an agricultural one.
Are you picking and choosing or are you farming?
Currently we grow engineering skill in (often) high cost institutions with limited capacity such as traditional universities. Moocs and bootcamps are alternatives which try to address the scalability, cost, and time commitment barriers of traditional education.
The question is should there continue to be a strong dichotomy between organizations who consume the output of these growth channels and the growth organizations, or should software development companies create programs of structured education and growth that have a low barrier to entry?
As others have mentioned startups who can hunt/find/pick people with relevant, high quality skills have the advantage of not paying the time and organizational cost of training.
Personally I think that large organizations should be taking more hands-on approaches that take all, or nearly all comers, and then provide training for the kinds of skills they need.
If you look at military funding for medical educations (for example) you'll see that the organization can be very generous in terms of time and training cost as long as a candidate ends up with the skillset they need. You might not go in wanting to be a urologist, but you can end up highly skilled and very well paid if you're willing to meet the needs of the organization.
I have, to some degree, given up trying to hire senior developers. Instead, I'm doubling down on the internal training programme (and have hired extra juniors).
5% of time is set aside for training. Works out a little over a half-day every fortnight - every fortnight, after lunch on Friday, drop the code and hit the books, pet projects, videos, experiments, whatever clearly makes you a better software engineer. If you don't spend that time on your own training, questions are asked. Nobody has been fired for not training yet, but if we get someone who simply refuses to, I could see it going that way; when we hire someone, we're not just hiring that person today - we're hiring that person next year, and we're banking on that person next year being better at this.
There is CapEx for books. We have PluralSight licences. New starters' agreed objectives include reading and thence using "Effective C++"; I will come by your desk every so often to chat about parts of it. We have short presentations every fortnight (the time of which doesn't even come out of the 5% training time) on technical topics. Once you've covered the basics, the company starts contributing towards conference attending.
The last senior dev who got internally promoted currently has an allowance of 50% of his time for helping more junior devs understand things. Fifty percent! The intention is to get his senior dev knowledge and experience out of his head and into the heads of five other people; growing ourselves five more senior devs.
I got all this by asking for it. Grow your own. Everyone wins. The company wins, the employees win. Just had to ask; if you ask, and your company isn't interested in improving, isn't interested in producing better products, faster and cheaper... well, is that really the company for you? :)
"The last senior dev who got internally promoted currently has an allowance of 50% of his time for helping more junior devs understand things. Fifty percent! The intention is to get his senior dev knowledge and experience out of his head and into the heads of five other people; growing ourselves five more senior devs."
I am pretty senior and I like mentoring people. But the incentives are generally the other way: If as an IC I transfer my experience to new people I almost get no credit. The manager of the group gets credit for building a good team but I have to justify my salary compared to the people I mentored. So sometimes I wonder if it would be smarter to keep knowledge to myself so I can look better.
I certainly sympathise. In a strong culture, when you mentored someone, their achievements and success would reflect on you. The boss would see your cohort doing well, and give you a pay rise for your fantastically valuable contribution to the company. "Thank you, maxxxxx, for making these junior software engineers 50% more effective," the boss would say. "Why, you've had the same effect as hiring two or three more people!"
But if your culture involves ranking and paying people only relative to each other, I can understand the need to protect yourself. And everybody loses :( The company loses, you lose, the potential mentees lose :(
Another factor is that by mentoring my own output goes down a lot. If I get interrupted several times a day to help then I get nothing done on my own stuff. I think on overall it's still a big gain for the team but I look worse.
That calls for setting clear boundaries, and proactively checking in/interrupting your mentee when it's a good time for you to take a break.
I like metrics based on how much time the other person has and expects to waste not being able to do anything productive, which strongly suggests you should give him at least two things he can be doing, an obvious second one being reading documentation or otherwise researching necessary stuff he doesn't yet know. After a certain number of hours it's worth an interruption.
And there's the reverse effect that teaching someone else forces you to better learn the subject, so you should gain some extra productivity from this.
Which implies it was only valuable to future companies you worked for. Those that actually believe in mentoring, which seems to be rare based on what others are saying and my own experiences.
This is great, but only when you've already got enough knowledge and experience within the organisation to enable it. That's where you really need to hire senior developers. Trying to grow a team of juniors into a team of seniors without enough guidance, grows teams of expert beginners, which is way worse for both the team and the organisation in the long run. You won't be able to hire or retain seniors in that sort of environment as they'll see it for what it is and leave.
However, that's not to say training people up shouldn't be done! I've seen some wonderful developers grow from junior to senior and it's always great to see it happen. Just make sure the organisation is in a position to do it well, otherwise you're doing both them and the juniors a disservice.
That's a good point. One of the places I worked hired a ton of juniors and placed them under "senior" team leads, but the leads were too few, not exactly all-stars, and code quality was all over the place. I tried to have a positive influence on some of the eager new hires, with varying success (mostly because I wasn't very senior either, just a little further along than they were).
Eventually the environment became frustrating enough that I had to move on. Great people, really friendly environment, and even a product I believed in, but it felt so bad to keep having to read through awful, giant, bug-ridden code reviews with the same old rookie mistakes. I only had enough influence within my own team to slow the rate of bad code entering master, but it still came alarmingly fast. I think nobody from my team is still at that company. I really hope management has turned it around since.
Maybe I'm just a grump, but: 5% is pretty low number for training people up. Perhaps that's just the "hit the books on your own, but during work time" portion? If it includes other things (talking people though a project that's on the edge of their capabilities, discussing the architecture of important project from an educational perspective, ...) then it seems pretty low.
It is, I believe from talking to others and my own experience, significantly higher than the average (outside the mystical FAANG etc).
The average is basically zero.
Talking people through things at the edge of their capabilities and discussing the architecture etc that they need to know; that's just doing the actual job, surely.
We are trying to build our own internal training program.
Beyond the language-specific training, what books/courses have you found that are super useful. For example, would you ask someone to learn design patterns or something like that ?
We're in a labor market in which CS students are focused on drilling for the FAANG-style whiteboard tests. And many will tell you their strategy is to go to Google for 2 years of experience and resume-building, and then leaving rather than grind away and play the promotion game there. And everyone has known for 20 years that you have to job-hop to grow your salary in this industry. And most employees would be naive to think that their employer would take care of them long-term.
In this mercenary environment, loyalty doesn't go very far, so, for retention after mentoring, I assume one would have to pair mentoring/training with substantial growth in compensation. Besides all the non-monetary attractions.
My last company would insist that they couldn’t give promotions or significant raises. Until you came in with an outside offer, then they’d roll out the red carpet and bend over backwards to keep you.
It breeds distrust, discontent, and disloyalty.
The best people don’t like this and leave. They company is left with people who can’t land outside offers. And the company ends up needing to pay market rate anyway to replace the good people who left.
This works for the company because most people don't bother interviewing and coming up with a counter offer. In my previous company the best of the best would leave because company had this blanket policy that they would never do a counter offer. But in overall it was good for the company because they were able to retain most of engineers with raises as little as 1% and no stock refreshers.
I actually prefer that policy. At least they stuck to their guns.
We had an inexperienced junior dev come in with an “amazing offer.” This signaled to management that he must be amazing, so they offered a promotion to team lead to keep him. Half the team quit within a month, then he proceeded to run everything into the ground.
There was a certain amount of shadenfreude watching that play out.
We're in a labor market in which loyalty has and should have disappeared a long time ago. I used to have a nice stable job (7+ years), very happy with my 'arrangement' but then wall street rankings started a process involving layoffs.
I didn't get affected by the layoffs but after about 5 rounds where some of my friends/acquaintances got the boot, I saw the writing on the wall and actively started looking outside. Because it's way more comfortable to be laid off when you have an offer in hand. That's when I realized how underpaid I was. Since then, I made it a professional goal for myself to switch jobs every 2-3 years so that I don't leave money on the table, as the only loyalty I have is to myself and to my family.
Every company, after a while, will start paying you less if you don't climb the corporate ladder to go into management. They will pay you as less as possible considering the risk of you leaving, slowly transition you into working on the old stuff while the new hires will get the green projects. Ok, I'm generalizing but nobody can deny that newcomers are always treated better.
But mentoring transcends companies. I still have great professional relationships with past direct reports working in other places and more often than not they still ask for advice when it comes to their overall careers.
What if you reverse this - loyalty goes very far, it's just that companies don't offer it. If you are fulfilled in your job, why would you want to leave for a grind?
I love the point the author raised in this article. Companies are spending a ton of money on recruiting and paying commissions to recruiters. If some of that money and effort is channelized toward mentoring, a company can notice a significant change in quality in its workforce. That said, this article fails to address 2 major issues or provide any solutions for that:
1) Every decent size company spends for providing resources like books, learning portals etc. for their employee to grow their skills. There is an entire industry running which caters to provide companies learning tools, for example - safari online books etc. Mentoring is also used a buzzword in these companies. There is a difference between providing tools & books vs creating an environment where people can grow. Mentoring is very inter-personal. Unless companies create incentives for senior engineers to help mentor other engineers there won't be any real change to the way things are now.
2) If your teams or Orgs are always battling to meet the next deadline, how will mentorship happen? You can't expect people to put more than 40 hours of work and expect them to personally mentor other engineers(They still do btw).
This article assumes that the person you are mentoring is open to being mentored. I’ve worked with some engineers who were definitely junior despite having years of experience and very opposed to even a slight suggestion on how to improve their thinking process or implementation process.
On the other side of spectrum there are those people who "really want to learn real programming" but you have to do all the work for them. You point them at the resources, contribute ideas and it turns out person is not following through even though when they talk they are enthusiastic.
So basically you have to somehow spot right person to spend time with, and it is hard. At least guys that don't want to be mentored are not time sinks.
This too, I’ve also worked with people like this, it is extremely frustrating to teach someone who wants to be mentored not take your mentorship advice and continue to make the same mistakes.
The counter argument here can be that I possibly may not have mentored the person in the right way using the right motivation, but methods I tried were (ranked in succession):
1.) Showing by example but asking to come up with own examples
2.) Templating examples
3.) Listing out steps
4.) Finally just directly asking to do x, y, and z
Utilizing data patience time boxing.
This is definitely a difficult problem I don’t particularly have an efficient solution to, my best answer is just find someone to mentor who will execute
This sounds like a wonderful idea in a business culture not obsessed with burning tomorrow to a crisp for more return today. Not to mention this requires trust and loyalty, both rendered cruel jokes by the all-against-all knife fight that our (in the US) labor market is.
At what size of company does this pay off? My experience of hiring juniors is generally that they are net negatives to productivity for quite a while, and the smaller the company, the more significant the impact of that is. How do people here go about mitigating that?
In my experience, at two developers. You just have to hire a junior capable of significant growth and who starts out at some level above "helpless", which I'll admit is hard. And of course be able to create small bits of work he can do on his own with a moderate amount of help.
On the other hand, if the company is so overloaded that they really would like for you to put in 100 hours of real work a week.... And if they stick all the developers in an open office, forget about it.
Don't have proven techniques, but have been toying with an idea I'd like to try the next time I have the chance.
Have been thinking of starting a "farm team" to develop green programmers. Have a meetup once or twice a week, work on a focused project together, do mutual code review. Read the classics (e.g. the MMM) as homework.
Perhaps give out some Amazon gift cards for good work. When a participant levels up, move them to a paid role.
That's what I think Isaac (Sendgrid founder) is trying to do with JoyLabs.
I had the pleasure to meet him when he came to Mexico and he talked about the idea of "pairing" a very junior Engineer (from Mexico) with a very senior one from top companies in the USA to grow them, even covering the English language teaching.
The theory sounds very good but man, at least I was afraid that he was overestimating what "Junior dev" means down here in Mexico (from my experience hiring in MX and US, MX-Senior = US-Mid-Level, MX-Mid-Level = US-Junior).
This sounds like such a great idea! I saw in a sibling comment that you might lean towards doing these in person, but I could see it working well remotely also.
Agreed, however am in Los Angeles. Would recommend remote but this type of thing might be better in person. Perhaps each city can create their own. Even in LA there'd probably need to be a group in each part of town, like west, downtown, and/or Pasadena.
I'm game location-wise from about Hollywood to DTLA, however not in a hiring position right now. Will be looking for a gig of my own shortly as my current contract finishes.
This seems to strike a chicken and egg problem. Who will grow the talent? It seems you'll need to hire the mentors for that. And what's the level of growth possible? Isn't that capped by the level of your senior devs?
As far as I know, most interview processes are designed to hire potential. For example, if you can't learn fundamental algorithms in a reasonable amount of prep time to prepare for the interview, but someone else could... Which talent has the most likely potential?
I'd even go and claim that the current interview processes are biased against senior talent. Someone who already knows they are qualified won't be motivated to go and practice fundamental algos that they haven't needed for real work in years. They'll expect their own track record and knowledge to be recognized on it's own. But, the interviews won't care about that. And they might instead hire a junior with more time and motivation on their hand, which decided to spend all evenings for the last two months doing leet code questions.
Similarly, many companies seem to favor new grads, which they can quickly brain wash into their existing engineering culture. They think, these new grads really strive, instead of challenging the status quo, they internalize our processes and work hard to deliver, even if we're being unreasonable. Eventually, this creates a lack of perspective in the entire company. Hiring more external senior talent would help get more perspectives, and prevent this silo of opinion that hurts innovation over time.
> And what's the level of growth possible? Isn't that capped by the level of your senior devs?
Senior devs who are good at mentoring also ought to be good at learning new stuff. They'll also be learning some things from the mentees, at least some of them will know stuff they don't know because our field is so vast.
Once the mentees catch up? If you've inculcated a learning culture, these new senior devs will be learning new things right along with the old ones.
I have never seen a single company/startup place a job posting for a junior position, (lucky if they even say training)
Last time I checked, everyone wants to look for a senior developer with 5+ years of experience. It's some sort of hidden bonus if you're from a FAANG company as well.
I'm guessing everyone wants to be the next Google, Facebook, Amazon, Netflix or Uber.
Right because 10+ year people are expensive and there's the stigma of spending your whole career as a programmer. After 5-10 years, most companies expect you to move into a specialized field or management.
I don't agree with that stigma at all, but it's there all the same.
That would be the case if one read such postings literally.
It is best to disregard the bullshit in job postings and just apply if you can demonstrate some proficiency with some key skills. Or better, make contact with someone in the organization before applying.
It's not about meeting the job description. It's about being better a better choice than the competition.
Every new grad, intern I've worked with has done an amazing job hitting the ground running. They're not ready for "here's a big problem, please dream up a solution and get it out the door", but with reasonably laid out tasks they do a fantastic job working out the code and improving their technical chops along the way.
Juniors who are eager to learn are my favorite employees
>Every new grad, intern I've worked with has done an amazing job hitting the ground running.
You've been incredibly lucky. It's great when it happens, but it's certainly not the norm (speaking from experience at a well-known organization that hires a lot of interns).
> They’re just giving them the “senior” title ridiculously early in their careers.
Yes, companies are usually more eager to throw out titles than they are to throw out dollars. True seniors need to push much harder on the compensation aspect to give these companies a sense of scale, and ideally, start pushing back on working with 23 yr old "Sr Directors".
It's a substantial failure of the field that for most people, there isn't a lifelong career trajectory that doesn't require moving into management.
Meh, in pretty much every company I've seen there are lots of entry level jobs to be done. Sure, you can ask an experienced developer to take care of them, and they will, but they'd rather apply their skills to more challenging tasks, or you could give them to a beginner, let them figure it out and run it by a more experienced dev to review.
We've done that with a guy that had been out of programming for half a decade but wanted back in. Within half a year he was a great asset. I believe it's more about whether the person is happy to learn something new, not so much what they already know.
Had someone respond to a job ad for a senior dev last week with 18 months experience. I was skeptical. I've never seen anyone develop senior level soft skills in that timeframe, and skill with requirements and design and so on seem to take a lot more time than 18 months.
The article is not only on point but it reflects a big problem in the tech companies.
Businesses loose millions and they just burn cash because of toxic and arrogant developments teams.
I can quadruple the sales of the company that I work for but you cannot push any change through the arrogant development team who don't give a chance to other people, it is so pathetic.
Trust me, there are arrogant developers out there and they suck to work with. They treat code and design reviews as chest beating exercises. They refuse to work on anything remotely legacy. If their idea or design gets questioned in any way they get loud and obnoxious. You can't mentor these devs at all.
You have to be careful what you're good at. If senior devs/management sees you're good at legacy, they might task you with that as a majority of your time. Then your career plans get sidetracked because you won't have as much time working on the stuff that you want to work on.
Some developers are okay with legacy, but if they aren't, it's not surprising. Some legacy stuff is absolutely horrible to work with - it devolves into "get-in-get-out" fix mentality (and security issues usually get swept under the rug). Some legacy products are good though and require minimal tribal knowledge to actually work on.
This has happened to me twice at two separate positions: bait-and-switches about what I'll be working on because more senior members wanted to offload the legacy work themselves.
The general arrogance is really a separate trait from willingness to work on legacy IMHO and I agree on those points.
I agree with all but the last sentence. Every dev has a different background. Every dev needs to adjust to a different style of work wherever they go. Some will figure it out on their own. For the rest, I find it hard to believe that adding a mentor into the picture doesn’t improve the odds.
> you cannot push any change through the arrogant development team
I worked at a company that did this. Eventually customers start demanding stability as a feature. There is a huge difference between arrogance and wisdom.
> I can quadruple the sales of the company that I work for but you cannot push any change through the arrogant development team who don't give a chance to other people, it is so pathetic.
The best developer thing is really frustrating and ultimately a failure. Companies always claim to want the best during hiring, but once hired that completely goes away. What they really want are a couple good developers and rest somewhere between mediocre to brand new.
To really see the paradox ask extremely controversial questions during the interview. As a frontend developer ask about process efficiency or interacting with the DOM without a bunch of framework bullshit.
We have to live in the world as it is, rather than what we'd like it to be. The well reported in this discussion patterns of your boss trying to replace you with your mentee, getting dinged for not getting "real work" done, and mentees not staying in the company for very long should give anyone pause.
> Ok, so the guy is in the training and conference business. That would seem to skew his perspective.
> Usually the people who talk loudest about mentoring are clueless or are in the teaching business.
Can we not do this? By all means, respond to the article and the points he is making (which in my mind are good ones), but dumping on the industry the OP is in contributes nothing.
How can you mentor people if you are afraid of being fired or replaced by a "cheaper" mentee? To mentor people, you have to be a professional developer, at the first place.
Professional developers achieve job security by doing great work and making themselves replaceable. Mediocre developers – by building knowledge silos.
> Professional developers achieve job security by doing great work and making themselves replaceable.
Wouldn't that be "achieve career security"? Because as I attest upstream in this subthread, in my most notable example of being a mentor, I was indeed fired as soon as my non-technical salesman background CEO decided I was replaceable. Although he didn't realize that wasn't quite yet true, and the mentee decided to leave instead of working in such a place.
I don't know about Estonia, but in the US conventional careers as a software developer start ending when you're in your 30s, with 40 being a hard limit in finding a new conventional job because that's when our national age discrimination law kicks in.
That fresh out of college except for one short job mentee? The only reason he's still a programmer a quarter century later is that within a decade he got a high level security clearance, which is sufficiently onerous for the company that pushes through that process, they have to "bench" or otherwise have the employee work on non-classified stuff for many months, that after getting it you're in a small pool that companies vastly prefer to recruit from.
This is intimately connected to being a good mentor since a fair amount of experience is required to do a good job of it.
> I don't know about Estonia, but in the US conventional careers as a software developer start ending when you're in your 30s, with 40 being a hard limit in finding a new conventional job because that's when our national age discrimination law kicks in.
In the US, I found a new developer job at 43, and another at 47. Haven't looked in a decade, so I don't know how it goes at 57.
Caveat: I'm in embedded systems, which is a much more senior-friendly world than web apps.
As you say, you're in embedded systems, that's well known to be the other US employment domain that's friendly to developers with grey hairs. Not a "conventional" field.
And you should expand on this with situation and timing details. In a talent starved startup like the one I was in, mentoring a nearly fresh out of college entry level employee was the only way to get the project completed in the available time ... except that very directly sowed the seeds of the destruction of both the project and the company.
Most US companies' management of software developers is horrible, see open offices, Agile as its actually practiced, etc. So I would expect the outcome of this process getting you replaced by your mentee to be common.
In that light, consider timing your mentoring period, which as I note can intrinsically be very rewarding, and I'd argue is vital as paying forward for the mentoring you yourself received, for when you want to leave your current company.
And since getting fired for doing a really good job is psychologically devastating for most if not nearly all people, and at least in the US makes it significantly harder to get a new job, don't wait to get pushed out, start your job search at an appropriate time. Especially since it's really unlikely you can't continue your mentoring after you leave the company, I certainly didn't, to this day. Although by now we're both so experienced, in somewhat divergent sub-fields, that the continued learning goes both ways.
I mentor people for the same reason I automate things; at the end of the day I'm lazy and I'd rather concentrate more on the things that matter to me. It that means I can teach someone else how to do the work that I don't want to do but they'd love to do, then more power to everyone.
Especially when 30 seconds of following links shows the author is almost certainly not a native speaker of English. That the only problem was substituting "at" for "in" should have been a clue.
> In the real world, there is zero reward for mentoring.
In my experience, it can result in a life long friendship, and getting the project to alpha level in time.
> Moreover, if you do it, you might get fired and be replaced by the now cheaper mentee.
Strangely enough, that too happened. While it was cold comfort to me, it did kill the company because the mentee hadn't yet learned enough to cover all the areas I was expert in, and he didn't want to work in a place like that.
I have found the premise of the title to be completely false in real life. Not much else to say to this - I haven't seen too many people grow, and when we hire someone great, they are great.
Are they given time during normal work hours to grow? Are they given adequate assistance and resources? Is training a priority?
I've run into two different situations in my work life:
a) You should learn new tech and keep up, but it's all on you, your own time and discretion (outside of work). It was expected to do project work 100% of the time on the job.
b) It's expected for you to learn and grow and we will help you get there. $ for training/conferences. It's expected that you will spend a decent amount of time out of your 40 hr work week improving yourself and learning new tech.
In situation A, I would have been (I was!) labelled as someone who lacked the will. It was hard to put in a full day and do more at home, learning new stuff. I still did it, but it was difficult. I was burnt out by the time I left that job.
In situation B, I feel like I can live a normal life. I can learn, do my projects (I'm more productive), and go home at night and enjoy my time off and weekends. I feel like a normal person living their life.
It takes me around 4 weeks to figure out if someone can grow or not. There are exceptions though. Some people are almost traumatized by previous jobs so they need some time to learn that it's OK for them to grow.
As a junior developer currently looking for a role on a great team, I'm curious about your process. Why does it take ~ four weeks, and what are some of the markers that tell you 'yep, this is a great candidate who'll grow quickly'?
I usually give new people a task I understand fairly well myself, that they don't know much about but can easily be researched because it's well documented. So I expect someone to research the problem, develop some level of understanding and then be able to discuss options. I don't like it when people copy a piece of StackOverflow code and don't understand it.
I also prefer people who are naturally curious about tech vs people who just want to do the job. I don't like overtime but I like to discuss and try new ideas during working hours.
Yes! This is something that is not just about developers and seems to be a huge gap in hiring.
Go look at any big company job listings. There are many positions that have no "entry level" roles. The lowest level of experience will say "5 years of {x}".
If you're a company that does not take people without experience, where do you think they're getting the experience? You're relying on other companies to train your employees, and naturally you're not getting a chance to create the exact employee you need.
Hire people that are intelligent, humble, and willing to learn. Ignore credentials, and promote from within. In most situations, you'll get the right result.
Aside: The weirdest part is there are some positions that seem to not have entry-level jobs anywhere in the industry, you have to sneak into them. For example my girlfriend is a "Brand Strategist" at a web design agency. This is what she always wanted to be, but when she was applying it seemed that every Brand Strategist job required 2-3 years of Brand Strategy experience. So she applied to her company in a role she didn't really want and then basically talked her way into the new role. Obviously she's doing well and she will never face this barrier again. But that was a stroke of good fortune.
this is exactly what global investment banks do ... they hire a fresh crop of a few dozen smart motivated young perspective programmers and put them through 9 months of intensive work study multitasking classroom lessons in software problem solving together with IT operations experience where everyone gets a very broad exposure to the technological landscape ... these banks repeat this every 3 months with yet another new crop so there are three such sets of new recruits on an ongoing basis ... after the 9 months these ~graduates~ are assigned into programming roles and just boot themselves into their new positions ... key here is they start with razor sharp people from any field ( philosophy, science, humanities ) who have exhibited problem solving potential ... also key is the business can afford to offer this in-house training while the new hires are getting paid ... baked into this equation is the nurturing of loyalty and admiration toward their employer - deservedly so I might add
I don't think a general discussion on this topic can really be had.
In my experience of working for shitty enterprise software, good and bad consulting firms (and seeing how their non-tech clients work), and silicon valley startups. The company financials, work culture, job market are all vastly different, impacting all the trade-offs of different hiring method.
i.e. some firms simply cannot afford top-of-the-market pay for senior engineers they want to hire, so they hire more junior ones and train them, who eventually leave after they're trained, but people don't immediately jump to next ship paying a little more, so you end up getting good work out of them for a period of time while underpaying them.
Some companies compete on non-momentary means.
Some pay top of the market rate, but only hire seniors.
Some pay top of the market rate, and hire from all levels; some of the juniors rise up through promotions, and some didn't get recognition despite growing, so they leave for other companies.
Some companies simply don't care about engineering quality, or does not have the ability/DNA to differentiate between good and bad work.
Also in silicon valley, networking and mentoring good engineers is much more professionally rewarding than in smaller markets.
I guess the cynic in me would ask what the point is in polishing a rough gem in your organization into a diamond, if you're thus turning them into a target for other people to poach.
You get the first dibs, don't you?
If you need a diamond level dev, you must provide diamond level compensation. The article just points out that it is simpler to get that level from other sources than filtering what is on the market.
Companies want talent for cheap. Every time I see in the news companies complaining that they can't find employees, I think to myself, why don't you pay more?
Add to that, if you start at a company and become a rockstar developer, admin, or QA guy chances are they will not value you as much as if you came in as the rockstar developer, admin, or QA guy.
That's roughly what they do at my company. Many people in the company have some form of Computer Science certificate/degree, so shouldn't be that hard to make them develop...but you hit the Peter Principle much faster in this line of work. The CTO loves the hanging on by the seat of your pants optics. "Look at him go. He doesn't have any idea what he's doing, but he's getting it done. That's what we want." The rock stars puff up and grouse about the recent QA to senior DEV promotion, then ridicule them, then you find out the rock star has been working until past one every morning since part of their responsibility as a lead is to make sure the QA-cum-Senior Engineer's work is code complete. Then they leave. And yes, then a great developer is hired...but they never tell us where they're going...
Okay. I'm fine with agreeing with the notion that good, productive engineers can result from good environments.
But that doesn't mean hiring 'broken toys' is a good idea. This article's message is 'Can't find anyone good? That's okay! Hire someone anyway and mentor them!'
Turn this stone into a diamond!' Okay. Some stones don't turn into diamonds. Gee...if only there was some sort of process that can help determine which people are capable of being a good engineer. Maybe companies can do something like asking some basic questions about a candidate's ability. Something like a filtering process.
'The pond is empty.' Pfff. No it's not. If no one's biting at the rod, it's because of shitty bait.
We have tried this with 3 different candidates:
1. No experience last year in university
2. No experience with BS
3. 1 year working experience
My experience with this approach is that it is a far more expensive investment that takes long time to pay off. The safe ratio that I can recommend is 5 seniors to 1 junior
This discussion reminds me of the fixed vs. growth mindset, in the book Mindsets:
"In a fixed mindset, people believe their basic qualities, like their intelligence or talent, are simply fixed traits. They spend their time documenting their intelligence or talent instead of developing them. They also believe that talent alone creates success—without effort. They’re wrong.
In a growth mindset, people believe that their most basic abilities can be developed through dedication and hard work—brains and talent are just the starting point. This view creates a love of learning and a resilience that is essential for great accomplishment. Virtually all great people have had these qualities."
I started in IT. I very quickly realized I could do a lot of tasks the other support staff weren’t willing/able to do, like learning regex and database normalization. Kept getting more dev related tasks since my boss was the only software engineer at the small startup.
Rather than get rewarded or hired as a developer by the company, as the support team grew I was headed toward being promoted to the support manager. They brought on someone else as a dev and that really made me realize I’d never be a dev in the CEO’s eyes. Bosses daughter did an internship so she got the coding tasks I would have gotten before. I was taking more phone calls with idiots from places like The Federal Reserve who didn’t know how to Google “hoe to format a hard drive”. So I left and doubled my pay.
Some managers just believe what you know is set in stone and you can’t progress or learn anything new. It’s a really bizarre mindset to have when a devs most important skill needs to be the ability to learn. Didn’t all these same people go to school?
> Bosses daughter did an internship so she got the coding tasks I would have gotten before.
In my experience at a couple of places, the moment you learn its a nepotistic environment you should leave as soon as you reasonably manage. As you saw, it's a sign of very bad management, the sort that can easily kill a company, see Wang Laboratories for perhaps the most famous example in the US.
Great developers can be hired. For example, you raise the developer, I double his salary and hire him away from you. Not saying that I advocate this practice, but this is what happens in SV.
I can agree with hiring novices and then giving them what they need to learn. We hired two women from Fullstack Academy (NYC) and they turned out to be amazing. They were novices, but incredibly motivated and talented. Both of them had had other interesting careers, and for both of them they were changing careers to get into computer programming.
Now we are expanding the team so we are hiring another of their classmates, who they have strongly recommended to me.
from my experience the only way you get better salary is to jump around, not too often, but if you stay with one company for two long(say, 5+ years), you become the lowest paid at your level in general.
only if you're on the management ladder you want to stay longer, for tech and engineering roles, the old employer does not really appreciate that much after you're loyal for too long as far as compensation goes, very ironic but it's the way it is.
A “self-confident rockstar“ is just a developer who has been through this process of self-development and no longer requires the mentoring and extra effort to get them there.
I appreciate that some companies value experienced developers and aren’t trying to nickel and dime by finding “broken toys” so to speak that they can force into their own moulds on the cheap
As a developer, I want to work with people who are at least as knowledgeable as me, and preferably much more so. I want to spend my time learning what I do not know, not teaching what I do.
You must be a junior with a few years of experience. Even so, you should discover that teaching will boost your knowledge a lot. Being surrounded by more experienced people may give you a short term boost, but teaching what you already know will deepen your knowledge in what you only think you know, which is way more important to improve.
> You must be a junior with a few years of experience.
You may say that, although that would stretch the word junior to the point where it is hardly meaningful anymore. Judging by Twitter threads and Medium posts that have become so very inclusive and protective of juniors, a junior (usually discussed as applied to web development) is someone who has hard time configuring build tools, is still uncertain about syntax of their primary programming language, and is easily scared by a smidgen of functional programming (such as the reduce function). I wonder where they would fit in your classification :-)
That’s totally fair (and there indeed was a time when the typical response to my resume was, "we are not looking for juniors") :-)
But this argument makes sense only from the collective standpoint (as in, the industry in general). Of course developers have to be trained by someone, because otherwise there will be no dissemination of knowledge, no passing down of experience, and no qualified workforce. So of course that should be done.
The question is, whether you (as a programmer on a team looking for new members, or as a company looking for new employers) need to be doing this, or whether it's all right to let someone else do this while you look for already well-trained and experienced professionals.
But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted. One might argue that if everyone put more fish in the pond, then we'd all be better off (true), but we have a standard collective action problem where the free riders benefit at the expense of the fish growers.
I see two (partial) ways out of this trap.
1. Pay more than everyone around you. (Obviously, not generally viable.)
2. Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy at every level so people will see a path to grow.
I'd be curious to hear other possibilities.