While Coaching a Pod Lead on hiring, they asked me a simple question: What makes a good engineer? I’ve always knwn the answer instinctively, but I had never fully articulated it. This is my attempt to do so.
The content is based on Ben Horowitz’s classic: Good Product Manager/Bad Product Manager
Written by Myron Lee
Good engineers know the technology space, the vendors, and the various tradeoffs extremely well and operate from a strong basis of knowledge and confidence. A good engineer is a consolidator of good technical designs and ideas. Good engineers take full responsibility and measure themselves in terms of the flexibility and robustness of their stack. They are responsible for the right solution at the right time and all that entails. A good engineer knows the context going in (the company, the revenue funding, vendors, user experience, etc.), and they take responsibility for devising and executing a winning plan (no excuses) all the way to business outcomes.
Bad engineers have lots of excuses. Not enough resources, not enough direction, their partners are idiots, Google has 100 times as many engineers working on it, I didn’t get the designs fast enough, I don’t have enough time, I don’t get enough direction. Good engineers don’t get all their time sucked up by managing the various organizations that must work together. Instead, they collaborate with them to identify risks and issues impacting their ability to get stuff done. Bad engineers consider themselves at the center of the organization and treat other parts of the organization as gophers for engineering. They feel best about themselves when they figure out how to control all the various influences.
Good engineers apply best practices and tooling to deliver software appropriate for how long they expect to maintain that software. Bad engineers write unproductive software. They over-engineer systems and prepare for scenarios that will never happen including the application of patterns and tooling because everyone else is doing it even if it isn’t a good fit.
Good engineers create leverageable collateral, architectural designs, tradeoff comparisons. Bad engineers put out fires all day and attend meetings that don’t impact their delivery. Good engineers anticipate the technical and product flaws and build real solutions. Good engineers take ownership and do not say “it’s not my job.”
Bad engineers voice their opinion verbally and lament that the “powers that be” won’t let it happen. Once bad engineers fail, they point out that they predicted they would fail. Bad engineers assume someone else will fix it later. They believe that it’s not their job to test and quality control their output.
Good engineers are always learning and understand that technology and software move fast. Bad engineers think programming is just about learning one stack and memorizing patterns rather than understanding the fundamentals. Good engineers ask questions. They know that their teammates and Google are their best resources. Bad engineers don’t want to look dumb and always think their way is the best way and that by asking questions they are admitting weakness.
Good engineers are product-oriented. They understand how their users think and can make good decisions on their behalf. Bad engineers always blame others. They wish that their designs or products were smarter and more like how they would do it. Good engineers define good products as self-contained, intuitive to use, and can be executed with a strong effort. Bad engineers define product delivery by building as specified. Good engineers think in terms of delivering superior value to the marketplace. Bad engineers get confused about the difference between delivering value and delivering the best technical solution. Good engineers decompose problems into small high-quality deliverables. Bad engineers combine all problems into one.
Good engineers understand that the product is bigger than themselves. They consider how others will maintain and extend their work long after they are gone. Bad engineers think code is good enough when it works. Good engineers understand the importance of communication. They seek to understand and be understood. Bad engineers think that others can read their minds. They always complain about how others are changing their requirements.
Good engineers understand the fallibility of the mind. They rely on testing and peer reviews for confidence. Bad engineers think that they have everything figured out and that P=NP. They gain confidence when they don’t encounter issues in the happy case. Good engineers understand that they are part of a team. They help each other and become hive-minded. Bad engineers think they are special. They don’t bother investing in the team and become black holes of tribal knowledge. Good engineers treat mistakes as lessons. They consider what can be learned and implement systems to prevent it in the future. Bad engineers think mistakes are abnormal. They assume they will never happen again and take no ownership.
Good engineers lead by example. They know that they must understand something before they can show others. Bad engineers lead by assumption. They think they know what someone else should be doing without the full picture. Good engineers are disciplined. They understand the value of process and consistency. Bad engineers are unpredictable. They consider all processes to be overhead. Good engineers think outside the box. They understand that sometimes a creatively simple solution is better than a standard complex solution. Bad engineers do things the way they’ve always done it. They don’t consider the scale and complain that they have too much to do. Good engineers define their job and their success. Bad engineers constantly want to be told what to do.
Finally: Good engineers always want to automate themselves out of a job and try to find ways not to do the same thing more than once. Bad engineers feel their value lies in their ability to do complex work well. Good engineers understand the importance of administrative tasks. Bad engineers do every non-engineering task late and with poor quality because they don’t have discipline.
