There is a general belief that legacy systems, stale code, and archaic tooling are sleeping dogs – we avoid them fearing a collapse from interference or deprioritize them for seemingly more important projects. I think this strategy of intentional avoidance and/or deprioritization is perfect for disasters.

The challenge with systems that do not fail is that they have no fixes when they eventually fail. Thus, it is more urgent to fix these systems than is usually accepted.

A short, cogent argument why hosting your own cloud services is worth the time/effort:

Consider this, you carefully curate your playlists on Spotify but every now and then you see a certain song missing from your playlist. Same goes for videos saved in your YouTube playlists or other music/video streaming services. Then there is also the case of OTT streaming platforms where the show you were going to watch over weekend has now disappeared.

The author points to r/selfhosted and this awesome self hosted list as good resources to get started.

Pia Wiedermayer, Lead QA at Zühlke, is talking with Gerhard today about software quality. If the name sounds familiar, check out episode 28. Thank you Romano for the introduction 👋🏻

Do you remember the last time that you used an app, whether it was in the browser or on your mobile, and everything just worked? What about that intuitive feel, snappiness and you achieving the task that you intended to without feeling that you are fighting tech? Experiences like those take a lot of effort across multiple disciplines. They are designed, built and maintained over long periods of time. It all starts with people like Pia that really care about quality. It’s so much more than just automated testing…

Today’s conversation with Kelsey Hightower showed Gerhard what he was missing in his quest for automation and Kubernetes. The fundamentals that Kelsey shares will most certainly help you level up your game.

This is a follow-up to the last 45 seconds of the Kubernetes documentary.

Oh, and we finally cleared where we should run our changelog.com PostgreSQL database 🙂

The incomparable Jessica Kerr is back with another grab-bag of amazing topics. We talk about her journey to Honeycomb, devs getting satisfaction from the code they write, why step one for her is “get that new project into production” and step two is observe it, her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design can translate to how we skill up and level up our teams, and so much more.

Jean Yang:

Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.

As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.

Good stuff to be reminded of. That reminds me: You are not Google/Amazon/LinkedIn.

It’s possible to pair well simply by avoiding pairing poorly.

I’ve never thought about it that way, but yeah, makes sense. What follows is a list of things not to do when pairing. Things for navigators, things for drivers, and things for both.

This is just one page from Tuple’s pair programming guide, which looks excellent all-around.

Chris Ferdinandi:

For years, a trend in our industry has been to build single-page apps, or SPAs.

With an SPA, the entire site or app lives in a single HTML file. After the initial load, everything about the app is handled with JavaScript. This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps.

Today, I want to explore why that’s nonsense. Let’s dig in!

I built one of the first big SPAs (remember Grooveshark?), but I’ve shied away from them ever since. I do think there are cases when they make sense (Trello and GMail come to mind), but overall I think too many people chose the architecture too many times because it was the it thing to do vs it was actually the best decision for their circumstance.

Heck, even Chris’s disclaimer of ‘when SPAs make sense’ section at the top is easily defeated by our Turbolinks implementation. But I digress… read this post it’s a good one for sure.

Derek Sivers:

I write almost everything important in my life: thoughts, plans, notes, diaries, correspondence, code, articles, and entire books.

They are my extended memory — my noted self — my organized thoughts. I refer to them often. I search them, update them, and learn from them. I convert them into HTML to make websites, or LaTeX to make books.

My written words are my most precious asset. They are also a history of my life. That’s why I only use plain text files. They are the most reliable, flexible, and long-lasting option. Here’s why.

An argument in support of software packages that come in the form of a single binary executable (statically linked or portable), that one can just copy anywhere in ${PATH} and execute, without needing sudo, or downloading half the distribution’s packages as dependencies.

Straight from the NGINX team:

When we help NGINX users who are having problems, we often see the same configuration mistakes we’ve seen over and over in other users’ configurations – sometimes even in configurations written by fellow NGINX engineers! In this blog we look at 10 of the most common errors, explaining what’s wrong and how to fix it.

If you agree with the notion that you need to be able to tell the difference between the absence of a value and a value itself, then this has some impacts on the code you write. If you want to keep ’em separated (so they can come out and play), then it gets you looking at your API designs in certain ways.

These are my reactions to some of the ways a value can be returned (or not).

Before you head off to read Rachel’s post, allow me to close the loop on that Offspring reference for those of us who didn’t grow up in the 90’s.

This week we’re joined by Annie Sexton, UX Engineer at Render, to talk about her blog post titled Git Organized: A Better Git Flow that made the internet explode when she suggested using reset instead of rebase for a better git flow. On this show we talk about the git flow she suggests and why, how this flow works for her when she’s hacking on the Render codebase (and when she uses it), the good and the bad of Git, and we also talked about the cognitive load of Git commits as you work.

This week we are talking to Robin Morero, the person behind fabled.se, a DevOps consultancy from Gothenburg, Sweden. Their motto is “move faster and prosper”, which Gerhard prefers to the initial “move fast and break things”.

Fabled works with startups primarily, and after 26 years, Robin has a few interesting insights to share. What do you think, are haunted codebases real? At what point do pull requests become harmful? What about k3s running on KVM as a simple starting point for production? If this reminds you of #7, and the follow-up YouTube stream with Lars, it’s no coincidence.

This is a piece that I wrote for GitHub’s ReadME project about an important aspect of software maintenance: recognizing which contributions are a good fit for a project—and which are not.

The thought process applies equally well to proprietary code bases and open source projects.

Troy Hunt (of Have I been Pwned fame) has been a vocal proponent of cloud-first services for awhile. Last December, that strategy came back to bite him:

It all started with my monthly Azure bill for December which was way over what it would normally be. It only took a moment to find the problem…

He goes on to tell the tale in excruciating detail. Be careful out there, cloud natives.

Jesse O’Brien from Test Double wants us to stop using the term “Tech Debt”

There’s loads of reasons why unmaintainable code ends up running in the systems our products are built on, but none of these fit the definition of debt.

Instead, I propose we drop the term Tech Debt and start talking about maintenance tasks. Maintenance is what we’re really talking about. When parts on our car or bicycle suffers wear from driving them around, we don’t talk to our mechanic about “mechanical debt”. (Go back and re-read that sentence, but replace things with “software” and “programmers”). We talk about maintenance.

This post starts as mostly a semantic debate, and I’m not convinced by his arguments there. I think the debt metaphor is useful when you’re talking about trading quality for speed. That’s what you do when you take on debt: you trade higher cost at a future date (principle + interest) to gain access to the money today (speed).

That being said, I really like where Jesse ends this piece talking about software maintenance and methods of going about it. Lots of actionable advice there and I’m 100% onboard with talking about software maintenance early and often. One of the first things I consider when somebody approaches me with a feature idea is ask myself: what will this cost to maintain?

Imagine this: you’ve been paged to investigate a production incident, and after some digging, you identify the commit with the breaking code. You decide to revert the change:

git revert 1a2b3c

Unfortunately, in doing so, a new bug is introduced! As it turns out, hidden in that old “broken” commit was some code that another part of the app depended upon, and when you reverted those lines, it left the site once again in a broken state. 🙃 Oh dear.

How can situations like this be avoided? To answer this question, we first need to examine how these types of commits come to be.

If you’ve never heard of or used git reset… this article is a must-read.

Arnold Galovics’ follow-up to his excellent monoliths are your friend post from late last year.

Starting a greenfield project with microservices is easy. The promises are wonderful but often they are far from reality. This time I’ll share my experience on the truth about microservices when starting a project from scratch.

This post covers 5 cases where the author uses the JSON data type for column definitions:

• Dumping request data for later processing
• Supporting extra fields
• Some one-to-many relationships
• Key-value use cases
• Simpler EAV design

Craig Kerstiens has also weighed in on this topic for us.

I love articles like this one because I was ready to disagree with it going in, but it was so well-reasoned and articulate that I ended up agreeing with most everything the author proposes.

Any debugging story that includes the phrase, “My Mom’s verbal JIRA ticket was right” has a lot of promise. This one by Jim Nielsen delivers the goods. Here’s the culprit:

In my brain, I always thought of Safari and Chrome as “modern” browsers. But even Chrome, an “evergreen” browser, failed because it wasn‘t on an “evergreen” operating system (or hardware).

and his takeaway:

The real-life impact of our technical decisions really hit home to me once again: my Mom had trouble volunteering and participating in her local community because somebody shipped the optional chaining operator in their production JavaScript.

Be thoughtful out there.

Paul Orlando joins Jerod to talk through some unintended consequences that occur when systems operate at scale. We discuss Goodhart’s Law, The Cobra Effect, how to design incentive systems, dependency management decisions, the risks of autonomous vehicles, and much more along the way.

Martin Heinz on the tools/techniques for finding bottlenecks in your Python code. And fixing them, fast.

The first rule of optimization is to not do it. If you really have to though, then optimize where appropriate. Use the above profiling tools to find bottlenecks, so you don’t waste time optimizing some inconsequential piece of code. It’s also useful to create a reproducible benchmark for the piece of code you’re trying to optimize, so that you can measure the actual improvement.

Arnold Galovics:

Microservices are getting natural and we almost feel like we’ve been always living in the world of microservices. Lately when I talked to other developers and asked how they would start a greenfield project, almost certainly the answer was, well, one microservice for this, another one for this, another one for user management, one more for authentication, another for authorization, one more for session management, and the list could go on.

I’m gonna try to shed some light on what nobody is talking about when it comes to microservices. And yeah, it’s gonna be a first-hand experience from a past projects I worked on.

This excellent piece gave me some serious deja vu of Kelsey Hightower’s monoliths are the future. I’m quite looking forward to Arnold’s upcoming “chapter 2” of the story.