Why should you practice TDD?

In 2014, J. B. Rainsberger wrote, “I started practicing test-driven development because I saw that my job was draining my energy and taking up too much time.” Should you practice TDD for the same reason?

Does TDD require less energy than manual testing and debugging?

How can TDD require less energy if you are supposed to make more effort? You not only have to write the code, but you also need the tests. You need the tests before you write the code, so you have to know what you will write before writing it. Those are three actions instead of one! It looks like more effort, but it isn’t.

When you practice TDD, you put all your effort into thinking of the next step required to implement the code change. The tests are a consequence of your thinking. Tests require no mental effort when you already know what you expect. After writing the test, you implement the code. Does this require any mental effort? Not really. A proper test diminishes the required effort because you have an external mechanism checking your code. You don’t need to wonder, “Will it work?” You can check it. After implementing code comes refactoring. Does this require lots of effort? A little bit, but not much. Why? Because you can do all the refactoring in small steps while automatically checking whether your code still works.

What’s the alternative? Manual testing, debugging, and adding useless tests at the end to have “code coverage.” Does it require more energy? We don’t know. It’s unpredictable. You may have all the skills and luck needed to get the code right on the first attempt. If you don’t, you may spend a week fiddling and debugging the code.

Is TDD predictable? No. But it’s more predictable than the write first, test later approach. In TDD, you may spend 30 seconds thinking of your next step, or you may need an entire day. Sometimes it feels like the existing code fights back against any attempt to do TDD. When you work in such a codebase, you will need more time to plan your next steps. Steps! Even though you tackle the problem one step at a time, having a general idea of where you are going does pay off.

Does TDD make you faster?

In a messy code, the write first, test later people will start coding sooner than a TDD-er. It happens because they are thinking of the solution while they are coding. A TDD-er does most of the thinking before they start typing. The write first, test later programmers may occasionally get lucky and finish the task quickly. But TDD gives you a consistent pace. Your process doesn’t depend on luck. You make stable progress.

However, in the beginning, TDD is painful and slow. It’s ok. It’s normal. You are doing something new. Do you have a driving license? If yes, recall the first driving lesson you had. Were you driving with confidence at the maximal allowed speed? Perhaps, a handful of people did. Although, the majority was freaking out and trying not to crash into something.

Test-driven development requires practice. You won’t learn TDD in a week or even a month. You will need months of effort every working day. It seems to be a huge sacrifice, but it’s an investment. Once you learn it, you will get the benefits of the process every day for the rest of your career.

Why should you care about spending less time and having more energy?

Why should you care? You have an employment agreement stating you get paid X for Y working hours. You get the money no matter what. You must show up and make a minimal effort to avoid looking like a slacker. Nothing else is required. Really. Often, people who struggle to get the code right look like someone who works hard, not someone who is incompetent. Why would you like to get the job done faster? It benefits your employer but doesn’t benefit you. Right?

That’s only one point of view on the situation. When you agree to trade Y hours for X money, you are supposed to spend those Y hours on something that benefits your employer. But nobody forbids you to spend time on something beneficial for your employer and you!

What should you do? Do something to improve your chances of getting promoted or getting a better job in the future. It’s ok as long as you improve the situation at your current company too! What may you choose?

You can learn another programming language or a new framework. Picking another programming language is the easiest choice for a programmer. But would it make a difference? I can write production backend code in Java, Scala, and Python. I know a little bit of JavaScript and React. Does it make sense to learn Rust or Go? I don’t think so. If I knew only one language, then I would learn another one. The benefits of learning yet another programming language diminish fast. I see no difference between a programmer who knows 3 or 8 languages. The person who knows three may be a better programmer if they spend time learning the details of the standard library in those languages.

If not a programming language, then what? If I didn’t know how to train machine learning models, I would learn ML. What’s next? If I didn’t know how to make an ugly front-end, I would learn a front-end framework. Do I want to learn how to implement a beautiful front-end? No. I have no interest in learning design right now.

It’s not only about programming languages. It’s the same story with frameworks and libraries. How many Java dependency injection frameworks do you need to know? One or two. It makes no sense to learn how to use seven of them. What about machine learning? I know how to use Tensorflow with Keras. Will I learn Pytorch? No. It won’t give me any benefits.

If you are a Java backend developer who knows the Spring framework, pick something that makes you more than a Java backend developer who knows Spring. You have two options: backend and something or backend specializing in something. To get the best results, you should alternate. One time you specialize. The other time, you learn something completely new.

Right now, I decided to learn marketing. It will be handy when I have to promote myself and my work. Also, I will need marketing if I ever create my software product. After all, most software startups die because everyone wants to write code, and nobody does marketing. How does it benefit my current employer? I hope to learn how we can promote my team’s work better within the company. Usually, data teams are overlooked because we are “the backend of a backend.” With the right marketing skills, we should be able to get more attention.

Why should you promote your work? Because programming is business (even when you are employed). In business, you don’t get participation trophies. No matter where you are in the hierarchy, a higher level has a limited number of seats. Tenure alone can get you to the senior level. If you want anything more, you will need to be seen and positively perceived by those higher in the hierarchy.

What will the other team members think about it?

If you are on the right team, they will be happy. They are already doing it too.

On the other hand, you may be on a team that opposes everyone who tries to become more than average. What does it look like? It may be a casual comment. A few years ago, I participated in a conversation about video games when I mentioned I was going to buy a gaming console. One person said, “Finally, you will stop blogging.” Apparently, my blog bugged them. Did I stop blogging? No.

Don’t waste your time thinking of people who oppose your growth. They don’t matter.