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
