Last time, I talked about how to prepare for a tough conversation with a coworker about having bad code.  This included understanding what not to say and creating a game plan of specific shortcomings to address and concrete outcomes you want from the conversation.  This time, I’m going to talk about how to actually engage with your teammate, “Bob.”

It’s Not If You're Going to Say Something, but How

Having built your case ahead of time, it’s time to go have a chat with Bob. You’re calm, you’re rational, you have a legitimate argument, and you’re all set for a constructive dialog…but the lead in for the conversation threatens to be awkward. What I’d suggest doing to put the conversation in more natural terms is to ask for his help. “Hey Bob, I’m chasing a defect through the code and it led me to this method of yours. It’s a little hard to follow at first glance, so I was hoping maybe we could trace through it together?” Now you’re not coming over to preach to Bob about the evils of his code but rather to ask him to help you solve a problem.

Once you’re looking together at a screen and starting to dig in, one of the most effective ways I’ve found to surface code problems is through the Socratic Method. Instead of telling Bob that the method is too long, ask a series of questions. “Wow, good thing you’re here—this is a pretty long method with a lot going on. How long do you think it would take the average team member to understand it?” “Huh, wow, three or four hours seems like a pretty long time to spend trying to understand a method, don’t you think?” “What if it were smaller?”

Now, this is where it starts to get a bit trickier. Making proclamations of fact or strongly stating opinions tends to put people in a defensive posture. Asking questions, even leading ones, doesn’t get people’s hackles up as much. They tend to join you in problem-solving mode rather than argue against you in debate mode. Still, asking questions this way may not lead to the desired outcome, which is why you’ve done your homework. Switch gears from the questions to statements of your experience and how you feel. These are inarguable.

“I get that you think breaking up the method would just distribute the complexity, but I spent hours trying to understand this. I don’t have the same problems in Alice’s code where she uses lots of small methods.” There’s nothing Bob can say, so far, to argue with this, so it’s a good premise for a call to action. “You can find a lot of literature and studies out there about small methods correlating with fewer bugs, and I know I’m not the only one on the team that prefers to read and write code that’s more compact. What do you think? Can we try pairing up and refactoring this a bit? It might help reduce the defect count originating from features that you’ve implemented.”

That last line is the critical last piece to the engagement puzzle. Bob probably can’t argue with your well-researched position, and he certainly can’t argue with how you feel, but he could still balk at changing his approach. You need to focus on how the new approach benefits not only others or the codebase in general but also specifically Bob himself. No one wants to write bad code and suffer the consequences, so help them understand that life can be better.

Maintaining the Constructive Relationship

As I’ve said, you’re not going to take someone that writes bad code and turn the whole ship around in a sitting. The first engagement is about establishing a relationship along these lines and setting the stage for more talks. To do that, you have to be prepared and patient, willing to nudge gently but firmly, and opportunistic in looking for a line of reasoning that strikes a chord. If you can show Bob the difference and convince him of the benefits of adopting a new approach, future collaborative improvement sessions will start to happen naturally. Often times, they’ll happen with Bob being eager to learn. I’ve personally been in a lot of groups where building trust in this fashion has led to unsolicited requests to review others’ code and offer feedback. If that happens, you’re in an excellent place.

Over the course of time you and Bob can work together on a broader strategy of code improvement.  Even if he’s receptive and eager in the initial conversation, this kind of ongoing maintenance will be required for going from “Bob writes poor code” to “Bob writes clean code.”  This will require cataloging the differences between good code and bad code, keeping track of them, and working strategically with Bob one one or two of them at a time to help him get better.  As he practices the easier ones, you can gradually introduce more and more to gently push him out of his comfort zone, toward cleaner code.

So, in the End, How Do You Tell Bob That His Code Sucks?

Over a beer, a year or two later, when marveling at how far he’s come: “I didn’t want to discourage you back then, but your code really sucked. You’ve come a long way. Good job.”

This is Part 2 of our series on Poor Coding in the Work Environment. To Read Part One, Click Here.

If your development team’s code isn’t up to par lately try out Collaborator, a Peer Code Review Tool From SmartBear.