Good Developer / Bad Developer

Problem

Inspired by Marty Cagan's article Good Product Team/Bad Product Team, here are the behaviours and traits we look out for at my company while hiring and coaching software engineers.

Actions taken

• A good developer tries to understand their users, is involved in feature design, and spec from conception (if possible). A bad developer feels that anything that is not coding is a waste of time.
• A good developer is able to instrument, tune, and measure performance. A bad developer doesn't know what those things are.
• A good developer is obsessed with learning new things, improving processes and voicing concerns. A bad developer is resistant to change.
• A good developer can give accurate estimates and timelines on work and be diligent with status updates. A bad developer makes you chase them up constantly.
• A good developer always puts the team and organisation before themselves. A bad developer only cares about delivering their own work.
• A good developer knows how to break down complex functionality into small deliverable pieces. A bad developer gets bogged down in problems and no progress can be seen "until it's all done".
• A good developer understands their work only has value once it reaches production and satisfies customers' needs. A bad developer painstakingly agonises about writing code which is only ever works on their machine.
• A good developer will always look to write the minimum amount of code possible to solve a problem. A bad developer believes their worth is related to the amount of code they write.
• A good developer follows the boy scout rule, always leaving things cleaner than they found it. They are never happy when looking at past work and is always wanting to refactor. A bad developer duplicates code, writes complex methods, ignores terrible code when they see it, and never reviews previous work (unless to copy paste it).
• A good developer always checks if a problem has been solved before they tackle it. A bad developer re-implements logic that already exists and never discusses implementation approaches with teammates.
• Good developers understand the value of code reviews and pair programming. Bad developers get offended when someone critiques their work.

Lessons learned

Have a really great hiring process so you can find the good developers and don't be afraid to fire bad ones :) Source: https://hackernoon.com/good-developer-bad-developer-e65a1bba1838