Good Engineer/Bad Engineer

This format and content is based on Ben Horowitz’s classic “Good Product Manager/Bad Product Manager” and the many inspired pieces that came after it. This is a very effective format for communicating expectations in the same way that positive and negative samples are effective in machine learning training sets. By providing both you allow the learner to infer a boundary that would otherwise be difficult to describe. Note that at different stages and types of companies what an ideal engineer looks like will differ, this is written specifically for Stably on October 2020.

Good engineers know how to get stuff done. They apply best practices and tooling to deliver software appropriate for how long they expect to maintain that software.

Bad engineers write code to feel productive. They over engineer systems and prepare for scenarios that will never happen. They apply patterns and use tooling because everyone else is doing even if it isn’t a good fit.

Good engineers are always learning. They understand that technology and software move fast and so they get good at picking things up quickly.

Bad engineers think programming is just about learning one stack. They learn the syntax and memorize patterns rather than understanding fundamentals.

Good engineers ask questions. They know that their teammates and Google are their best friends.

Bad engineers don’t want to look dumb. They always think their way is the best way and that by asking questions they are admitting weakness.

Good engineers take ownership. They know that good software is built over time by those who thought of others while writing their code. A good engineer does not say “it’s not my job.”

Bad engineers assume someone else will fix it later. They believe that it’s not their job to test and quality control their output, it’s “management’s job.”

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. They believe that anyone who can’t read their code must not be as good as them.

Good engineers are product oriented. They understand how their users think and can make good decisions on their behalf.

Bad engineers always blame the user. They wish that their users were smarter and more like them.

Good engineers understand the importance of communication. They seek to understand and be understood.

Bad engineers think that others can read their mind. They always complain about how others are changing their requirements.

Good engineers understand that they are part of a team. They help each other and become a hive mind.

Bad engineers think they are special. They don’t bother investing in the team and become black holes of tribal knowledge.

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 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 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 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 are disciplined. They understand the value of process and consistency.

Bad engineers are unpredictable. They consider all processes to be overhead.

David Zhang

Co-founder & Aspiring Good Engineer

Stably