This is inspired by the Horowitz Good Product Manager / Bad Product Manager paper. Good engineers are not always good, and bad engineers are not always bad. I believe in both the ability and necessity of personal and professional growth. I apologize to Ben Horowitz and humbly beg his forgiveness for my otherwise blatant plagiarism.
Good engineers understand the product they’re building. A good engineer researches, understands, and has a vested interest in data center operations when they’re building systems for data center operations, and high frequency trading and markets when they’re building systems for high frequency trading and markets. Bad engineers are not interested in the product and focus exclusively on the technology within the product. A bad engineer only sees trees, no forest.
Good engineers care about what customers want and need, and can quickly separate the two. They understand that customers sometimes ask for a faster horse, and in doing so help them figure out that a car needs to exist. Good engineers understand that the right product comes from a mix of deep internal domain experience and innovation, as well as iterative improvement and feedback from users. Bad engineers think customers are stupid and that users “just don’t get it.” Equally, bad engineers also always build whatever feature is asked of them without understanding why they’re doing so.
Good engineers care about the business. They know that without sales, there would be no money; without marketing, no one would know who they are or why people should care; without finance, they’d burn through all their money or go to jail for not paying payroll taxes; without administrative staff, the company would descend into chaos. Bad engineers believe that if they don’t understand what someone does then that person is not important; they fail to see that many don’t understand what engineers do nor how building software actually works.
Good engineers understand the real world and can operate within reasonable constraints. For example, customers do not upgrade software as soon as it’s released, companies have good reasons to run older versions of operating systems or databases and that not everyone has root access. Bad engineers see no value in backward compatibility. Bad engineers tell customers or support staff to upgrade the OS’s included python interpreter with a rpm out of EPEL because, honestly, 2.6 is ancient! Good engineers understand that quality, timing, performance, features, and maintainability are all important and make tradeoffs where necessary and appropriate. Good engineers anticipate and understand the logistics of deploying production software. Bad engineers can’t figure out why we don’t just rewrite the entire codebase in a new language today. Bad engineers are inflexible and intolerant of less than ideal circumstances.
Good engineers participate in positive, constructive debate over critical topics, and know when to let an argument go. Good engineers know how to disagree and commit, and help others do the same. Good engineers aren’t afraid of their own failures, and do not hold the failures of others against them. Bad engineers fight to death over tabs versus spaces, shave every yak, and paint every bike shed, sometimes more than once. Bad engineers point out every time they were right.
Good engineers can communicate complex ideas at the appropriate level for the audience. Bad engineers often cannot communicate at all.
Good engineers are good humans. They fundamentally understand that everyone usually has good intentions. Good engineers believe in collaboration over competition as a default mode and aim to hold everyone to a high bar. Good engineers know that good engineers come in many different forms. Bad engineers believe all other engineers went to the same school they did, have the same experience, or are the same gender, color, or sexual orientation as themselves.
Good engineers beget good engineers. Bad engineers believe there are no other good engineers.
Source: LinkedIn
Good engineers understand the product they’re building. A good engineer researches, understands, and has a vested interest in data center operations when they’re building systems for data center operations, and high frequency trading and markets when they’re building systems for high frequency trading and markets. Bad engineers are not interested in the product and focus exclusively on the technology within the product. A bad engineer only sees trees, no forest.
Good engineers care about what customers want and need, and can quickly separate the two. They understand that customers sometimes ask for a faster horse, and in doing so help them figure out that a car needs to exist. Good engineers understand that the right product comes from a mix of deep internal domain experience and innovation, as well as iterative improvement and feedback from users. Bad engineers think customers are stupid and that users “just don’t get it.” Equally, bad engineers also always build whatever feature is asked of them without understanding why they’re doing so.
Good engineers care about the business. They know that without sales, there would be no money; without marketing, no one would know who they are or why people should care; without finance, they’d burn through all their money or go to jail for not paying payroll taxes; without administrative staff, the company would descend into chaos. Bad engineers believe that if they don’t understand what someone does then that person is not important; they fail to see that many don’t understand what engineers do nor how building software actually works.
Good engineers understand the real world and can operate within reasonable constraints. For example, customers do not upgrade software as soon as it’s released, companies have good reasons to run older versions of operating systems or databases and that not everyone has root access. Bad engineers see no value in backward compatibility. Bad engineers tell customers or support staff to upgrade the OS’s included python interpreter with a rpm out of EPEL because, honestly, 2.6 is ancient! Good engineers understand that quality, timing, performance, features, and maintainability are all important and make tradeoffs where necessary and appropriate. Good engineers anticipate and understand the logistics of deploying production software. Bad engineers can’t figure out why we don’t just rewrite the entire codebase in a new language today. Bad engineers are inflexible and intolerant of less than ideal circumstances.
Good engineers participate in positive, constructive debate over critical topics, and know when to let an argument go. Good engineers know how to disagree and commit, and help others do the same. Good engineers aren’t afraid of their own failures, and do not hold the failures of others against them. Bad engineers fight to death over tabs versus spaces, shave every yak, and paint every bike shed, sometimes more than once. Bad engineers point out every time they were right.
Good engineers can communicate complex ideas at the appropriate level for the audience. Bad engineers often cannot communicate at all.
Good engineers are good humans. They fundamentally understand that everyone usually has good intentions. Good engineers believe in collaboration over competition as a default mode and aim to hold everyone to a high bar. Good engineers know that good engineers come in many different forms. Bad engineers believe all other engineers went to the same school they did, have the same experience, or are the same gender, color, or sexual orientation as themselves.
Good engineers beget good engineers. Bad engineers believe there are no other good engineers.
Source: LinkedIn
0 comments:
Post a Comment