6 ms·

If your a senior dev it’s part of your role to help the junior ones out. You should cultivate that behaviour as it brings up the quality of your colleagues and

If your a senior dev it’s part of your role to help the junior ones out. You should cultivate that behaviour as it brings up the quality of your colleagues and builds work relationships.

Communitivity 5y ago
Let's say you are the cryptid 10x engineer/tech lead, supervising a team of 8 junior engineers. You can spend 4 hours, the equivalent of a 40hr week of lesser mortals (this math is almost never true in my experience), or spend a half hour of time on each of your junior engineers. The problem you help each of them solve is solved in 30m as opposed to the 3-4h they might have tried solving it themselves, and they've learned something that maybe saves them an hour a day. You do this twice during the week. You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain. Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs. You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.
- jokethrowaway 5y ago
  This requires an environment where long term productivity is more important than short term productivity, it doesn't account for juniors who won't get it, no matter how hard they try, it doesn't account for juniors who will leave the company after becoming more proficient because they can't get an adequate payrise. 10x engineers can be a good match for startups where shipping now is essential and for big businesses who need something done quickly (for a change, the bigger the company, the slower everything else). The only cons of 10x engineers is that they will burn out and that they're incredibly rare. Advising 10x engineers to help out other and collaborate is also nice to give them a bit of down time so they don't burn out and leave for the next startup with a 50% raise. That said, it's not like HR managers are able to distinguish between senior low productivity engineers and 10x engineers, so it doesn't matter. No company will have a strategy around employees productivity. I disagree the 10x engineer is a myth, as an hiring manager, I can easily tell you who is a 10x engineer after working with them for a year or so.
pc86 5y ago
I draw a corollary to how graduate medical education works. You go into residency a fresh doctor with zero applicable skills. You may not even be CPR certified, but you're an MD/DO, and you've matched into a residency. You know less about actually helping people than a nurse who's been on the job for a month. You spend the next 3-7 years working 80-100 hours a week learning your chosen specialty. You become an absolute expert at your specific field. If you're in a surgical field you spend thousands of hours practicing and performing the surgeries you'll be responsible for. You may or may not specialize even further with a fellowship for another 1-4 years. Then, when you graduate and can start making real money (probably), if you work at a hospital that does resident education, you're almost immediately expected to let the residents do as much as they can safely do, so they can learn. You go from working 80 hours a week performing surgery after surgery at a senior resident to working 30 hours a week watching the senior resident perform surgery. Similarly (and admittedly it isn't a perfect analogy) as a junior and mid-level you're spending all this time learning how to write real software. Most of it's bad and especially at the junior level you're going to spend a couple years being more trouble than you're worth in terms of productivity. But by the time you're a senior, when you theoretically know what you're doing, you're going to have to spend most or a large portion of your time helping out the juniors in your org. If you don't want to do that, you shouldn't be accepting senior positions. Or at least, go work somewhere where they don't hire juniors.
- wanderingmind 5y ago
  And yet a junior dev who LCd for a few months will get paid way more than a MD in residency. It might be interesting to see if the quality of people (measured with IQ) or some other simple metrics who pursue medicine relative to other fields have gone down over the past decade.
- thegrimmest 5y ago
  What if you just want to write software and not be responsible for mentorship? Why do capable individual contributors always have to be roped into leadership?
  - BurningFrog 5y ago

If your a senior dev it’s part of your role to help the junior ones out. You should cultivate that behaviour as it brings up the quality of your colleagues and builds work relationships.

Communitivity 5y ago

Let's say you are the cryptid 10x engineer/tech lead, supervising a team of 8 junior engineers. You can spend 4 hours, the equivalent of a 40hr week of lesser mortals (this math is almost never true in my experience), or spend a half hour of time on each of your junior engineers. The problem you help each of them solve is solved in 30m as opposed to the 3-4h they might have tried solving it themselves, and they've learned something that maybe saves them an hour a day. You do this twice during the week. You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain. Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs. You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.

jokethrowaway 5y ago
This requires an environment where long term productivity is more important than short term productivity, it doesn't account for juniors who won't get it, no matter how hard they try, it doesn't account for juniors who will leave the company after becoming more proficient because they can't get an adequate payrise. 10x engineers can be a good match for startups where shipping now is essential and for big businesses who need something done quickly (for a change, the bigger the company, the slower everything else). The only cons of 10x engineers is that they will burn out and that they're incredibly rare. Advising 10x engineers to help out other and collaborate is also nice to give them a bit of down time so they don't burn out and leave for the next startup with a 50% raise. That said, it's not like HR managers are able to distinguish between senior low productivity engineers and 10x engineers, so it doesn't matter. No company will have a strategy around employees productivity. I disagree the 10x engineer is a myth, as an hiring manager, I can easily tell you who is a 10x engineer after working with them for a year or so.

pc86 5y ago

I draw a corollary to how graduate medical education works. You go into residency a fresh doctor with zero applicable skills. You may not even be CPR certified, but you're an MD/DO, and you've matched into a residency. You know less about actually helping people than a nurse who's been on the job for a month. You spend the next 3-7 years working 80-100 hours a week learning your chosen specialty. You become an absolute expert at your specific field. If you're in a surgical field you spend thousands of hours practicing and performing the surgeries you'll be responsible for. You may or may not specialize even further with a fellowship for another 1-4 years. Then, when you graduate and can start making real money (probably), if you work at a hospital that does resident education, you're almost immediately expected to let the residents do as much as they can safely do, so they can learn. You go from working 80 hours a week performing surgery after surgery at a senior resident to working 30 hours a week watching the senior resident perform surgery. Similarly (and admittedly it isn't a perfect analogy) as a junior and mid-level you're spending all this time learning how to write real software. Most of it's bad and especially at the junior level you're going to spend a couple years being more trouble than you're worth in terms of productivity. But by the time you're a senior, when you theoretically know what you're doing, you're going to have to spend most or a large portion of your time helping out the juniors in your org. If you don't want to do that, you shouldn't be accepting senior positions. Or at least, go work somewhere where they don't hire juniors.

wanderingmind 5y ago
And yet a junior dev who LCd for a few months will get paid way more than a MD in residency. It might be interesting to see if the quality of people (measured with IQ) or some other simple metrics who pursue medicine relative to other fields have gone down over the past decade.
thegrimmest 5y ago
What if you just want to write software and not be responsible for mentorship? Why do capable individual contributors always have to be roped into leadership?
- BurningFrog 5y ago