3 ms·

That’s a good question, even if I disagree slightly about the premise, as random large open-source products targeting consumers (as opposed to infrastructure pr

by vtail 5y ago

That’s a good question, even if I disagree slightly about the premise, as random large open-source products targeting consumers (as opposed to infrastructure projects like Linux kernel) can dramatically vary in quality. My hypothesis: devs are much closer to users, as they are often users themselves, and have more freedom to work on fixing broken experiences, as opposed to just rolling new features.

ItsMonkk 5y ago
Exactly. Linus was able to out-compete a team of hundreds of Microsoft Engineers who spent years building a Source Control system by himself within a span of 10 days when he built git. You can't take Microsoft Source Control, add a few stories, and end up with git in a Sprint. You can't split that work up between different teams. The essence of git is in a unified design that matches the essential complexity of source control requirements. When you play the game of telephone from user to sales to program manager to project manager to architect to lead developer to UX designer to DB modeler, each step along the path introduces errors. Those errors made the system harder to design for, harder to scale, and harder to use. Linus was able to cover every element of those to a passable degree himself. You need to empower your developers. If they don't use the product, if they are not dogfooding, you have no chance to compete against those that are.
- belval 5y ago
  IMO Linus is a very unique, one in a million, engineer building a proto git in 10 days is really not a common feat and is the result of a mix of passion and focus that is very hard to replicate. That being said, I agree with the general point that having vision and trusting your developers with their vision can be a winning strategy.
  - lfairy 5y ago
    I think it's less "passion" and "focus", more his position as the Linux lead giving him first-hand experience with change control at scale. He didn't need a product manager to gather requirements, because he already knew them. That's basically what ItsMonkk is saying, but I think it's worth making it more explicit. Because a one-in-a-million engineer is not replicable, but a deep understanding of your users' needs is.

by vtail 5y ago

ItsMonkk 5y ago

Exactly. Linus was able to out-compete a team of hundreds of Microsoft Engineers who spent years building a Source Control system by himself within a span of 10 days when he built git. You can't take Microsoft Source Control, add a few stories, and end up with git in a Sprint. You can't split that work up between different teams. The essence of git is in a unified design that matches the essential complexity of source control requirements. When you play the game of telephone from user to sales to program manager to project manager to architect to lead developer to UX designer to DB modeler, each step along the path introduces errors. Those errors made the system harder to design for, harder to scale, and harder to use. Linus was able to cover every element of those to a passable degree himself. You need to empower your developers. If they don't use the product, if they are not dogfooding, you have no chance to compete against those that are.

belval 5y ago
IMO Linus is a very unique, one in a million, engineer building a proto git in 10 days is really not a common feat and is the result of a mix of passion and focus that is very hard to replicate. That being said, I agree with the general point that having vision and trusting your developers with their vision can be a winning strategy.
- lfairy 5y ago
  I think it's less "passion" and "focus", more his position as the Linux lead giving him first-hand experience with change control at scale. He didn't need a product manager to gather requirements, because he already knew them. That's basically what ItsMonkk is saying, but I think it's worth making it more explicit. Because a one-in-a-million engineer is not replicable, but a deep understanding of your users' needs is.