Hey there!

Everyone is talking about the developer experience, and for good reason. I’m super excited to welcome another guest author from the community: Okay’s CEO and Co-founder Antoine Boulanger. He’s sharing his approach to boosting DevEx.

Let’s get bakin’

Optimizing feedback loops to improve DevEx

Antoine Boulanger, CEO and Co-founder at Okay

Understanding your engineers’ pain points is important for determining which feedback loops to investigate and address. The approach is very different when the CS team is overloaded with customer bug reports, vs when the engineering team is frustrated that it can't ship code fast enough.

There are three main types of feedback loops:

• Quality - all the flows that engineers use to ensure they’re building code that meets their customers’ requirements
• Delivering code - all the flows engineers use while writing and modifying code
• Process - all the checklists or meetings engineers are required to attend as part of their job responsibilities

Each category has its own set of feedback loops that can be evaluated and optimized to improve the effectiveness of the team. Below are examples of common loops across each category.

Quality Feedback Loops:

• Writing a new test
• Code reviews
• Responding to page

Delivering Code Feedback Loops:

• Common IDE/CLI commands
• Finding documentation
• Building a service
• Creating a new service
• Deploying a change

Process Feedback Loops:

• Postmortems
• Agile/Scrum
• Onboarding to a new team
• On-call

Optimizing feedback loops to improve productivity typically follows its own loop:

• Catalog all your existing feedback loops with an understanding of their frequency, latency, usability, and purpose.
• Create a prioritization framework that weighs these factors in a way that is consistent with your values and culture.
• Create an action plan to prioritize.

Remember that sometimes, the right choice can be to remove the loop altogether. For example, let’s say you have a centralized approval committee that requires every engineer to present a design for every new change. It’s important to evaluate and measure whether this process loop is accomplishing its purpose, and worth the ROI.

Loops must be analyzed and measured because many of them are frequently overlooked. It’s very tempting to ignore and delay indefinitely working on slow build times, and continue prioritizing new features instead. Over time, too many poor loops can lead to the feeling of death by a thousand cuts.

Check out the full article here.

‍

Short on time? ⏳ We got you 🥐😋

🥐 Platform engineering =/= building fancy UIs. Kaspar von Grünberg explains how confusing the two is kneecapping your organization’s platform engineering efforts.

🥐 Most platform engineering pitfalls can be avoided with treating your platform as a product. Aaron Erickson makes his case over at InfoQ.

🥐 Platform engineering helps you do more with less. Daniel Bryant explains:

“If the developer experience — and enabling the developer’s work — is crucial to achieving business goals and using resources wisely, the DevOps/PlatformOps role and platforming engineering are equally instrumental in continuously improving and safeguarding the developer experience.”

🥐 What happens when you create a pod in Kubernetes? A thread 🧵

Have you joined the Platform Engineering Slack channel? If not, you're missing out. Here are some highlights from the community:

• Platform engineers from our community are looking for a job
• Enabling GitHub authentication provider in the Backstage frontend
• Open source examples on how to coordinate a golden path document at my organization
• Looking for a cost-effective, scalable, and reliable log analysis solution

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it our way.

Stay crunchy 🥐

Luca

‍