4 ms·

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).

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? :)

maxxxxx 8y ago
"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.
- EliRivers 8y ago
  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 :(
  - maxxxxx 8y ago
    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.
    - dfrage 8y ago
      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.
  - davemp 8y ago
    If the saying "A rising tide lifts all boats" doesn't hold in your company, I'd say that's definitely a dysfunction.
    - maxxxxx 8y ago
scaryclam 8y ago
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.
- epscoe 8y ago
  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.
anarazel 8y ago
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. EDIT: non-phone spelling
- EliRivers 8y ago
  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.
- maxxxxx 8y ago
  5% is pretty low to basically nothing. I agree.
  - EliRivers 8y ago
    It's very low and, from my own experience, significantly higher than average. My experiences are almost entirely UK based, outside big name or hip companies.
    - maxxxxx 8y ago
      True. Usually training is 0%.
- ikeyany 8y ago
  5% = 2 hours out of the entire week It's basically 4 conversations and that's it.
sandGorgon 8y ago
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 ?

maxxxxx 8y ago

"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.

EliRivers 8y ago
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 :(
- maxxxxx 8y ago
  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.
  - dfrage 8y ago
    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.
- davemp 8y ago
  If the saying "A rising tide lifts all boats" doesn't hold in your company, I'd say that's definitely a dysfunction.
  - maxxxxx 8y ago

scaryclam 8y ago

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.

epscoe 8y ago
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.

anarazel 8y ago

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. EDIT: non-phone spelling

EliRivers 8y ago
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.
maxxxxx 8y ago
5% is pretty low to basically nothing. I agree.
- EliRivers 8y ago
  It's very low and, from my own experience, significantly higher than average. My experiences are almost entirely UK based, outside big name or hip companies.
  - maxxxxx 8y ago
    True. Usually training is 0%.
ikeyany 8y ago
5% = 2 hours out of the entire week It's basically 4 conversations and that's it.

sandGorgon 8y ago

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 ?