In my post “Working out loud doesn’t mean being noisy”, I’ve laid out how we at freistil IT make sure everyone on our distributed team is on the same page with regard to both the progress of our work and the state of the people who are doing it. This way of intentional communication is sometimes called “Narrating your work” or simply “Working out loud”. A few weeks ago, I’ve started an experiment of significantly extending the audience with which I share my progress. In fact, I broadcast my software engineering work live on the streaming platform Twitch.

Every Tuesday and Thursday afternoon, I launch my development environment together with a streaming software and get to work on a piece of software that we’re using to run our managed hosting platform freistilbox. People join my live coding channel, say hello, watch me work and comment on what I’m doing. I respond and we get into fun little conversations.

This kind of “exhibitionism” might seem strange or fancy at first but the reasons for my experiment are serious. The idea to do live coding came when we realised that our web operations team was struggling with an internal learning initiative.

As the CTO and most experienced software engineer on the team, I’m always looking for ways to share my know-how. That’s why, a few years ago, I established a weekly video call in which I’d do practical coding exercises with team members who joined me on the call. Since I didn’t want these sessions to be abstract one-way lectures, I tackled current engineering tasks in an interactive way that allowed everyone to chip in with questions and suggestions. Put simply, I extended the Pair Programming method to work with a group. The name for my weekly session was inspired by “Chef”, the system configuration management software we use to automate our IT infrastructure. Chef uses “recipes” to describe processes and comes with tools like “knife” and “test-kitchen”. Aptly, I named my weekly engineering exercise “Cooking with Jochen”.

The issue that emerged over time was that people found it hard to participate in these calls regularly. Project deadlines, sick time, customer support, vacations, a weary head, family duties — all valid reasons that kept team members from attending. This left them feeling that they missed valuable opportunities to learn, and I wasn’t happy either when I ended up doing solo sessions of which I would only be able to share the results but not the journey.

When the team brought up this issue during one of our weekly retrospective, I started to look for a solution. As a distributed team, we needed a way to make my sessions available both asynchronously and location-independently. In the words of the philosopher Shakira:

My first idea was to just use a video conferencing service like Zoom that allowed me to record the Cooking calls. This would allow my team to watch the footage of my sessions at their leisure. Alternatively, I could simply record my screen using an app like Screenflow and publish the videos on our Discourse forum. And then my gaming hobby kicked in and I realised that I could use streaming software to not only record but also broadcast my sessions live. This would solve our participation problem and at the same time reap additional benefits:

• *I’d share my knowledge with my team and with other DevOps practitioners. This would fit the Open Source spirit perfectly because even when I’d be working on internal software, I’d still give something back to the community. After all, “Community” is one my company’s core values.
• *I would be able to exchange ideas and solutions with other developers. I’m sure you’ve experienced yourself how a simple comment from someone else can bring the solution to an issue that had been wrecking your head for ages. Why not tap into this “wisdom of the audience”?

I decided to give it a try, and here’s one of the results:

So, what has my experience with working in public been so far? After about 15 live coding sessions, this is what I found.

My productivity has increased.Even though having casual chats with people dropping in and out while you’re working on a coding problem is distracting, running the live stream made me deliver more results in shorter time than before. And that’s due to the accountabilitya regularly scheduled live stream imposes. Every week, I have two 90-minute calendar items that I can’t easily ditch without feeling that I’m disappointing my followers.

Positive feedback makes happy.I’ll admit it — when strangers tell you things like “You’re awesome”, “Impressive stuff!” and “Cool, thanks!”, it’s hard to not enjoy your work.

Pride is intrinsic motivation. The number of my followers — Twitch users who requested to be notified when I go online — grew surprisingly quick. Within just a few weeks, my channel crossed the 100 followers mark. The fact that people are interested in someone who’s not an elite gamer reaching world ranks in eSports but an IT nerd doing his daily work is a strong motivator for me to keep up this gig.

Stream viewers are great Rubber Ducks.That is not an insult. 😁 Rubber Duck Debugging, or short Rubber Ducking, is a colloquial name for the method of getting a grasp on a problem by verbalising it, even if it’s just to the rubber duck on your desk. I’ve experienced this effect many times and it has happened on stream that I elaborated on an issue I was trying to solve and immediately went “Oh, of course, I know how to handle this.”

A live stream is not the same as a raw screencast.Screencasts are often highly produced videos that required a lot of effort for both recording and editing. The fact that a live stream comes with warts and all, however, doesn’t mean it’s of inferior value. The audience doesn’t just get to see the final result; more often than not the result isn’t even a big deal and nobody would have made a screencast about it in the first place. But they also witness the journey that led to the final result, and many times that’s the more important part. In the same vein, I don’t feel (too) bad when I make mistakes or struggle with coming up with a good solution quickly. I’m basically teaching by letting people watch me learning.

Of course, over these first weeks, I also learned that live coding has its challenges.

It’s a one man show.The internal Cooking sessions before the live stream were interactive and allowed my colleagues to work closely with me. Now they can only join the Twitch chat like everyone else. What puts even more distance between me and them is the fact that their messages appear with significant delay (for moderation reasons, I guess).

It requires solid planning.Choosing the wrong problems to tackle on the live stream will result in a confusing or even boring session. In one of my early streams, I had planned a code change which introduced a significant improvement but then required replacing variable names in a lot of files. Unfortunately, the latter part took up about 80% of the total time — even I got bored! At the end of the session, I apologised for its embarrassing lack of entertainment value.

It’s still too early to say if I’ll keep up live coding for the long term. Even though it certainly strokes my ego to suddenly have somewhat of a fan base, the effect on our engineering work has to stay the most relevant success metric. If it turns out that I’m spending precious time from which our ops team doesn’t benefit significantly, it would be narcissistic to keep it up.

So what will I do if I decide to shut down my live stream? Maybe I’ll go back to recording Zoom sessions. One thing is certain: I’ll make sure to build in the same level of accountability as my stream schedule provides because that’s one of the positive effects I really want to keep.

However, if you think it’s worth keeping up with, follow my stream!