On Thursday, November 18, 2021, Dropbox did not go down. It sounds like a beginning of some modernist novel. Yet, this is rather a post-mortem on an incident that never happened.

This is a great story of leadership and dedication, which lasted for a few years. Results? Dropbox were able to literally pull the network cord from their data center and “do not go down on 18 of November, 2021”. And not just a data center, but their main one.

I really enjoyed this story because it proves once again a few basic things that we prefer not to think about:
- Any project take time and effort. Big projects take a lot of time and effort. If you’re looking into rebuilding your system from scratch, that won’t take a week or two.
- Big projects require dedication. You cannot just add them as a side hassle for your existing team and expect them to deliver everything with the highest quality.
- Iterative improvements. Apollo 11 was the first mission to reach the Moon not because 11 is a pretty number.
- Test and exercise. It’s not enough just to “implement the best practices”, you have to validate if those are actually working as expected. And if there’s a process involved, you have to repeat it frequently enough to not to get rusty.

#infrastructure #culture #postmortem

A story about how chaos engineering helps companies teams to find bottlenecks in their systems.

The good thing about this article is that it provides links some tools you can use for your infrastructure as well.

#chaos_engineering #culture

Some notes from the interview with Kent Beck on the cargo culting software engineering practices and approaches to develop software in general.

Here are few my notes from this article:

- There is no value in copy-pasting someone else's processes and approaches e.g. Spotify-model. You have to work to develop your unique approach, because your context is different. Things that work for <companyName> won't probably work for you.

What engineering practices can other companies and startups learn from Facebook?

Nothing. People should figure out what their style is and do their style. I’ve been talking about software process for a long, long time. Something I notice is there are people who are uncomfortable taking responsibility. They want a process where they can say, “Well, hey, we executed the process. We failed, but we executed the process.”


- Job titles shape culture and process as well: if there's a Scrum master, ppl won't use Kanban, etc.

- You need to think ahead, how long a software would live and how many times is it used. You can plan accordingly:
- Do not overthink scripts for limited time or usage
- Take time to design long-term systems

#culture

An interesting thread about the perception of performance by managers and developers.

165 managers and developers were asked about how they define productivity and how do they think their managers or their teams define that.

In nutshell:
- 50% of developers associate productivity with activity i.e. number of PRs, closed tickets, etc.
- At the same time developers think that efficiency doesn’t matters to the management as well as their well-being.

At the same time, 67% of managers define productivity by performance and quality of delivered products and 45% by efficiency.

The study also explores the trade offs between quality and productivity. If you’re interested in the original paper, it’s available here.

The key takeaway here for me is that unless you agree on the common ground on how to define productivity, you won’t be able to move as fast and smooth as you could. Moreover, the absence of understanding of this matter may jeopardize decisions, when it comes to sacrificing quality a bit in sake of delivery deadlines.

#culture

​Good documentation is foundational for implementing DevOps capabilities - State of DevOps says.

But writing good docs is hard... and what can you do, except hire a Tech writer?
Cry Try to write docs better.

Here are free technical writing courses by Google (and quick recap). I drive "good docs culture" (that happened historically) in my current job and find these courses really helpful in describing to teammates how docs should look.

Also, I found that already exist documentation style guides by Google and Microsoft so you don't need entirely reinvent the wheel, just a little part of it ;)

On the other hand, these style guides look very complicated, so to not be overwhelmed, just start from these highlights.

And if you need, more technical writing resources and reasons why docs should be and should be good - here.

P.S. Don't repeat my mistake - take these courses before start writing and reviewing docs on a regular basis, not in ~2 years after.

#documentation #culture

​The Grug Brained Developer

A layman's guide to thinking like the self-aware smol brained.

#culture

I’ve decided to clean up my old saved articles a little bit. So, here’s Charity Major’s take on “the trap of prematurely senior engineer”.

It’s kinda old, but age is irrelevant on that matter, in my opinion.

In nutshell, this is the same argument about “if you’re the smartest person in a room, you’re in a wrong room”. Yet, with a better wording. Sometimes it’s very appealing to be “the smartest person”, but it also could be a trap. I like it, when it’s put this way.

#culture

A blog post by Charity Majors about Platform Engineering as a next generation of OPS-ish work.

She also created a table of skills, or rather skills differences, between Platform engineers and DevOps engineers. I don’t fully agree with all those differences, but I’m not quite sure yet, is it because I’m not fully onboarded yet to the concept of Platform Engineering or I just generally disagree.

Anyways, if you need a single-sentence summary of the Platform Engineering, let it be this one:

One of the key principles of any developer platform is that it should be easy to do the right things, and hard to do the wrong things.

#culture #platform_engineering

Charity Majors argues in her article that taking job hierarchy too close to your heart is problematic. We all want to get promotions and have our contributions recognized. However, this is not a race to the bottom. Getting a position that you hate just because it’s higher in the hierarchy can be damaging to your wellbeing.

I think this is an important thing. I know many folks, who strive for “higher” positions not because they want to make an impact, but because “this is how the world works”. Also, I know situations when people are in the positions they’re not qualified for, but they’re just “too long with the company”, etc.

The main argument is that it’s totally fine to be an engineer and stay on the individual contributor’s track.

There are a couple of advices from Charity on how to make this work:
- Treat work hierarchy not as a ladder, but as a data structure: the hierarchy represents, who does what, but not who is “cooler”
- Involve engineers into the decision making process. If becoming a manager is the only way to make your voice heard, you’re in a wrong organization
- Flatten compensation ranges: it’s not necessary for the managers to earn more than individual contributors. In fact, it can be the opposite in many cases
- Be transparent and make sure that people understand not only what do they do, but also why. It’s not the amount of work that makes people burn out in many cases, but a feeling of meaningless of that work.

#culture

Some time ago (initial commit on the 2nd of May 2021) I started a small side-project - an Awesome List of Ukrainian IT Communities.

There are more than 60 chats, groups, channels, and other resources mentioned there already! And I would appreciate if you help to make this list even more awesome 😎

Your PRs are very welcome!

Also, there is web view if you prefer that.

#culture