4 ms·

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too.

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / cultured away. * If your lead/management doesn't get that then they're in the wrong job, get out. * If you see shady consultant types and "thought leaders" talking about something, then it's just the latest bullshitchain. * If you see a junior developer say "this is easy", then let them learn the hard way, but manage expectations. * If you see Senior level engineers constantly say "this is easy" when the problem isn't clear, then run for the hills * The 10x engineer is only true in special cases and does not generalise. * That ^ is why you need to work together so everyone is doing their 10x task. * Incompetent engineers and bad actors can act as negative 10x engineers. * The vast majority of people on the outside of the team (consultant types) are worse than the above. With interviewing I have decent results just having an open form conversation, looking first for personality and drive and getting an idea of their technical knowledge by seeing how deep they can go (or if they even can go deep into a subject). References from someone competent dominate, mind.

theshrike79 6y ago
One more from me, with 20 years of experience. Some people are force multipliers. They make everyone around them more efficient. BUT people like this are hard to determine with Standard Performance Indicators. Personal anecdote: I had to fight tooth and nail to keep a junior coder in my team because "she wasn't performing well". Yes, she didn't commit often and her code quality was average at best. Tasks took longer than average to complete as well. But what she DID DO was keep the two auteur seat-of-their-pants 10x coders in her team focused and on task, made sure to ask the correct questions and had them document their work. She also took over their customer-facing stuff so the socially awkward 10x pair didn't need to do that. None of this showed up on standard performance indicators. Now she's a team lead at the same company, managing the two 10x-ers.
- radicalbyte 6y ago
  Totally agree; I'm now very similar to your example, only I came from being one "the" 10x-er. Then I worked with another 10x-er at the same time as we had our first kid. With no sleep and no time to learn I could remain a 10x-er so transitioned into a Tech Lead (and am now moving towards CTO). Now I spent my time optimising/running the system of software creation and delivery, being the face and the glue - because hey, that's me.
dvfjsdhgfv 6y ago
> * The root cause of the above is often insecurity; and it can be coached / cultured away. It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.
- greyhair 6y ago
  In thirty five years, I have encountered three zealots that became worse over time, because their zealotry was seen by upper management as dedication and resolve, so they were rewarded. As we all know in engineering, positive feedback is bad. It was awful. But luckily only three times in thirty five years, so I have that going for me.
bengale 6y ago
I’ve been saying for a while I’m pretty sure I can hire decent developers based on a conversation and not the assault course hiring process that’s normally used. Now I’m sure for certain roles, highly specialised stuff that isn’t true. But I tend to be hiring for teams building pretty standard stuff, line of business tools, general saas products, etc. For this you just need smart, reasonably experienced people who are easy to get along with and ask decent questions.
DrBazza 6y ago
> * Incompetent engineers and bad actors can act as negative 10x engineers. I worked with an engineer, let's call him Mark, whose 'talent' was to get involved in everyone else's problems during the stand up. When I first joined, he was 6 months late delivering his own project, which was eventually a year late, and that was the reason. He was a drag on the entire team. Rather than stand ups being a way of learning what everyone else was doing and offering help later, it turned it into guarded, cryptic, monosyllabic updates, lasting seconds. He'd spend half an hour at someone's desk after the stand up, trying to get up to speed on 3-6 months in 25 minutes to knock out a 5 minute solution that never worked. He was asked to leave and productivity soared. "Don't be a Mark" is still a phrase in our company.

theshrike79 6y ago

One more from me, with 20 years of experience. Some people are force multipliers. They make everyone around them more efficient. BUT people like this are hard to determine with Standard Performance Indicators. Personal anecdote: I had to fight tooth and nail to keep a junior coder in my team because "she wasn't performing well". Yes, she didn't commit often and her code quality was average at best. Tasks took longer than average to complete as well. But what she DID DO was keep the two auteur seat-of-their-pants 10x coders in her team focused and on task, made sure to ask the correct questions and had them document their work. She also took over their customer-facing stuff so the socially awkward 10x pair didn't need to do that. None of this showed up on standard performance indicators. Now she's a team lead at the same company, managing the two 10x-ers.

radicalbyte 6y ago
Totally agree; I'm now very similar to your example, only I came from being one "the" 10x-er. Then I worked with another 10x-er at the same time as we had our first kid. With no sleep and no time to learn I could remain a 10x-er so transitioned into a Tech Lead (and am now moving towards CTO). Now I spent my time optimising/running the system of software creation and delivery, being the face and the glue - because hey, that's me.

dvfjsdhgfv 6y ago

> * The root cause of the above is often insecurity; and it can be coached / cultured away. It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.

greyhair 6y ago
In thirty five years, I have encountered three zealots that became worse over time, because their zealotry was seen by upper management as dedication and resolve, so they were rewarded. As we all know in engineering, positive feedback is bad. It was awful. But luckily only three times in thirty five years, so I have that going for me.

bengale 6y ago

I’ve been saying for a while I’m pretty sure I can hire decent developers based on a conversation and not the assault course hiring process that’s normally used. Now I’m sure for certain roles, highly specialised stuff that isn’t true. But I tend to be hiring for teams building pretty standard stuff, line of business tools, general saas products, etc. For this you just need smart, reasonably experienced people who are easy to get along with and ask decent questions.

DrBazza 6y ago

> * Incompetent engineers and bad actors can act as negative 10x engineers. I worked with an engineer, let's call him Mark, whose 'talent' was to get involved in everyone else's problems during the stand up. When I first joined, he was 6 months late delivering his own project, which was eventually a year late, and that was the reason. He was a drag on the entire team. Rather than stand ups being a way of learning what everyone else was doing and offering help later, it turned it into guarded, cryptic, monosyllabic updates, lasting seconds. He'd spend half an hour at someone's desk after the stand up, trying to get up to speed on 3-6 months in 25 minutes to knock out a 5 minute solution that never worked. He was asked to leave and productivity soared. "Don't be a Mark" is still a phrase in our company.