Coding Dojo Troubleshooting
In my last 2 blog posts, I’ve detailed why and how to start a team Randori Coding Dojo. That’s the easy part. As soon as you start your first dojo, you’ll face trickier issues, especially people issues.
What if my team (or my boss) does not want to ?
Very often some of your team mates won’t see the value of the coding dojo upfront and will prefer to work on other tasks. It can also be your boss, who thinks you should be delivering features instead. Here are a few tricks you can do to make it work.
- Try to find another time slot. Ask people for their preferred moment. If you can negotiate food sponsorship with your boss, you might get everyone happy. He won’t feel you’re not delivering features, you’ll have a free lunch and you’ll improve your skills.
- If your boss or colleague doesn’t want to spend 2 full hours on a dojo. Get them to start with smaller problems and a shorter time slot.
- Your colleagues might have doubts about the value of the dojo. Get them to try it once or a few times before committing to a recurring event.
- As a general rule of thumb, the more you manage to involve people in the preparation, the more they’ll adhere.
- If you have 1 or 2 inveterate laggards, do it without them anyway. With time, they’ll understand what they are missing !
💡 If you cannot get people to adopt a new practice, get them to try it once. You’ll be more than halfway there.
Dealing with TDD complaints
As you’ll start your first Randori, you’ll have some complaints about Test Driven Development. Whether they come from newbies or skeptics, they usually look like :
- Why do we stick to TDD ? We’d go so much faster if we coded this straight away.
- We don’t need TDD for such a simple problem.
- We don’t need such small baby steps on this simple problem.
- …
My answer is more or less always the same. I try to re-frame everyone in the context of a learning exercice of deliberate practice. It could sound something like :
Yes, sure. I know you are professional developers and that you could easily solve this little problem. Keep in mind that we are here to deliberately practice TDD and friends. Solving the problem is only a side effect.
We are going to apply TDD by the book, for the sake of learning. It’s a lot easier to learn to swim in 1 meter of water than in the middle of the sea. Once we’ll master it in the safe dojo environment, you’ll know how to adapt it to your production code.
Please, play by the rules here !
As you can see, I don’t try to convince them. The last thing I want is to get into a pro vs cons of TDD. 95% of the time, this answer is enough to get people over their skepticism and try it for the time of the dojo. Unfortunately, the last 5% might result in a difficult session. There’s no single way to deal with these 5%. You can try to discuss with them in private, or run next session without them.
💡 Reframe the coding dojo as a learning exercice relying on TDD to go beyond skepticism.
How to avoid getting bogged down in details
One last advice, especially for your first sessions. It’s a common rookie mistake to waste 80% of the coding time on error handling. The key is to focus on what you want to learn. You are not writing production code, so don’t hesitate to omit certain aspects. For example, assume that correct arguments are provided to skip error handling. This will save you time, be more fun and increase what you learn.
What’s next ?
This was part 3 of this series on team coding dojo. In the next post, I’ll write how to maximize the benefits we can get out of coding dojos.
Leave a comment