Live data from Hacker News

Great developers are raised, not hired

sizovs.net

51–60 of 341 posts

Re: Great developers are raised, not hired

#51
post #29

Earlier quoted context omitted.

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

> almost get no credit Delivered four senior developers in order to accelerate our team's velocity... that's what my resume says.

I never even considered that. Thank you. I'm going to have to remember to add more "soft skills" and accomplishments to my resume.

Re: Great developers are raised, not hired

#52
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?

Re: Great developers are raised, not hired

#53

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 someon…

>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…

It's not "what if they go elsewhere" under that situation, it's "when".

This is gold. It's just a specific application of, "You shouldn't fight market forces, if you can help it."

Simply coming close to parody

parity

Though, this started me thinking on what "parody bits" would be.

Re: Great developers are raised, not hired

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

https://mindsetonline.com/whatisit/about/index.html

Re: Great developers are raised, not hired

#55
post #45

Earlier quoted context omitted.

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 p…

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.

Re: Great developers are raised, not hired

#56
post #29

Earlier quoted context omitted.

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

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 p…

If the saying "A rising tide lifts all boats" doesn't hold in your company, I'd say that's definitely a dysfunction.

Re: Great developers are raised, not hired

#57

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 someon…

[deleted]

Re: Great developers are raised, not hired

#58
post #56

Earlier quoted context omitted.

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 p…

If the saying "A rising tide lifts all boats" doesn't hold in your company, I'd say that's definitely a dysfunction.

Isn't that pretty common? "A rising tide lifts only the boats of a privileged few"?

Re: Great developers are raised, not hired

#59

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 yo…

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

Re: Great developers are raised, not hired

#60
post #52

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.

Post reply on HN