Inspired by Ben Horowitz's "Good product manager/Bad product manager" definition, this guide outlines behaviours that we expect from good engineers at Releaseworks.
A good engineer is often the smartest person in the room. A bad engineer thinks they are the smartest person in every room.
A good engineer takes time to keep tickets up to date and ensures that the board reflects true progress. A bad engineer only updates tickets when asked.
A good engineer follows a peer review process. A bad engineer thinks nobody can review their code.
When working with an existing codebase, a good engineer aligns their code to its documented conventions and standards, or if none exist, the conventions that are evident in the codebase. A bad engineer writes code with their own conventions because they want to stand out.
A good engineer sets realistic expectations on effort estimates. A bad engineer tends to underestimate effort, leading to slipping deadlines and difficult conversations.
A good engineer has enough commercial acumen to understand the impact of their work, and to spot risks and opportunities. A bad engineer is unaware of the value they are expected to create.
A good engineer shows up on time, every time. A bad engineer consistently shows up 1-3 minutes late to calls or meetings, because they don’t value others’ time.
A good engineer lives by their diary, ensuring that their colleagues have real-time visibility into their availability and commitments. A bad engineer ignores their diary.
A bad engineer makes late excuses on environmental factors (power, internet, trains) when they can’t meet a commitment. A good engineer sets expectations early.
A good engineer would rather stand for an hour outside a customer’s office waiting for the meeting time than be 5 minutes late.
A good engineer proactively shares knowledge. A bad engineer keeps solutions to themselves.
A good engineer poses a technical question to their manager as "Based on my research, I think the best way to solve X is Y. Is this correct?". A bad engineer asks their manager "I don’t know how to do X. Can you do it for me?"
When faced with an unknown problem, a good engineer actively searches for a number of different solutions and then does practical experiments to apply the potential solutions to their problem. If none of them work, they ask their manager for direction, clearly outlining all the solutions they have already tried. A bad engineer asks their manager for the solution.
A good engineer knows when and how to ask for direction from their peers and their manager. A bad engineer gets stuck trying to solve too big a problem on their own.
A good engineer actively reduces ambiguity in conversations, systems, and documentation. A bad engineer uses complicated language because they want to sound smart.
When someone asks a good engineer a difficult question, they answer "I don’t know, but let me think about it and get back to you". A bad engineer answers "I don’t know".
A good engineer talks about best practices, and finding the right solution for the current problem. A bad engineer talks about their solution as the only solution.