I was inspired to write this article by Ben Horowitz’s Good Product Manager, Bad Product Manager.
First – let me say that I don’t believe everything is as clear-cut as good or bad. But my intention here is to delineate good versus bad behaviours in a general sense. I think of it as a bit of a code for me to aspire to live by.
A bad developer sees a problem, and immediately sets out to write code that fixes it.
A good developer sees a problem, and immediately sets out to investigate ways it could be solved without code.
A bad developer writes unique code from scratch to solve a problem.
A good developer reuses existing code to build a solution that’s better tested.
A bad developer functionally tests their code to ensure the happy path works.
A good developer writes automated tests to test every conceivable scenario their code could encounter.
A great developer writes these tests first.
A bad developer writes unit tests for every conceivable scenario every time without regard for the deadline.
A good developer knows how to approach writing tests strategically to get the most value from them.
A bad developer believes their favourite language is the one true language and all other languages are inferior.
A good developer knows the power of mastering one language, and the flexibility of understanding others.
A bad developer writes long complex methods with many layers of nesting.
A good developer breaks the functionality into many small methods with descriptive names.
A bad developer builds exactly what they’re asked for.
A good developer puts themselves in the shoes of the user and builds the best solution to the problem.
A bad developer writes lots of code but no documentation.
A good developer writes instructions that their future selves are thankful for, and annotates complex code where necessary.
A great developer writes code that needs no comments, and habitually writes articles and guides to document their learning.
A bad developer works for days in a branch before opening a pull request.
A good developer integrates their branch to the trunk at least once a day.
A bad developer reads their peers’ pull requests and approves them if there’s nothing obviously bad.
A good developer mentally executes the code as they read and predicts the outcome; referring to documentation where they lack understanding and using the review as an opportunity to learn. They suggest meaningful improvements and refactors, no matter how trivial, with the goal of improving the overall product and standard of code.
A bad developer opens huge pull requests that take a long time to review, and potentially many rounds of feedback. Sometimes bad code slips through because it’s too overwhelming to review properly.
A good developer opens small, regular pull requests and layers up the functionality in Bitesize chunks that are reviewed quickly and regularly.
A bad developer names things for convenience and expediency at the time.
A good developer names things for convention and clarity in the future.
A bad developer applies what they’ve learned to their work going forward.
A good developer uses what they’ve learned to improve code they’ve written in the past.
A bad developer feels like they’re wasting time in team meetings.
A good developer seizes the opportunity to learn, share and grow with their colleagues.
A bad developer wants to bask in the glory of heroically delivering the impossible at the last minute while their teammates are floundering.
A good developer wants to bask in the warmth of collective success when they pull together and deliver at a steady, sustainable pace.
A bad developer tackles the interesting problems first.
A good developer tackles the important problems first.
A bad developer writes the code until it works and then checks it in.
A good developer writes the code until it works and then works to improve it before checking it in.
A bad developer copies and pastes examples into their code to make it work.
A good developer writes the examples into their code by hand to ensure they understand how each piece of the code works in order to solve the problem and learn something new.
A bad developer installs dependency packages that look like they’ll help solve the problem.
A good developer installs dependency packages that are well maintained and battle tested to solve the problem.
A bad developer has little patience for those with less experience or technical knowledge than themselves.
A good developer remembers the journey and does what they can to help others on their own journey.
A bad developer doesn’t know they are a bad developer.
A good developer knows that everyone is a bad developer until they make a conscious effort to be better.