The Main Thread – Issue #4

Reading Time: 4 minutes

Issue n. 4

Main Thread is a curated newsletter by You will find interesting articles, tweets and even podcast episodes about software engineering with a focus on startup engineering and practices.

Being on call for the software you produce is a good incentive to make it better. Would you agree? I was on call the past week and I tried to think about the experience as I was going through it. Psychological safety is key when being on call: the organization must make you feel safe going on call and being on call. You shouldn’t feel anxious about it or, more importantly, alone. But having great colleagues that are always ready to help you out when an incident occurs is not enough, unfortunately. Documentation is key. As you go on call you should be confident about where to find resources that describe the process. Known issues need to be documented and this type of documentation must be kept current. Recurring review meetings are a great way to facilitate that processes and documentations are kept current. The people on call should take note of not only the issues they addressed but the emotions they went through, the pain points they encountered. There is a strong emotional aspect to going on call and this can’t be underestimated. Sharing about this facilitates identifying the changes that really would make an impact in the on call experience. Nevertheless, a successful on call experience is the result of a multitude of aspects of operational readiness that your organization must be deliberate about. Monitoring being one of them. It’s not easy to get it right but it really impacts your understanding of the whole picture, as well as helping you find when problems occur ahead of your customers. It’s important to be deliberate about monitoring: you’ll realise how important it is once you’re in the middle of an incident. If you have missed instrumenting something it’s going to be painful to make up for that: you are going to have to make a change to your software in the middle of an incident to be able to figure out what is going on. Anyway, this was just a brain dump of me: food for thought, as they say.

Roles and Responsibilities

The Rise And Fall Of The Dungeon Master

In this controversial post, Alberto Brandolini, the creator of the Event Storming technique, talks about a figure that you might easily find in those companies that have recently transitioned from an early stage startup to a more established tech company. He calls this figure the Dungeon Master. In this really interesting article the author gives his perspective about the common trait of a Dungeon Master and the consequences of this figure maintaining influence and/or decision making positions. The article has created a bit of turmoil, especially because of the technology choice-driven examples that you can find in it, but I think this is a useful read especially if you’re trying to make sense of why certain things in your organization feel stuck or hard to change.


How To Write Buffer Overflows

This is quite the blast from the past. But I loved it! If you don’t know the L0pht hacker group (like I didn’t before coming across this article) check out the Wikipedia page about them. This post is about writing buffer overflows and if you’ve ever programmed in C it might tickle your curiosity and you might end up spending the evening following it all. At the end of it you will have spawned a shell through buffer overflow!

Interesting Tweets

If you are on Twitter you might have noticed the past week has been crazy for Basecamp. I personally haven’t formed a full opinion on the matter and I think Fried’s post is complex and nuanced. For this issue I decided I’m not going to link to any specific tweet but rather to the “basecamp” search term on twitter.

Interesting Podcast Episodes

Smart Working

Gitlab’s Sid Sidbrandij: “Meetings are expensive”

I loved episode because it goes through such an inspiring success story about trusting your employees and empowering them to work from home. As the Sid Sidbrandij says, though, this is something that requires the whole company to be deliberate about facilitating it. Gitlab’s public handbook demonstrates this a foundational principle for them.

Thank you for making it this far!

If you don’t want to miss out on issues like this one, subscribe here

Thanks for subscribing.
You can find me on Twitter too.