It’s subscription based, but with a free trial (all access to the content, for seven days). I discovered this whilst in-between jobs and had no income, so in a time where money is heavily budgeted it’s a testament to James’s work that I decided it was worth the money.
In fact, I think it’s so important to the dev space that I’ve linked to LCTDJS in what I usually reserve for ad space on this blog. You guys need to be watching these videos, even if you already know how to write node apps – the test driven component is brilliant and getting to hear some of James’ ideas should make this a really compelling subscription.
The videos are fairly short. I think they’ve been designed that way so they’re commute friendly. I can’t imagine sitting on a train watching these videos, but maybe you can. The shortness is pretty helpful for me since I’ve now got something to watch whilst eating that’s actually productive (instead of endless Youtube). Despite being short, I’ve not yet watched an episode and thought “well, that was a waste of ten minutes”. I’ve always walked away with a new idea to think about. And there’s such a backlog of videos for me to catch up on, if you need more just watch another.
The videos manage to kick off at a really good point – assuming you know how to program. What you’re learning really is the methodology behind programming (the thing that good programmers focus on). Where you should be spending your time. The code is often secondary to how well it’s tested. The best practices talked about in the series really should be sitting along side industry standards set out in Clean Code.
The videos start by adding build automation and linting. Nothing to do with getting the app working, just making it work cleanly. The emphasis on this throughout the series is why I keep watching. I don’t care to watch a guy telling me the problems and features needed in a collaborative painting app. I care about how the code is designed, and how to think about the choices that come up.
The chapter I’m on at the moment is about deploying the code. It’s not something that would have been consider a software developers job in the past, but now people in our job are going to find themselves more often in the command line. Faster deployment means developers are the ones pushing to live, not administrators. So it’s interesting to see how you can wrap tests around deployment. Had you every thought about TDD for things that aren’t strictly code? Because you should be.
My favourite aspect of the series is the warts and all approach. It would have been easy for James to have edited the videos in a way that just shows how to do TDD. But he also leaves in the walls he runs into. My favourite episode so far is episode 31. He starts the episode realising what he’s worked on recently is a waste of time, and then ends it by running straight into a bug. This is exactly how I program. More than likely how you do to. It’s amazing to see that these problems aren’t a reflection on me as a programmer, but they’re just part of the daily trials of every programmer.