Setup
A few things have aligned recently: I left a job without yet having started in anything new (I have a couple of possible opportunities, but happy to hear about other opportunities), which gave me some free time; I had a really good TDD session recently with the Rust study group that I am in; and I have had a desire to do something media wise since I stopped the podcast at Codurance.
Alignment means doing.
The Horror, the horror
Therefore, I had the “brilliant” idea to do videos around TDD. I love TDD, it helps me creating good solutions.
Let me tell you, doing a video, is scary. Even with my experience, and the fact that I have been doing this for years, especially pairing with other people, what if I am doing something completely stupid? What if my TDD has deviated too much and I am not doing the right thing? What if my solution sucks? What if my mumbling is too much to bear (thank Odin for captions). What if, what if, what if…
By Toutatis, can’t let that stop me. The worst case … well, I am quite imaginative, so the worst case can be very, very bad. But a more likely worst case, is that someone will correct what I do, which means a straight benefit for me. And best cases revolve around someone looking at the videos and decide to actually learn more about TDD. A benefit for them.
Which is the main reason I am doing this. I have seen the benefits of TDD, I enjoy the benefits of TDD. I want people to get better approaches on their coding, so they can produce code that does the thing right, and that does it in a way that is easy to change in the future (doing the right thing is a completely different conversation).
The Process
When I started doing the recording, I had two main ideas: not do something rehearsed, and do something closer to what I will do with any production code. That means that during the recording I have not follow a very strict TDD, taking pragmatic decisions at different points (though on quite a few places I go back to the “most simple test/solution”), after all, I have accumulated experience coding. Sometimes, I completely mess up. Sometimes, I make big changes. Sometimes, I think in advance before doing any coding (I do find that thinking about design options up-front, without being too formulaic or process driven, is actually quite good). Sometimes I get stumped for a few minutes. Sometimes I left things on a not perfect state (don’t let perfection be the enemy of releasing). I break the rules if I know the consequences (good or bad) of doing it (when I do not, I prefer to follow the rules).
Maybe I am not yet on the Nirvana of TDD: Learn the rules, follow the rules, break the rules, you are the rules (or something like that).
Production values are minimal (ok, none), some day maybe I’ll take care of that. For a pilot idea, I just wanted to get it out, rather than spend too much time getting something very nice that I never complete (this kind of rings a bell).
The End
I hope I can demonstrate a technical practice that has helped me massively. If you have never done it, you want to be more strict with the rules (probably get someone to teach you those rules). If you have practice the rules already, maybe you can see here a pragmatic way of doing it that is useful for you. Or maybe you try and decide that your path lies elsewhere.
Will there be more? I hope so, doing other stuff too. Meanwhile, here is the beginning:
