I’m guessing you’re a fan too.

If you’re reading this, it’s probably because you already know the benefits of adopting TDD in your team’s workflow. But you’re probably stumped (as I was) by the fact that while everyone seems to agree that adopting TDD is a good idea, very few developers do it consistently.

It’s not that they don’t want to… it’s something else. Let me explain.

As I was going through a TDD workshop for one of my clients, a friendly and enthusiastic junior developer starts asking a ton of questions.

It’s rare that someone shows that much interest in these workshops, so I am happy to answer all of his questions, and I ask him to schedule a pairing session, so we can dive deeper into the topic.

He agrees and thanks me for my willingness to help.

A few days go by, and I check my calendar, only to realize that he didn’t schedule the meeting.

So, I page him on Slack to remind him about our discussion. He apologizes and sais that because of some urgent tasks he had to postpone our meeting.

The same thing repeats one more time, and so I decide to give up until whenever he feels ready.

Time flies, and one day, I get a message on Slack from him telling me he needs some help with TDD.

So, we jump on a call later that day.

The meeting goes well. He seems enthusiastic again, just like before. But this time, he schedules another session, and then another, and I can see his excitement is through the roof.

But I’m puzzled. I want to know what changed. Why the sudden burst of interest. So, I ask him what was it that made him decide to schedule our sessions.

He said: “I joined a new project, and we need to do TDD.”

So then it hit me.

We’re all busy bees here. We’ve all got tasks to do. We all need to prioritize.

And if you have to cut, where do you cut from? Obviously, from the optional half of your to-do list.

Makes sense.

What to do?

Ask yourself these three questions:

• Do you believe that TDD will improve the quality of your codebase?
• Do you honestly want your team members to get better?
• Do you want them to stick around longer?

If your answer is yes, then you owe it to the team to push them a just little harder because that’s where the magic happens.

If growth is a priority, growth happens.

TDD is all about the mindset shift, and most developers are not comfortable with that, especially since the benefits are well hidden.

But if you want to see your team adopt it, then make it a priority. Don’t be afraid to challenge your team. Sprinkle a few tasks that junior developers find impossible, and watch them reach out for help.

Conclusion

Comfort Zones Are Where Dreams Go To Die. ― Regina King

I love that quote. It describes the entire career of a software engineer in just a few words.

We’re in a profession that keeps evolving faster than anyone could keep up. So to be on top of it, you have to get comfortable being uncomfortable.

The alternative is to let yourself (and your team) get comfortable. It’s a choice every one of us needs to make at some point. And now it’s your turn.

If you decide to push your team harder, they might get scared at first and feel uncomfortable a lot. But eventually, they will thank you for helping them grow.