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.
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.
edit/ words.
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?
All of the above is IMHO of course.
Yes I started programming in the mid 80s in my bedroom. But I keep up to date strictly for the money.
Would you rely on someone that started their tech career thinking about pay instead of engineering challenges, problems and solutions?
Thinking otherwise is why gullible developers will work 60+ hours per week while the owners get rich.
Or give them projects they're more keen to work on?
[0]https://www.forbes.com/sites/susanadams/2014/06/16/the-highe...
By that metric isn't Amazon the worst company there is?
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.
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.
Otherwise said, at-will employment doesn't incentivize intensely investing in growing people.
So you can a) hire someone who needs training and then train them, or you can b) hire someone who is productive since day 1.
The people in a) cannot expect the same salary as b). Otherwise, there would be no point in incurring the costs of training them.
Unfortunately, once you train them, someone can snatch them as people in b). You incur the loss, someone else benefits.
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.
But this "someone" includes the current employer.
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.
That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.
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.
You pay them market when they need to be trained, you pay them market when they move up the skill food chain.
If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.
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.
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.
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.
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.
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.
* 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.
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.
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.
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.
See? Looking just for one's interests works both ways.
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.
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.
They're training full-time? They're not even doing junior-level work? Why are you paying them a salary then?
> other people, who otherwise would, are not either
Senior folks are getting valuable experience of mentoring and growing people too.
And that's the reason why the wage ramp up is slower, even after finishing the training.
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.
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.
You don't, if they leave too early. That's the point.
> hire developers who are productive from day one
That's very rare, true. It was meant to illustrate one extreme. But there is still a huge difference between both ends of the market.
At least that’s always the answer over at r/cscareerquestions
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.
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.
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.
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.
The relationships I've formed with people have always been more valuable than the relationships I've had with companies.
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.