​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

​​Let's start a week with the fundamental stuff affecting all tech folks over decades.

https://www.youtube.com/watch?v=6YbK8o9rZfI

#culture #programming

Choose Boring Culture is a new article by Charity Majors which in my opinion would be useful for engineering managers here and also to the technical leaders.

In this article, she argues that there are two types of culture: formal and informal. Formal culture is what a company and its managers build. Its goal is to make the company to succeed. And it includes all the formal policies around vacation days, compensation, postmortems, team structure, roles, promotions, etc.

All the "funny stuff" is a part of the informal culture. Informal culture is still important, but this is something that should grow organically. So, please, do not force "mandatory fun" on your employees.

And a quote from this article:

 a leader, you should absolutely care about your culture, but your primary responsibility is the health of the business. The purpose of your culture is to make your business succeed. It does not serve you, and it does not serve the people you care about, to be unclear on this front.

#culture

I know that currently there is a hiring freeze in many companies as well as a lot of folks stay put and not actively looking into changing their jobs.

Yet, some hiring is still happening, and some folks are actually joining new companies and therefore going through onboarding.

Hence, I would like to share this article with you - What I Wish I Knew About Onboarding Effectively.

This article has some interesting thoughts. For example, that you are the one who's "owning" your onboarding process. It seems obvious on the surface, but I saw many folks who assume otherwise.

Also, this article has some practical advises on how to prepare for an onboarding and make it a success.

#culture #onboarding

Some Friday material (also, from our subscribers, btw).

DevOps is Bullshit.

Now, once you've got clickbaited, let's talk. The premise of this article has been already repeated many times in different words: a single person cannot know everything and be good in everything, job-specialization is actually good, you can have good enough Jacks of All Trades in the beginning, but it doesn't scale.

The answer that this article provides is to build platforms. Internal platforms, specifically. You know, do Platform Engineering. And I fully agree with this statement. Yet, this article comes from a company that sells you an "IDP as a Service". So, you can clearly see some vested interest here. What I dislike specifically about this article is that instead of striving for standardization, a good platform should "accommodate all the various needs and configurations". I mean, if you sell it to others, it makes sense. If you are building an internal platform, why would you do that?

Anyway, nice Friday read. Here's a reaction video by Primeagen (this is how I actually "read" this article).

Also, if you have any interesting things to share - welcome to our chat! Chat is in Ukrainian, tho.

#devops #culture #platform

Amazing article about decision making

It's big but it's worth it.
TLDR version can be "try to understand why it was done in this way, before trying to abolish or replace it with something else. Otherwise, it can get worse than it was."

#culture

Today, I would like to present to you The Dark Side of SRE.

Basically, this is a yet another article on the things that sucks at work. Things like stress from the incidents, continuous context switch, the need to use multiple technologies and thus inability to become an expert in one, and so on...

I disagree with some points made in this article. Specifically:

- Operational Treadmill:
this where Platform Engineering shines. The whole idea of PE is to switch from the reactive operational approach to the proactive
product-focused approach (OPS still exists in this paradigm, tho)

- The Limited Career Progression: I didn't get this point at all. An SRE can become a manager just as any other engineer if they wish. Obviously, being a manager requires a completely different skill set. However, this point almost sounds like the author was denied a promotion and now is sour about it.

Yet, this article has an interesting document
linked - an instruction from Google SREs on what to expect from an SRE
position outside Google. It's hilarious, TBH. This document shows once again how inconsistent are the titles across the industry. Especially, when it comes to the OPS roles.

#culture #sre

Some time ago, there was a story of a programmer who held the entire Ukrainian customs service as a hostage, because he was the only one familiar with the obscure codebase (that he has created himself).

Unfortunately, this is not a single case over the industry. When a Programmer Holds the Code Hostage tells a similar story that, frankly, could happen at any company.

What are the takeaways? Appeasement doesn't work. It takes some courage and will from the management to identify and successfully address the situation. There are even some tips on how to do it in the end.

#culture

Death by a thousand microservices.

You can consider it to be yet another “old tech guy yells at cloud” article, but it has ratio in it.

Yet, I wouldn’t say that we have to throw away the whole idea of distributed systems. Distributed systems is the reason why I still have a job!

So, I would rather read this piece as a “memento mori” article, a reminder that we have to take things in moderation.

For example, there’s an idea of having a “trunk” monolith supported by a handful of additional smaller services. I know a company that does just that and you know what? They’re fine!

#friday #culture

Let's talk a little bit about culture. Culture of sabotage!

That's a nice guide of how to drop productivity to a minimum without being caught. Enjoy!

https://erikbern.com/2023/12/13/simple-sabotage-for-software.html

#culture

​​There was an interesting talk at CfgMgmtCamp 2024 about non blocking code reviews.

The good thing is that there’s also an article on this topic from the author

The general idea is that not all the code changes require a code review, especially when there are enough safety nets configured.

As a result, smaller code changes simply sit there and wait for be reviewed, which may take some time, especially in a remote setup.

The solution is to allow such changes as they are and add them to a backlog of pending reviews.

There are more details in the article. Also, here’s a picture from that presentation that kinda captures the spirit of this idea.

#programming #culture #devops

The biggest problem in software engineering is distractions.

This is what this article is about. So, I have distracted myself to read it and now I'm distracting you with this post.

Enjoy!

#culture

A reasonable article on how to provide meaningful feedback. Specifically, on how not to be afraid to provide meaningful feedback.

You may already know many of these points, but it won't hurt to re-read them. Also, this is one of the cases where actual practice weights more than theory.

P.S. The original article seems to be behind a paywall, but I was able to read it just fine via Pocket. In any case, here are the tl;dr points provided by the author himself:

Way before giving feedback…

- Build a relationship with the other person - This starts the path of giving feedback to someone like it’s your close friend. Good relationship = easy feedback.
- Share that you are open to receiving feedback - This results in the other person seeing you are growth-minded and often leads to them asking for feedback too.
- Give positive feedback first - This helps build a positive relationship and ensures the other person knows you are on their side and looking out for them.

When you do need to give feedback, follow the feedback process…

- Look inward first. Know your intent - Ensure you are sharing the feedback for the right reason. Not to vent, but to help the other person.
- Get permission - When in doubt, confirm with the other person. This allows them to opt in and prevents backlash.
- Show you care - The most important step. Let them know the reason you are sharing is because you care.
- State your observations - Stick to the facts of the situation. These should hardly be debatable. Call out the common problem.
- Explain the impact - Help the other person understand why it matters. Is it impacting you, others, or the business?
- Get their thoughts - You’re solving a problem together. Get their take on it.
- Align on next steps - Ensure it’s clear what to do moving forward.

#culture #feedback

Today's Friday, so we can talk about some more relaxed topics.

Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP) is a good reminder that working on everything everywhere all-at-once is a bad idea. I'd like to bring up this topic, because I think this issue is even more prevalent in platform teams.

What I missed in this article is some advices on how to address the issue in a controlled fashion: how to properly calculate it and "sell" to the management. Still, you can get some ideas from the discussion on Reddit.

So, as a bonus, I'd also like to share these two articles:

- One is on the Little's Law
- The second one is on the cost of context switching

P.S. I'm in that age when I really regret slacking out at the Queuing Theory lectures in the university :\

#culture