4 ms·

> It's not a myth they exist, but you shouldn't depend on them. It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than o

by emrah 5y ago

> It's not a myth they exist, but you shouldn't depend on them. It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay. Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.

rualca 5y ago
> It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay. Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others. We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.
- angelzen 5y ago
  MapReduce. Leveraging lower level abstractions incipient in the early Google datacenter (distributed FS, distributed process executor) and providing a simple but expressive programming model for distributed large scale batch computations. A significant amount of effort went into documenting and exemplifying the usage of the programming model for a large number of use-cases. Chosen to serve thousands of use-cases all across a fast growing company. Developed by 2 people. A fantastic example of '10[00]x engineering', and yet I can't imagine something more antithetic to the 'lone gunman' strawman.
  - samhw 5y ago
    I think Jeff + Sanjay is arguably a better example of 100x developers. Goes way beyond just MapReduce. Edit: I just noticed that you said the same yourself. Great minds...
- tracker1 5y ago
  A really good developer can and will absolutely outpace a couple small teams of developers. The shortcomings is the domain knowledge is locked in one head. You gain and lose a lot depending on how many people are involved and how much you have to communicate. Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.
  - kragen 5y ago
    As the MapReduce example shows, the domain knowledge is not necessarily locked in one head in cases like this. I haven't heard complaints from Googlers about how Jeff and Sanjay write unmaintainable code, either. My own non-Google experience is that extremely productive programmers tend to write code that's more readable, not less readable.
hinkley 5y ago
One of the hard lessons I've learned in software is that force of will can make any development or management process work for a little over 12 months before the cracks really start to show. By then people (and by people I mean folks who don't think the way I do) have cemented that process in their heads as working and they want to ignore the data that says it doesn't. If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.

by emrah 5y ago

rualca 5y ago

> It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay. Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others. We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.

angelzen 5y ago
MapReduce. Leveraging lower level abstractions incipient in the early Google datacenter (distributed FS, distributed process executor) and providing a simple but expressive programming model for distributed large scale batch computations. A significant amount of effort went into documenting and exemplifying the usage of the programming model for a large number of use-cases. Chosen to serve thousands of use-cases all across a fast growing company. Developed by 2 people. A fantastic example of '10[00]x engineering', and yet I can't imagine something more antithetic to the 'lone gunman' strawman.
- samhw 5y ago
  I think Jeff + Sanjay is arguably a better example of 100x developers. Goes way beyond just MapReduce. Edit: I just noticed that you said the same yourself. Great minds...
tracker1 5y ago
A really good developer can and will absolutely outpace a couple small teams of developers. The shortcomings is the domain knowledge is locked in one head. You gain and lose a lot depending on how many people are involved and how much you have to communicate. Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.
- kragen 5y ago
  As the MapReduce example shows, the domain knowledge is not necessarily locked in one head in cases like this. I haven't heard complaints from Googlers about how Jeff and Sanjay write unmaintainable code, either. My own non-Google experience is that extremely productive programmers tend to write code that's more readable, not less readable.

hinkley 5y ago

One of the hard lessons I've learned in software is that force of will can make any development or management process work for a little over 12 months before the cracks really start to show. By then people (and by people I mean folks who don't think the way I do) have cemented that process in their heads as working and they want to ignore the data that says it doesn't. If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.