Good engineers know in great detail what code will be written long before the coding begins. They’ll consider which changes are easily reversed (like static text on a page) and which aren’t (like database migrations). They think about & discuss how the product will evolve so that the hard-to-reverse decisions are great. Every sprint, they know really clearly what the week will look like beyond any extreme exceptions. They believe problems become easier to solve the longer they’re in your head.

Bad engineers figure out along the way what code they’ll write. They start coding and uncover the constraints as they go. The consider coding and researching something done in parallel, not in sequence.

Good engineers sweat some details and are very flexible with others. Good engineers care about the user experience, color scheme, padding, margins, really clear copywriting, and edge cases. They’ll be helped by their PM here but will fill in gaps not explicitly defined. They don’t worry about perfect code commenting, 100% test coverage, or every single possible refactor.

Bad engineers treat all details as equally important. They find a detail they want to update and fix it regardless of the user impact it has. They also believe that MVPs will invariably have user facing bugs and oversights. This isn’t necessarily the case. The very best MVPs will often have little-to-no bugs.

Good engineers actively try to be lazy. They look for shortcuts and ways of not building things. If a product has five features they’ll often push back and try to only ship the three most important ones. They’ll help reduce scope as much as possible. They aim to maximize user value with the least possible effort.

Bad engineers love adding as many features as possible. They consider more buttons, more text, more code, and functionality all signs of great work. All of those are bad things. They’re sometimes a necessary evil but the goal is to maximize user value. The dream product would be a button customers could click that prints money for them. Not currently possible but we can always get closer to that.

Good engineers operate at velocity. By combining great decisions (see 1), great quality (see 2), and minimal work (see 3) - they will build quickly with minimal additional revisions.

Bad engineers operate at speed. They work hard but believe they’re judged on the work they do, not the results they deliver.

Good engineers are accelerated by AI. They use AI to write the vast majority of their code but still have almost 100% understanding of the code they produce. They write detailed instructions for their AIs (including what, why, and how) and review its output carefully.

Bad engineers fall into one of two categories: One kind believes they should minimize their AI usage. They believe they’ll lose some of their skills or AI will be wrong. Both of those will happen but that’s ok. The latter category believes AIs should be replacing them now. They trust AIs output and trust a future AI to be comfortable with any slop that was just added.

Good engineers are super transparent with timelines. They set expectations for how long their work will take, which they can do pretty accurately from having a detailed plan. If things take longer than expected, they’ll notify others.

Bad engineers believe their peers don’t want to be distracted by notification of a delay. Bad engineers believe a delay is their own problem and they must just grind it out until the work is completed.

Good engineers have a low tolerance for being blocked. They’ll first ask an AI, but if stuck for >15mins they’ll share their problem with someone else and work on it together. Following #3 above they know there’s nearly always a perfectly acceptable shortcut they can find with someone else.

Bad engineers think that requesting help (even from a senior) is wasting the senior’s time. They think the senior would rather not be distracted instead of helping unblock the engineer.

Good engineers consider other engineers’ work more important than their own. They stop their own work to review their teammates’ PR. They help unblock their teammate even if they’re in the flow since two productive people will almost always outpace one very productive person.

Bad engineers wait until they’ve finished their work to help their teammates. They’ll be in the flow and wait until that ends to help their teammate.

Good engineers evaluate priorities based on the customer impact. They understand that customer-facing issues/bugs, particularly high impact ones, must be solved as quickly as possible by any means necessary.

Bad engineers value finishing what they’re currently doing the most. They’re often enjoying it, and think the customer issues can be solved when they’re done so that they don’t need to change context.

Good engineers user test thoroughly. They look at the code they wrote to know where to test but consider user testing the ultimate source of truth and do this on all environments.

Bad engineers believe the way to find bugs is by looking at the code. They trust that the code they wrote will work because it passes the tests and they’ve read through it thoroughly.

Good engineers are really pedantic when they review PRs. They use conventional comments to illustrate what comments are critical vs not, and push back on anything they don’t understand.

Bad engineers see PRs as a cursory glance to make sure there aren’t major outstanding issues.

Good engineers proactively highlight areas to improve the code base, the product, and the processes. They often have unmatched visibility on all three areas and so share with their PM & others what can be done to improve. For obvious high urgency work they inform the team and address it instantly. They also take some time to talk to customers, watch product recordings, and develop expertise in the product themselves which helps them be informed during product planning sessions.

Bad engineers consider product feedback beyond their responsibilities. They must focus on following their PM’s instructions as closely as possible and not get distracted.

Good engineers market their work. They make Loom videos and take screenshots to help during all the review stages. They showcase their wins and help build a changelog everyone can see.

Bad engineers believe their sole focus is on building and reporting is a distraction. They assume their colleagues understand the product as well as they do (even colleagues who spend 1% as much time looking at the product). They believe people will see their progress via GitHub - they won’t need to actively promote all they have done.