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

Coordination Headwind (How Organizations Are Like Slime Mold) is a 171-slide presentation by Alex Komoroske that tells a story of changes in the organizational dynamics as an organization grows.

This presentation answers the question that many of you might have had at some point of the time: how comes that it suddenly becomes an impossible task to do something in an organization that was able to execute things superfast just a couple of years ago?

Alex digs into the project delivery math as well, highlights some things that inevitably lead to the execution slowdown.

Sure, you may say that this presentation would more interesting to the managers, but not only them! Individuals matter! Also, this is still a channel about DevOps and DevOps is about culture and collaboration.

#culture

Puppet Labs have issued a new State of DevOps 2023 report.

This time it’s focused on Platform Engineering and how it helps organizations to achieve their goals and move further with their DevOps journey. Key takeaways (opinionated):

- While DevOps helps to foster collaboration and delivery velocity inside teams, platform engineering helps to increase the delivery velocity across the organization.
- Companies that have implemented platform engineering approach are satisfied with it. Also, companies that have platform teams for longer period of time are more satisfied, which is a good sign.
- Platform engineering treats infrastructure (observability, CI/CD, etc.) as a product, not as project. Therefore, platform teams benefit from a product manager position within a team.
- Yet, about a half of respondents have reported that their senior leadership is still concerned about the topic of platform engineering or confused about it.
- Centralized platform team is more common compared to decentralized and people who work in a centralized structure are more satisfied.
- Organizations plan to hire engineers to work on their internal platforms. So, you‘re safe :)
- 01 Normalize the technology stack => 02 Standardize and reduce variability => 03 Expand DevOps practices => 04 Automate infrastructure delivery => 06 Provide self-service capabilities => ???? => PROFIT!!1

#report #culture #platform_engineering #devops