Good Developer / Bad Developer

John Doran

Director of Engineering at Phorest Salon Software



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

Be notified about next articles from John Doran

John Doran

Director of Engineering at Phorest Salon Software

Performance MetricsSoftware Development

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up