Gergely Orosz did an excellent job detailing the ins & outs of Atlassian’s epic outage:

Hundreds of companies have no access to JIRA, Confluence and OpsGenie. What can engineering teams learn from the poor handling of this outage?

The TL;DR on the cause of the outage is a script that was supposed to “mark for deletion” some records also had “permanently delete” functionality and was run against a wrong list of IDs, improperly deleting 400 of their customers. Oh, and their backup restore process is really good at doing all customers, but not a subset. Ruh roh!

Lots to learn here, and Gergely puts a fine point on the biggest takeaways. A must-read!

Gergely Orosz shared advice that he’d give to himself 10 years ago. It’s interesting how hindsight is always 20/20…it’s easier to connect the dots looking back vs looking forward.

As I look back to over a decade ago, there are a few things I wish I’d started doing sooner. Habits that could have helped made me grow faster and in a more focused way. This is the advice I’d give my younger self, who has just landed their first professional software engineering job.

1. Take the time to read two books per year on software engineering … Every time I took the time to slowly and thoroughly read a recommended book on software engineering, I leveled up. By properly reading, I mean taking notes, talking chapters through with others, doodle diagrams, trying out, going back, and re-reading…

If you are a leader or someone aspiring to lead, consider this approach to engineering management.

This post is a summary of the approach and tools I’ve used to build an engineering team, where everyone is a leader - including sharing of the project management expectations Google Docs guide that my team uses. It’s also a reflection on the pain points that came with this approach. I can’t advocate for how universally this approach could work. However, based on my results, it is something I suggest engineering leaders - especially frontline managers - consider as an option.

What, exactly, is mentoring? How does it work? Better yet, how does it work well? In this post Gergely Orosz, Engineering Manager at Uber, shares his perspective and the practices he’s seen work well.

Mentorship has been the best things that’s sped up my growth and others engineers around me. This post discusses mentorship practices that work well engineer-to-engineer. The practices come from my own experience, observations I’ve made people mentoring each other and from conversations I’ve had with half a dozen mentors in my network and on Coding Coach.

Being able to communicate and write well often plays out to being a huge asset in a career. But how does that works for software engineers? Gergely Orosz writes on his personal blog:

For software engineers, writing becomes the tool to reach, converse with and influence engineers and teams outside their immediate peers. Writing becomes essential to make thoughts, tradeoffs and decisions durable. Writing things downs makes these thoughts available for a wide range of people to read.