This document is heavily influenced by a similar document Ben Horrowitz wrote many years ago for product managers and that was also printed in his book "The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers" as well as on a modified version that was co-authored by David Weiden
The original article was recently discussed on Hacker News. Someone mentioned a version for engineers and I immediately wanted to write my own version.
Right now it's only a list, but I might expand on some of these points if more clarity is needed.
- Good developers understand the code they are writing and its implications
- Bad developers cargo cult other people's code without understanding the reasoning behind the patterns used
- Very bad developers copy code without understanding how it works
- Good developers understand that writing code is chosing between trade offs and know there is no perfect code. The main trade offs are between the following axis
- Runtime Performance
- Time spent writing the system
- Maintainability
- Readability
- Extensibility
- Bad developers are not able to see the trade offs
- Bad developers might see the trade offs but do not assess which one is the right one given the context the code is written in and will live in
- Bad developers write code that's too clever, not targeting one of the important quality axis, but making themselves feel smart
- Good developers keep learning about new technologies and methodologies
- Bad developers settle for what they know
- Very bad developers fight new things they don't understand because they don't want to change/learn
- Good developers are careful when choosing new technologies and make sure that the major trade offs are known before using new technology on any critical project
- Bad developers believe a new technology is a silver bullet
- Bad developers use new technology on critical projects before they understand the trade offs represented by the technology
- Good developers ask for help
- When they are stuck
- When a design decision will have long term consequences and more smart people should weigh in
- Bad developers waste time being stuck when others could have helped them
- Bad developers unilaterally make long term design decisions that they aren't sure about
- Good developers are eager to share their knowledge
- Bad developers are interested in looking smarter than other people on their team
- Great developers can explain different solutions the team might want to consider to product managers and designers
- Bad developers get frustrated with product managers and designers
- Great developers provide tooling to make the entire team more productive
- Good developers can give a rough estimate how long an effort will take and know when they can't give an estimate
- Bad developers keep promising they will be done "soon"
- Great developers work with product on setting and achieving realistic targets
- Bad developers know targets set by the business are unrealistic, but remain quiet an let the train hit the wall