Your Code Sucks!!

….is usually not an approach that works.  However, how do you start the conversation when there is an issue with somebody’s code (or work performance) that needs to be addressed that still preserves the relationship?

Earlier this week in the Certified ScrumMasters LinkedIn group, one member asked “How do you motivate a Team member to improve their technical skills?”  In the scenario, the OP had identified some clear deficiencies in the Team member’s code – long methods, too many if\else statements, difficult to mock, big unit tests, etc.  Yet, the Team member did not see the same issues because in the Team members’s mind since “it works” it is naturally good code.

The first place to start is the Perfection Game.  The Perfection Game is simply the most powerful tool out there to give direct, candid feedback while preserving the relationship and helping the person listen to what is being said.  “Your code sucks!” shuts down the entire dialogue while the Perfection Game keeps the lines of communication open.

For instance, if I were to look at this code, (using the Perfection Game) I might say: “On a scale of one to ten, ten being perfect, I give this a five.  I like that it works properly, that we have automated unit tests and that you came to me for feedback.  These are all good things about this code.  What could be more perfect is that the main methods in this class are too long.  My expectation is that we don’t have methods longer than twenty lines.  Next, I would use an Extract Method refactoring to pull out all these if\else statements and see if we can remove some of the duplication.  I think you’ll get the most bang for your buck by pulling these blocks into their own methods.  Finally, more perfect would be to simplify these tests and remove some of the data dependencies.  I’m not sure how to do that right now, but I can sit down with you and we can figure it out together.  If you made those changes, this code would be perfect.”

Since this is a dialogue about code, I would offer to pair program with the person to show them what I mean (because clearly in this situation the programmer does not know what good code looks like).  Pair programming is the second most powerful tool for this situation since pair programming is about showing people what quality code looks like.  Telling is not working, so the best way to convince other programmers about the quality of an idea is to write code.  IME, nothing else works better than looking at code.

Pair programming is less about teaching and more about helping Team members understand the thought process behind Simple Design and what good code looks like.  It is NOT about writing the code, but teaching how to think about code.  So much of the time in the pair programming sessions will be spent thinking out loud as you write the code.  If you do not talk about the thought process, then you missed the teaching opportunity.  IMO, when there are issues with code quality in a Team, it is the responsibility of the technical leads and senior developers to pair program with Team members who are struggling.

Finally, the last step is buy Refactoring by Martin Fowler.  I cannot overemphasize how important this book is for the professional programmer.  By reading this book and using the refactoring techniques, you will be in the top 30% of all programmers globally.  If people will not read this book on their own, than tech leads and senior developers need to schedule sessions to review the key sections with the Team members.  By understanding the patterns in this book, it becomes so easy to spot dirty code.  Without the patterns (and a language to talk about them), it is nearly impossible to improve code quality.