In my prior life as a professional live poker player, game streams, online and offline, were some of the most powerful learning opportunities that I had. The same is true for programming...
I'm doing an experiment (again). Live Stream Coding. And Writing Small Programs (again).
In my prior life as professional small stakes live poker player, game streams, online and offline, were some of the most powerful learning opportunities that I had. Seeing what's actually going on under the hood and the thoughts of experienced players were incredibly helpful.
The same is true for programming. Seeing developers solving issues on the spot is a whole different thing than seeing them present you the well-crafted materials in form of books, blogs, and video courses.
We are not just professional coders. We are also professional Googlers. The earlier in the career, the more we are the latter than the former. Why is it then that in conventional educational coding videos we only see how someone is solving a problem perfectly? Not their struggles and actual findings along the way? Googling and debugging well, is as essential as software architecture, language knowledge, and algorithms, especially at the beginning of your career.
But is every live stream a learning opportunity?
Apart from doing a live stream every day for the last week, I've been reading up on this topic. There are streamers who condemn code streaming, there are streamers who love them. The same goes for watchers. The issue is, every live stream is different, done by different people with different intentions.
If you want to do a live stream while coding your next big project, that's cool, and some people will love it, but it's definitely not as fun and educational as working on a small problem or challenge the complexity of which is easy to fit into every watcher's brain.
I've been looking at live streams that many developers are doing at the moment. It's sometimes hard to learn from them unless they are doing a structured session about a focused topic.
There are inherent issues with jumping into a live stream of a large codebase, where the streamer works on a non-trivial problem.
Educational issues when jumping into a live stream:
- You don't have the codebase context
- You don't have the domain knowledge
- You don't know what is currently worked on
Still, some developer streamers reach an audience of up to about 100 live watchers. Good job! Having a lot of watchers is cool and ensures lively chat discussions. But this brings another challenge for the stream as a learning opportunity: It distracts the coding streamer and the progress of solving the problem at hand.
4. Learning is always interrupted
5. Project's progress is interrupted
This is cool if you are inside the stream to hang out with folks, but less cool if you are there to learn 📚
Looking at all these issues, I wonder if we can set some parameters for live streams to make them more effective for learners? What is the minority of the exceptional educational streamers doing so well?
Making live streams more of an enjoyable educational experience:
- Present the codebase at the beginning of each stream, keep your Small Program™ small enough, so that its complexity fits into people's brains
- Explain the domain context and the problem to solve, don't expect watchers to have knowledge as you do
- Set clear goals and keep a visible note about the project's progress so far
- Comments are fun, handle non-essential comments during breaks or at the end of the session
- Encourage watchers to interact with you in a pair/mob programming type of way, where you all try to solve the challenge together
These are my initial thoughts and I will experiment with them as my streaming adventure progresses.
Basically, from this perspective, the answer to the question of Why Live Streaming Coding is to experiment with live streaming even more as an educational tool than hanging out with other devs.
And then Why Writing Small Programs? In order to make Live Streaming Coding more of an enjoyable learning experience. What a closure 🔄
There's a bit more to it, though, than I want to handle in this post. More details and reasons on how I came to writing small programs (again) in a live coding stream fashion: