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.

Good developer/Bad developer

Too Long; Didn't Read

@johnwildoran

RELATED STORIES