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.\n\n* 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.\n* A good developer is able to instrument, tune and measure performance. A bad developer doesn’t know what those things are.\n* 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.\n* 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.\n* A good developer always puts the team and organisation before themselves. A bad developer only cares about delivering their own work.\n* 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”.\n* 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.\n* 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.\n* 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).\n* 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.\n* Good developers understand the value of code reviews and pair programming. Bad developers get offended when someone critiques their work.\n\n### Closing thoughts\n\nDo 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.\n\nThanks to [Paul Dailly](https://medium.com/@paul_dailly) and [Ronan Perceval](https://medium.com/@ronanperceval) for their help with this post.