Good engineers are value creation machines. They take responsibility for the outcome of a project. They see the situation holistically, rather than in silos. They speak up when they are stuck. They use maxims for guidance, whose meanings are contextual, not dogmatic. They view product quality as everyone’s responsibility, not just QAs. They do not shy away from making mistakes. They think for themselves. When they do have questions, they have specific questions for specific people.

Bad engineers punt problems to someone else. They always seem to find the shortest path to being stuck. To a bad engineer, product quality is the responsibility of the QA team. Bad engineers practice ‘CYAE’, ‘Cover your Ass Engineering’. They blame end-users for bugs in their code. Bad engineers focus on the letter, not the spirit, of the task they’ve been assigned. They make complaints without also suggesting a least one solution. They have lots of excuses.

Good engineers are proactive communicators. They seek out constructive criticism of their designs. They understand the non-technical areas of how they are perceived and have self-awareness when it comes to their communication. They are both empathetic and assertive, not passive or aggressive in how they get their ideas across. They thrive in an open, collaborative environment.

Bad engineers hide their mistakes. They believe they are the smartest person in the room because they are a great coder. They can come off as condescending, belittling, or narcissistic. They are a lone-horse, delivering code in a vacuum.

Good engineers are always shipping product. They have an irrepressible addiction to solving problems. They understand that shipping product means delivering value in the short term, while building a stable, performance, secure, architecture for the long term. They anticipate product flaws and build real solutions.

Bad engineers are putting out fires all day. They cannot overcome obstacles in the implementation of their features. They do not seek to understand the constraints that they are working within, and therefore under-architect or over-architect solutions. They add scope that is not what the product team wanted. When bad engineers fail, they point out that they predicted they would fail.

Good engineers understand that not all of their projects are filled with the most interesting technical problems. However menial or trivial their assignments may appear, they give their best effort. They do the hard thing. They have a pleasant demeanor because they understand that getting things done doesn’t always mean only doing things you are most interested in.

Bad Engineers push back on work that they view as beneath them. They are slow to turn around work that does not stimulate their own personal tastes. They sow their discontent about their assignments to their teammates.

Good engineers are mindful of their strengths and weaknesses. They are aware of their cognitive biases. They develop strong relationships with those who have complementary skills to their own. They accept and trust the product team’s vision and ability to understand the market, product, and competition. Good engineers are always learning. They lift the skills and expertise of those around them. They push the boundaries of their comfort zone and their knowledge. They leverage patterns and architectural work of others, and they reach out when they need coaching or mentorship.

Bad Engineers assert themselves outside of areas of their areas of expertise. Bad Engineers do not back down. When confronted with contradictory evidence, they will muddy the waters, defer responsibility, and request endless justification from others. Bad engineers are intellectually stagnant. They coast. They wait for someone else to come in and tell them what they need to learn.

———————————————————————————————————————————————-

Inspired by
[1] Good Product Manager Bad Product Manager
[2] On Being a Senior Engineer
[3] Simple Energy Team Values (we’re hiring)