Recently, I've been getting back into live coding on the weekend. I didn't realize how much I missed it.
I worked as Technical Director for an online code school (aka'd as a MOOC, for Massively Online Open Course) called thegymnasium.com from 2014-2020, and during that time, I did a weekly livestream of my work on twitch twitch.tv/irreverentmike just about every week for 2-4 hours. It's something I was able to do because everything Gymnasium does is Open Source - you can peruse the source code that powers Gymnasium on Github.
My intention with the livestream was to share my Open Source work on Gymnasium with the world - the easy parts, the hard parts, and everything in between. Depending on the week, I'd be working in VS Code, updating the Python code that Gymnasium ran on, or building front-end components in React, or working in Sketch on designs with our extremely talented designer.
It was a fantastic experience, and a great way to connect with Gymnasium's growing audience of thousands of learners around the world. Importantly, it was also a growth opportunity for me - streaming to a live audience gave me an opportunity to connect with and help people from all over. I got to explain complex development topics to learners in simple terms, and let them see what it's really like for a professional developer to break things in real time.
Lessons learned from live coding
Over the years, I started to notice some of the benefits that my stream provided that aren't obvious at first blush:
- Sharing bumps and bruises is a superpower - Traditional online tutorials often only show the happy path for developers using a tool or implementing a new feature. This leaves students at a significant disadvantage if they have to figure out how to debug something. In live coding, I was breaking things left-and-right, while forcing myself to talk through my debug process, with all my bumps and bruises shown to the world. Time and time again I got feedback from my audience that this was the most valuable part of watching me - seeing how to research/recover/resolve when things go wrong. It's a hard skill to learn on your own, and it's honestly easy to forget that I have years and years of experience un-breaking my own code in various capacities.
- Explaining yourself has reflective benefits - Slowing down and explaining what I was doing and why will really changed the way I work. For me, it caused me to think more deliberately through solutions, and often helped me land the foresight to deploy a better solution more quickly. It's a bit like the benefits of Paired Programming - explaining what you're doing to someone else means that you have to speak your intentions aloud. More often than not, that ends up being a great way to hear yourself explaining flawed ideas. You should give it a shot sometime.
- You'll call out your own faults - This process of slowing down also helped me document my work more thoroughly - when I found myself spending lots of time explaining a complicated solution, workarounds, or strange tricks I'd used, it was a good indicator that the thing I was working on should either (a) have numerous comments in my code to explain the madness within, or (b) that it should be marked as something to later revisit, with occam's razor.
So yeah, I'm back at it again...
I recently started streaming again on the weekends - this time it's not the work I'm doing in my day-to-day at Google, but instead my personal projects which are all OSS. It's a great way to get back into coding for enjoyment, and to force myself to deliver results... I can crank out 2-3 hours of really good work when I'm on stream without getting (too) distracted. If you want to catch some of that, you can find me on twitch at https://www.twitch.tv/irreverentmike
