Inspired by Marty Cagan’s [good product team/bad product team article](https://svpg.com/good-product-team-bad-product-team/) here are the behaviours and traits we look out for while hiring and coaching software engineers. * A good [developer](https://hackernoon.com/tagged/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](https://hackernoon.com/tagged/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 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. ### Closing thoughts Do some of these bad things sound familiar? If there is anything missing, I’d love to hear your feedback. Reply below if you have any ideas. Thanks to [Paul Dailly](https://medium.com/@paul_dailly) and [Ronan Perceval](https://medium.com/@ronanperceval) for their help with this post.