Eric Bailey’s take on CSS is certainly counter to the direction most are headed:

Human-friendly CSS is an interface that prioritizes people. It allows someone using your website or web app to easily make modifications to get what they need. This is huge because we can’t know who the person is, or what circumstances they’re experiencing.

Humans reading/modifying your CSS may seem like an edge case, but it’s more common than you think:

Stylus on the Chrome Web Store has more than half a million users. Stylish has over three million. That’s a lot of people modifying the web to get what they want.

He goes on to point out that even if it weren’t that many people, it’s still worth considering for other reasons. Lots to ponder.

The bulk of this post by Brett Cannon is a detailed argument that Python makes sense to select even for projects with known performance concerns, but I got my money’s worth from the concept in the title and opener:

… it dawned on me that the problem is people are not treating language selection as potential form of premature optimization: if you select a programming language based on your preconceived notions of how a language performs, you will never know if the language that might be a better, more productive fit for your developers would have actually worked out.

This week Gerhard is chatting with Romano Roth, Head of DevOps at Zühlke, a company founded by Gerhard Zühlke in 1968. Nowadays they help companies all over the world build, ship and run anything from factory robots, to AI assistants in complex regulatory environments, and even medical devices that perform autonomous robotic surgery.

When Romano is not leading a team of 30 software engineers that specialise in operations, infrastructure and cloud, he is one of the organisers of DevOps Days Zürich, and also the DevOps Meetup group which is how Gerhard and Romano met in 2019.

Having started his career as a .Net developer back in 2002, Romano had his fair share of dev and ops challenges, and he always enjoys seeing real business value delivered continuously in an automated way. In recent years, Romano’s perspective broadened, and now he sees DevOps realities across many companies. If you are curious about what good DevOps looks like, and what are the real challenges, then Romano has some good insights for you.

Rachel by the Bay:

There’s a post going around tonight about how someone forgot to put an index on some database thing and wound up doing full table scans (or something like that). The rub is that instead of just being slow, it also cost a fair amount of money because this crazy vendor system charged by the row or somesuch. So, by scanning the whole table, they touched all of those rows, and oh hey, massive amounts of money just set ablaze!

The usual venues are discussing it, and I get the impression some people have the wrong approach to this. I want to describe a truly bad database schema I encountered, and then tell you a little about what it did to the system performance.

A fun story with an excellent twist at the end.

Code quality affects the mental state of a programmer, communication within their team, and the incentives attached to their work. Improve your code and you can improve your organizational health and competence as a whole.

Slow down to go faster.

This week Gerhard is talking with Arnaud Porterie, founder of EchoesHQ, a new utility that measures and communicates engineering activity.

They start by re-creating the 60 seconds Y Combinator pitch, and then shift focus to what it was like to get EchoesHQ off the ground. Next, they tackle something which is always on Gerhard’s mind: Why is it important to connect our daily engineering activity to intent?

Before EchoesHQ, Arnaud used to run the core team and the open source project at Docker, and combined with other engineering leadership roles that he held for over a decade, he kept encountering misalignment that was preventing organisations from making meaningful progress. Let’s hear why EchoesHQ might just be a great way of addressing this.

If you have a library dependency that your application relies upon, and you’re afraid to (or for whatever reason will not) peek under the covers and grok its source code… you should not be using that piece of software.

Of all the principles of software engineering which has fallen by the wayside in the modern “move fast and break things” mentality of assholes modern software developers, reliability is perhaps the most neglected, along with its cousin, robustness. Almost all software that users encounter in $CURRENTYEAR is straight-up broken, and often badly.

A scathing rant by Drew DeVault, but it comes with sage advice on how we move forward from here:

You must prioritize simplicity. You and I are not smart enough to be clever, so don’t try. As the old saying goes, there are two kinds of programs: those simple enough to obviously have no bugs, and those complicated enough to have no obvious bugs. It is by no means easier to make the simpler kind, in fact, it’s much more difficult. However, the simpler the system is, the easier it is to reason about all of its states and edge cases. You do not need a JavaScript-powered custom textbox widget. YOU DO NOT NEED A JAVASCRIPT-POWERED CUSTOM TEXTBOX WIDGET.

Today we’re talking to Matt Rickard about his blog post, Reflections on 10,000 Hours of Programming. Matt was clear to mention that these reflections are purely about coding, not career advice or other soft skills. These reflections are just about deliberately writing code for 10,000 hours, which also correlates with the number of hours needed to master a skill.

If you count the reflections we cover on the show and be the first to comment on this episode, we’ll get in touch and send you a coupon code to use for a 100% free t-shirt in the merch store. Good luck…

This piece by Lucas F Costa starts off right where I live:

There are many ways of estimating how long a software project will take. All of them are a waste of time.

It then goes on to describe a different way of doing it:

Instead of making “informed” guesses or multiplying estimations by N, we can embrace the randomness and variability involved in writing software and use more suitable statical methods, in this case, stochastic modeling techniques, to devise better forecasts. One of these techniques is the Monte Carlo method, which I’ll use to make projections in the rest of this post.

In this post, I expand upon Michael Nygard’s post Documenting Architecture Decisions. Michael defines architecturally significant decisions as those decisions that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques. I add examples to each of the five decisions categories.

Today we have a very special episode, where Gerhard gets to share his favourite learnings from Steve Jobs. If it wasn’t for his determination to build a better personal computer, Gerhard would have most likely continued with a career in physics.

We know what you’re thinking: it’s crazy and impossible to interview Steve Jobs, but on his 10th memorial anniversary, Gerhard was determined to combine the things that Steve said with his passion for computers, automation, and infrastructure.

Live your life and ship your best stuff because there’s nothing like the present.

Thank you, Steve.

It’s common for me to get excited about a personal project, put a bunch of time into it, and then lose interest. As much as possible, I want these projects to continue working; upkeep isn’t fun. What does designing for minimum maintenance look like?

Great question!

Things go wrong all the time. We all make mistakes. And that is okay. What is not okay, is to think that it won’t happen, or that there will be someone else around when it does. In that moment, it doesn’t matter who wrote that module, package or microservice. But there is a better way to think about this, and there is an approach that makes people actually look forward to incidents.

It all starts with thinking of incidents as opportunities to learn, and then share those learnings with everyone, so that you can all improve. In this episode, Gerhard is joined by Stephen Whitworth and Chris Evans, incident.io co-founders, and former Staff Engineers at Monzo.

They get it, we get it, and now you can get it too.

When most teams complain about poor quality, they usually mean reliability woes; however, quality spans a more extensive spectrum and can mean many things. This post posits a quality hierarchy that identifies the pertinent challenges and helps with making the right tradeoffs.

Eugene Yan, in a post titled The first rule of machine learning: start without machine learning:

Applying machine learning effectively is tricky. You need data. You need a robust pipeline to support your data flows. And most of all, you need high-quality labels. As a result, most of the time, my first iteration doesn’t involve machine learning at all.

Eugene is stating the obvious with this post, but hey sometimes you just gotta state it. What’s even more interesting to me is how nicely the format generalizes! Let’s pattern match this sucker:

The first rule of X: start without X

Now, apply the pattern a few times and see if it holds:

1. The first rule of Kubernetes: start without Kubernetes
2. The first rule of goroutines: start without goroutines
3. The first rule of coding: start without coding

Yeah, that abstraction holds pretty true. Surely there will be cases where it falls flat on its face, though. Can you think of any examples?

In this post, I cover in a step by step manner how to do software estimation for project bids where there is limited clarity and a lot of ambiguity. I cover how we can use an uncertainty factor to cover the unknowns, questions/things to ask/consider at each step of the software estimation process, and some practical advice. This process is based on estimates I have done for multiple projects in the last couple of years.

Trisha Gee writes (because Someone Is Wrong On The Internet):

The problem is not that we shouldn’t write readable code. Of course we should aim to write readable code, if only for our own poor selves further down the line (there is no one less capable of reading my code the following week than me). The problem is that these two issues are not mutually exclusive. It’s not “write readable code” or “learn to read code”. That’s like saying, “I’m going to drive really economically so I don’t need to put petrol in the car”. No. You’re still going to need to put fuel in the car (if it’s not electric!) at some point no matter how economically you drive.

She writes a lot more than just that (of course) and even gave a talk about it, which is also worth digesting.

In this article, three experts discuss some of the key findings of the State of Technical Debt 2021 report including the impact of technical debt on engineering teams, the pros and cons of dealing with maintenance work continuously, the future of technical debt, and what each engineering teams can do to communicate the importance of dealing with technical debt to leadership.

Remember, not all tech debt is bad, but even good tech debt has its ramifications. Solid insights here.

Chris Coyier on some of the new(ish) CSS compilers (such as Assembler) and how they’re flipping the script:

The popular Tailwind framework supports it. It kind of flips the mental model of Tailwind on its head, to me. Rather than providing a huge pile of CSS utility classes to use — then “purging” what is unused — it only creates what it needs to begin with.

Building software is difficult and time consuming, but the maintenance of software is where we spend the majority of our time. In this episode, Ian and sam join Johnny and Kris to discuss how to build actually maintainable software, the features of Go that make it good for writing maintainable software, and different ways that we might define the term “maintenance”.

You gently face-palm and let out a groan. Your bug is so obvious now. How did you miss it before? Thank goodness you didn’t blame Bob publicly.

In this blog post we will look at how to get unstuck with things you do not understand (yet). It’s a methodical approach to solving insight problems - problems where all the information is known but you need to see it a different light to solve it. We start from writing down the problem and move through increasingly more esoteric phases such as changing location to invite insight in.

To build or to buy, that’s a constant question we ask ourselves as software engineers. In this episode we dig into the nuance of these options and the space between them with an eye toward both the building of software and its eventual maintenance.

On this week’s episode, Gerhard is joined by Kathy Korevec, former Senior Director of Product at GitHub, and now Vercel’s Head of Product. Docs play an essential role in GitHub Actions, and Gerhard’s experience has proven that. Building, testing, and shipping code with GitHub Actions works better because of their excellent docs. However, the docs that Kathy pictures are not what you are imagining. She explains it best in her post, Maybe it’s time we re-think docs, which is what started this whole conversation.

The bottom line is, just as you wouldn’t ship untested code, shipping code without documentation is not optional. Today’s conversation with Kathy explains why.

This week Gerhard is joined by Justin Searls, Test Double co-founder and CTO. Also a 🐞 magnet. They talk about how to deal with the pressure of shipping faster, why you should optimize for smoothness not speed, and why focusing on consistency is key. Understanding the real why behind what you do is also important. There’s a lot more to it, as its a nuanced and complex discussion, and well worth your time.

Expect a decade of learnings compressed into one hour, as well as disagreements on some ops and infrastructure topics — all good fun. In the show notes, you will find Gerhard’s favorite conference talks Justin gave a few years back.