As I learned that my team is having issues managing incidents, I naturally gravitated towards those issues.
Software Engineering ⚙️
Facebook suffered the worst outage in recent years last week. Its VP of Infrastructure explains how a wrong command and a bug resulted in a global outage lasting hours.
A common pitfall for an engineering team dealing with an incident is not to involve customer-facing teams like account management or customer service teams. Everyone who gets impacted by an incident should be informed and consulted.
An engineer from Mailchimp shares a cautionary (yet, exciting) tale on what could go wrong when overly optimistic. Being optimistic is ok, but let’s think the plan through before we invest our precious time.
I found it surprising that Go didn’t have a typegen-based GraphQL client before genqclient. There is gqlgen, which focuses on creating a type-safe GraphQL server, but nothing as a client.
As the products and the teams scale, their codebases get larger. When the sizes get to a certain point, the existing tools start to break down. That’s why teams come up with git alternatives and cloud editors. The iOS team at Airbnb adopted a cached build system, introduced module types, and enabled dev apps.
A leader’s work is about leverage. Since feedback cycles for leaders are generally longer and people are usually less inclined to provide feedback to their leaders, it’s too easy for leaders to create negative leverage by creating busy work for their teams.
Decision-making based on authority should be the last resort as such unilateralism can fail to get needed commitment and, worse, result in skepticism and burnouts. My usual tactic is to build trusting relationships and use story-telling based on the shared understanding.
Cool stuff 😎
I didn’t know I needed this before. But I want it so badly now.