You’ve made it to the end of the first part of this course. Great work!

Let’s take a quick look back at what you’ve achieved so far:

• You’ve seen TDD as a practical approach to increasing your capacity to deliver features.
• You’ve started using powerful microtechniques from Getting Things Done to organize your programming work so that you feel more confident and more resilient.
• You’ve practised test-first programming on a problem that didn’t require many design decisions, so that you could focus on implementing correct behavior.
• You’ve practised committing your code frequently so that you can safely go back to the last time everything worked whenever you become confused.
• You’ve seen how common high-level design patterns, like Model-View-Controller, can evolve by applying the Simple Design Dynamo, so you can focus on the details for now and you’ll notice the high-level organizational patterns when you’re ready.
• You’ve learned about the power of removing duplication and improving names. You’ve even seen some ideas about how to improve names.

There’s more, but that’s pretty good so far, don’t you think?

So… Are You Ready To Continue?

If you’ve already purchased this course, then the rest of it is ready, waiting for whenever you have the time and energy to continue. Maybe that’s now! Maybe not. No worries. It’s ready when you are.

But if you haven’t already purchased this course, then you can take a look at the free previews to get an idea what’s left for you to learn. Here’s a quick summary:

• If you let clusters of modules become too tightly coupled to each other, then you start to notice design problems in your tests. (Which ones?) Series 3 walks you through an example, shows you the risks, and suggests how to confidently address those risks. If you’ve heard people complain that TDD leads to tight coupling, this series shows you what they’re reacting to and what’s really going on.
• Once you’ve understood the patterns that highlight tight coupling between modules, you can use Client-first design with Test Doubles (also known as “mock objects”—don’t panic) to avoid a lot of these problems in the first place. Series 4 walks you through an example of the technique, so that you can start applying it in your systems right away. Yes, you’ll probably make a mess in the short term, but remember: a mess in the tests only alerts you to a bigger mess in the production code.
• Once you have a trusted technique for avoiding and rescuing tight coupling between modules, you can turn that technique on expensive, external resources. Series 5 walks you through two realistic examples of connecting to things that run outside of your immediate control. In one case, you will avoid depending on a network device using interfaces and test doubles, and in the other case, you will avoid depending on a keyboard device mostly by inverting the dependency. Mock objects works great (in spite of what some angry programmers claim), but don’t make them the only tool in your toolbelt: the best way to block a kick is not to be there!
• Finally, as an added bonus, you’ll see an example of the equivalence between an typical object-oriented design pattern and a typical functional programming design pattern. You’ll find it very liberating to know that you don’t have to worry about choosing one approach or the other when you can safely and simply refactor back and forth between the two approaches. If you have options, then you can defer commitment until you know better what to do.

By the end of this course, you’ll confidently and safely write new code as well as improve existing code. It might feel slow at first. Don’t worry. I went just as slowly when I started as you are going right now. If you keep at it, your learning will follow an exponential growth curve. (But not forever! We’re not trying to eat the planet.) Exponential growth curves have two important properties:

1. You can’t tell where you are along the curve, because its growth looks the same from everywhere. (That’s the “bad news”.)
2. When it kicks in, it really kicks in, even if you don’t really feel it. (That’s the “better news”.)

After a few months of diligent practice and asking questions, one day at work I looked up from the end of a task and realized that I had nothing left to do and I felt confident about the correctness of my code and I felt safe about what would happen when I needed to change it. Suddenly everything felt different and it felt like the change happened while I was busy focusing on doing the little things well. I hate to say that it felt like magic, but it kinda did!

I am not promising any magic. But if you continue this course, practise the techniques, and focus on doing the little things well, then I feel very confident that you’ll look up one day at work from the end of a task and realize that everyone else is rushing to finish and you feel calm, confident, and safe.

And who doesn’t want that?!

Here is the experience of one participant who has found this course transformative.

Please note! I do not guarantee any particular improvement in "velocity" or any other measurement of productivity. I do, however, virtually guarantee a reduction in time wasted fixing mistakes, a reduction in time wasted building what you don't need, and a reduction in time wasted trying to maintain a code base that is constantly in danger of falling apart. It would shock me if those outcomes didn't correlate highly with delivering more value sooner, even though you might need several months to a year for those benefits to pay back your investment in learning.