Good developer/Bad developer

Originally published by John Doran on April 7th 2018 3,412 reads

@johnwildoranJohn Doran

Director of Engineering

Inspired by Marty Cagan’s good product team/bad product team article here are the behaviours and traits we look out for while hiring and coaching software engineers.

• 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 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 and Ronan Perceval for their help with this post.