In your company, who designs the end-to-end developer experience? From design to implementation, what is the developer experience that you actually ship? Even though the average developer wastes almost half of their working hours because of bad DX, many of us don’t even know what that means, or how to improve it.

Kenneth Auchenberg is working at Stripe, building economic infrastructure for the internet. Gerhard found his perspective on Developer Experience Infrastructure (DXI) refreshingly simple, as well as very useful.

Might a “modular monolith” be the happy middle ground in the endless monolith or microservices decision? You may have to answer that question for yourself, but this post shares some good thoughts around designing a modular monolith:

When designing a modular monolith, it is all about breaking up the system into modules, and then combining those modules into a monolith for deployment.

It might be worth noting that finding what modules you will need, might not be as easy as you would think. They have to be as independent as possible. High-cohesion and low coupling is very important here, as all communication between the modules might end up being a cross network call, if you decide to break it into services in the future.

This means that all communication between modules need to well abstracted, and be either asynchronous, so that they can handle the call going across the network in the future, or use some form of messaging.

Natalie & Ian welcome Liran Haimovitch & Tiago Queiroz to the show for a discussion focused on debugging Go programs. They cover good & bad debugging practices, the difficulty of debugging in the cloud, the value of errors logs & metrics, the practice of debugging in production (or not) & much more!

In today’s episode we have the pleasure of Audun Fauchald Strand, Principal Software Engineer at NAV.no, Norway’s Labour & Welfare Administration. We will be talking about NAIS.io, the application platform that runs on-prem, as well as on the public cloud.

Imagine hundreds of developers shipping on an average day 300 changes into a system which processes $100,000,000 worth of transactions on a quiet week. If you think this is hard, consider the context: a government institution which must comply with all laws & regulations.

Simon Willison describes the Perfect Commit as a single commit that contains all of the following:

• The implementation: a single, focused change
• Tests that demonstrate the implementation works
• Updated documentation reflecting the change
• A link to an issue thread providing further context

Here’s four paragraphs on how he got to here:

I went through a several year phase of writing essays in my commit messages, trying to capture as much of the background context and thinking as possible.

My commit messages grew a lot shorter when I started bundling the updated documentation in the commit—since often much of the material I’d previously included in the commit message was now in that documentation instead.

As I extended my practice of writing issue threads, I found that they were a better place for most of this context than the commit messages themselves. They supported embedded media, were more discoverable and I could continue to extend them even after the commit had landed.

Today many of my commit messages are a single line summary and a link to an issue!

This is one of those pieces of advice that is easy to say, but hard to do. Cedric Chin:

The only problem with this advice is that it’s trite — it sounds obvious; people don’t take it seriously; it’s a cliché. But it really isn’t any of those things, not if you’re actually trying to put it to practice. One of the more interesting things about focus is that you can see it in good operators, if you know how to look. But it happens to also be really difficult to do.

Instead of articulating a fully-fleshed out theory of focus, I want to do something different here. I’m going to tell you a handful of stories. This should do more to illustrate the nature of focus in business than anything else that I can say. Let’s get started.

Some good stories follow. I’ll just add that good ideas is just one category of things that focus means saying “no” to. Another major category is good opportunities.

When you’re first getting started in your career, you are short on opportunities and long on time. But success breeds success. At a certain point, that relationship flips and you have more opportunities (actual, good ones) than you have time. Saying “no” to the wrong ones and “yes” to the right ones is another lesson in and of itself, but the same thing is in danger: your focus.

This is an excellent deep-dive on error message best practices by Jenni Nadler from Wix:

Error messages are part of our daily lives online. Every time a server is down or we don’t have internet, or we forget to add some info in a form, we get an error message. “Something went wrong” is the classic. But what went wrong? What happened? And, most importantly, how can I fix it?

Smashing Mag’s Vitaly Friedman puts down some of his recent thoughts on authentication flows:

nobody wakes up in the morning hoping to finally identify crosswalks and fire hydrants that day. Yet every day, we prompt users through hoops and loops to sign up and log in, to set a complex enough password or recover one, to find a way to restore access to locked accounts and logged-out sessions.

Of course security matters, yet too often, it gets in the way of usability. As Jared Spool said once, “If a product isn’t usable, it’s also not secure.” That’s when people start using private email accounts and put passwords on stick-it-notes because they forget them. As usual, Jared hits the nail on the head here. So what can we do to improve the authentication UX?

Vitaly lists seven recommendations. Nothing radical here, but solid advice worth thinking through.

I don’t think that you can imagine just how excited Gerhard was to find out that Audi, his favourite car company, has a Kubernetes competence centre. We have Sebastian Kister joining us today to tell us why people, followed by tech make the process.

The right thing to focus on is the genuine smiles that people give in response to something we do or say. That is an important SLI & SLO for reducing friction between silos.

How does this impact the flow of artefacts into production systems that design & build cars?

A journey from Stripe to Paypal and back to Stripe led Zed Shaw to the conclusion in the headline. And, no, that is not a compliment (in case you weren’t sure).

Zed goes deep on why he feels this way, listing seven serious downsides to using Stripe today. What’s a dev to do? His advice at the end alone is worth the cost of admission:

This is why I advocate to people to be ready to switch payment processing at a moment’s notice. Right now I could flip two options and I’d be back on Paypal. If I was pressed I could probably implement any other payment processor in about a week or a day. The ability to quickly switch payments is your only defense against frozen accounts, fraud, and rogue employees.

This week we’re talking about product development structures as systems with Lucas da Costa. The last time we had Lucas on the show he was living the text-mode only life, and now we’re more than 3 years later, Lucas has doubled down on all things text mode. Today’s conversation with Lucas maps several ideas he’s shared recently on his blog. We talk about deadlines being pointless, trajectory vs roadmap and the downfall of long-term planning, the practices of daily stand-ups and what to do instead, measuring queues not cycle time, and probably the most controversial of them all — actually talking to your customers. Have you heard? It’s this newly disruptive Agile framework that seems to be working well.

Dave Farley, co-author of Continuous Delivery, is back to talk about his latest book, Modern Software Engineering, a Top 3 Software Engineering best seller on Amazon UK this September. Shipping good software starts with you giving yourself permission to do a good job. It continues with a healthy curiosity, admitting that you don’t know, and running many experiments, safely, without blowing everything up. And then there is scope creep…

Inbal Cohen, Product expert and Agile evangelist, joins Natalie & Angelica for a conversation about all things Agile. Inbal lays out some agile tips for Go devs, discusses if and how remote work changes things, describes some downsides of the methodology, and more.

Egon Elbre and Roger Peppe join Mat for a conversation all about bloat (and how to avoid it). Expect talk of code bloat, binary bloat, feature bloat, and an even-more-bloated-than-usual unpopular opinion segment.

This article isn’t arguing against writing user stories, it’s arguing against keeping user stories:

If you put the story in your icebox/backlog/cooler/hat, it’s time for it to go. It’s now duplicate documentation. That story was only there because you were yet to break it down into tasks. Now you have, so you delete it.

I don’t mean tick it off as complete, I mean right-click on it and hit the ‘delete’ button.

Julia Evans shares five things you can do to getting better at debugging, which is a critical skill for everyone in tech! They are:

1. learn the codebase
2. learn the system
3. learn your tools
4. learn strategies
5. get experience

Each thing comes with an explanation and she shares a great quote at the end (from a paper she extracted these things from):

Their findings did not show a significant difference in the strategies employed by the novices and experts. Experts simply formed more correct hypotheses and were more efficient at finding the fault. The authors suspect that this result is due to the difference in the programming experience between novices and experts.

Having a smaller website makes it load faster — that’s not surprising.

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

The reason for this is because of how TCP works, which is nicely explained in the post. But is 14kB even a feasible reality? The author thinks so:

That 14kB includes compression — so it could actually be more like ~50kB of uncompressed data — which is generous. Consider that the Apollo 11 guidance computers only had 72kB of memory.

Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes — you’re probably there.

Most of our audience knows that we operate on the mantra “Slow and steady wins,” and yet there’s lessons to be learned by reading a post adjudicating the need to “Move fast or die.” Let me explain…

There’s a key phrase that sets this post and its lessons apart from us here at Changelog Media — it’s “Here’s how we did it at Facebook.” Clearly, we are not Facebook, so we should not operate on advice that’s focused on Facebook. However, we can learn something.

Of the the five lessons shared, each can be appreciated, but one in particular stands out.

We embraced asking for forgiveness, never for permission.

This, to me, is synonymous with “Hire people smarter than you,” because it assumes everyone can bring something to the table that former wisdom might not. It gives permission to try something new and see if something beautiful comes as a result. That’s a good thing.

In this episode, we’ll be further exploring PRs. Check out The art of the PR: Part 1 if you haven’t yet. What is it that makes a PR a good PR? How do you consider PRs in an open source repo? How do you vet contributions from people who aren’t a part of the repository? How does giving feedback and encouragement fit in to the PR process? We’ll be debating the details, and trying to help our fellow gophers perfect the art of the PR. We are joined by the awesome Anderson Queiroz, hosted by Natalie Pistunovich & Angelica Hill.

Struggling through the tech job interview process? We feel you! On this episode, Amal, Nick & Amelia get together to discuss the various ways the interview process disappoints, share their own interview stories, and suggest ways we can improve the process for everyone.

In this episode, we will be exploring PRs. What makes a good PR? How do you give the best PR review? Is there such thing as too small, or big of a PR? We’ll be debating the details, and trying to help our fellow gophers perfect the art of the PR. We are joined by three wonderful guests Jeff Hernandez, Sarah Duncan, and Natasha Dykes. Hosted by Angelica Hill & Natalie Pistunovich.

Daily stand-ups are a classic example of learned helplessness. We all know they’re useless, but we tell ourselves “that’s just how things are” and do nothing about it.

Lucas provides a set of five symptoms that indicate you’re doing stand-ups wrong and says if your team hits at least three of the five, your stand-ups are useless.

But, instead of just telling you to stop doing them (like I probably would), he provides a bunch of solid advice on how to make them useful again.

A lot of ink is spent on the “monoliths vs. microservices” debate, but the real issue behind this debate is about whether distributed system architecture is worth the developer time and cost overheads. By thinking about the real operational considerations of our systems, we can get some insight into whether we actually need distributed systems for most things.

Scaling up has always been easier than scaling out. It’s amazing what one beefy server can do these days…

How using OpenAPI (previously called Swagger) has led to being able to ship a new service more effectively, by removing the need to write scaffolding, and instead focus on the business logic.

Daniel Sieger:

If you’ve been developing software for a while, you know that code has this natural tendency to turn into a mess. Keeping software simple over time is a challenge that keeps me thinking. My last post left you hanging without much concrete advice. This time I will outline a few high-level strategies to keep software simple.