A solid pre-flight checklist by PG aficionado Craig Kerstiens. It covers all the essentials: backups, high-availability, logging, statement timeouts & connection pooling.

Design handoffs are inefficient and painful. They cause frustration, friction and a lot of back and forth. Can we avoid them altogether? Of course we can! Let’s see how to do just that.

My opinionated list of four approaches to building websites and web applications. Publicly hosted on the internet, serving HTML, CSS, JavaScript, images, etc over HTTP.

There are more than four ways to build a web app, but the ones Tom covers in-depth in this post are:

1. Hugo Static Sites + Progressive Web Apps
2. Cloudflare Workers
3. Linux Server Singleton
4. Containers on Platform as a Service (PaaS)

Lucas F. Costa:

In this blog post, I’ll elucidate why backlogs exist and why they never shrink. Then, I’ll expound on why they’re useless and harmful. Finally, I’ll demonstrate how one can work without a backlog and explain why it’s much more productive to do so.

I agree whole heartedly with his “why they never shrink” logic, but I’m not willing to say that makes them “useless and harmful.” I’m not sure Lucas even believes that, since his advice of what to do instead at the end of the post boils down to “keep a short backlog.”

Still, I enjoy Lucas’s thought process and you might too. Recommended reading.

Aiming for one ‘big bang’ release is asking for trouble. Continuous improvement is a better route to creating great digital products. In this post, we take you on a thought experiment to prove this out.

Greg Schier from Railway:

The theory goes that if you ship code on Friday you’ll inevitably be working Saturday to fix what you broke. This makes logical sense; software is messy and mistakes are unavoidable.

But no, shipping code on Friday isn’t bad. At least, it doesn’t have to be.

The key to their success is confidence, which comes from having a solid deployment pipeline and shipping through it often. Gerhard Lazu hit that nail on the head in this short clip as well.

Bryan Braun reflects on years of pairing:

I’ve pair-programmed in a lot of different situations. I’ve been the junior developer who needed to be unblocked. I’ve been the new team member, being onboarded to a new codebase. I’ve paired with peers for knowledge-sharing and productivity. And I’ve been the senior dev.

He goes on to say that it’s easy to put a pairing session on rails to avoid embarrassment, but:

When I think back, my favorite pair-programming sessions were the one where things went wrong. These were the moments that taught me what being a programmer is all about. What do you do when you don’t know what to do? How do you break down a new problem? What tools do you reach for? When do you abandon your current approach? These are things you can’t learn from a blog post.

Robin Linacre:

SQL should be the first option considered for new data engineering work. It’s robust, fast, future-proof and testable. With a bit of care, it’s clear and readable. A new SQL engine - DuckDB - makes SQL competitive with other high performance dataframe libraries, making SQL a good candidate for data of all sizes.

You can make a similar argument for SQL that Gary Bernhardt made for Vim. Here’s Gary on Vim, run your own s/Vim/SQL/g filter on this as you read it:

…just for me, 15 years; at the beginning of that time, TextMate was just becoming popular. Then it was Sublime Text was cool. Then Atom was cool. Then VS Code was cool. A lot of people switched between two of those, three of those, maybe all four of those, and that whole time I was just getting better and better and better at Vim… And you multiply that out by the length of a career, you use Vim for 40 years - you’re gonna be so good at it by the end, and it’s still gonna be totally relevant, I think.

Alex Ewerlöf and his team implemented “Tech Debt Friday”

Engineers looked forward to the Tech Debt Friday. The team would happily remind management that this day cannot (under any circumstances) be planned for regular feature/bugfix work. Although we fixed some bugs along the way, this was primarily an investment to make future feature development cheaper while improving the maintainability and reliability.

Initially it was hard to defend spending 10% of the team bandwidth on tech debt, but over time the payback was huge

He goes on to list eight things that happened as result of this policy. Good stuff.

Scott Antipa:

I’m working on a flowchart editor that runs in the browser, and I wanted a way for people to use it without having to sign in, or store any data on our server. I wanted to give them control over their data and to be able to store it locally to open and edit later. And also easily share it with other people. It’s easy to do this by supporting file upload/download, but I wanted something simpler, like the ability to share by sending a url. I also didn’t want to store anything on the backend (at least for the free tier).

What he decided on was to base64 encode the entire application state and store it in the fragment section of the URL. I love all the upsides of this approach and it’s pretty trivial to accomplish. Here’s the pseudocode that Scott provides in his post:

const stateString = JSON.stringify(appState); // appState is a json object
const compressed = compress(stateString);
const encoded = Base64.encode(compressed);
// Push that `encoded` string to the url
// ... Later, on page load or on undo/redo we read the url and
// do the following
const decoded = Base64.decode(encoded); // same encoded as above, but read from url
const uncompressed = uncompress(decoded);
const newState = JSON.parse(uncompressed);
// Now load your application with the newState

Cedric Chin, writing about the famous adage that says “when a measure becomes a target, it ceases to be a good measure.”

At some level, this is self-evident. Goodhart’s Law is about as pithy and about as practicable as “the only certainty in life is death and taxes” and “hell is other people.” It is descriptive; it tells you of the existence of a phenomenon, but it doesn’t tell you what to do about it or how to solve it.

There are more useful formulations of the law that help solve it. Some organizations use this narrower, more actionable form:

When people are pressured to meet a target value there are three ways they can proceed:

1. They can work to improve the system
2. They can distort the system
3. Or they can distort the data

With that framing in hand, Cedric goes on to describe how you can solve for these three ways and design incentive/measurement systems that work.

A long-standing debate between me and a peer at work has been how we should name services. His position was always that services should be named something descriptive, so that you can infer from the name what it does. My position is that the name should definitely not be descriptive, but should be something cute and wholly disconnected from the purpose. And I think this applies more broadly to projects and companies, too.

Nicholas’ reason for cute names winning comes down to the inevitably of change in a service/project’s function and the difficulty in renaming things. I hadn’t thought of that argument, but I already agreed with the premise.

We also apply this thinking to podcast episode names, which can be a mixed bag because descriptive titles certainly help when it comes to discovery. As Adam and I discussed on our recent State of the “log” episode, if you see use a descriptive title, it’s most likely because we couldn’t think of a good cute/interesting one.

But that’s just our opinion about episode naming. What do you prefer?

Tim McNamara makes an important distinction that is often lost on us:

Agile doesn’t make your team magically speed up its ability to close tickets. Instead, it speeds up the team’s decision-making process. It’s about orientation, not velocity. An agile workflow is one where you are able to quickly adjust direction based on short feedback cycles.

Mat, Natalie & I touched on this when they dragged me on to Go Time last summer to share some thoughts on velocity. Worth a (re)listen if you’re in to such things.

A solid rundown of the discrepency between what we hope from microservices and what we often get instead. TLDR:

Architecture is hard sometimes–people keep offering up some new idea that quickly becomes the mainstream “way to do it” without any context or nuance, and the industry, desperate to find ways to improve their architecture, snaps it up without hesitation. Microservices was the latest in the trend, and it’s time we dissected the idea and got to the real root of what’s going on.

You’ve probably done the whole deleted_at thing to mark records as deleted without actually deleting them from the database. That strategy is fraught for a few reasons.

In this post, Brandur Leach proposes an alternative strategy with the following endorsement:

Speaking from 30,000 feet, programming is all about tradeoffs. However, this is one of those rare places where as far as I can tell the cost/benefit skew is so disproportionate that the common platitude falls flat.

Anytime your fellow developer can make that statement in earnest, whatever they’re talking about is worth a try…

If you operate an SSH server that receives connections from the public, you owe it to yourself to read this list of things you can do to lock that sucker down.

Julia Evans is working on a new zine about debugging, so she took to Mastodon to ask for tips and compiled a list of the best ones (with explainers). Here’s a short list of some tips covered:

• search for the request’s ID
• correlate between different systems
• check that a “suspicious” error is actually new

Andrea Leopardi likens database migrations to git commits and wonders why we don’t leave them in the past and load an up-to-date SQL file instead. He also shares his approach to this in Elixir.

An interesting idea from Gustav Westling…

One of the things that I like to do in my projects, is to make the git history as linear as possible.

Usually this means to rebase commits onto the main branch, but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project.

Today I’m taking this one step further, and I’m introducing a new concept: extremely linear git history.

With our extremely linear history, the first commit in a repo hash a hash that starts with 0000000, the second commit is 0000001, the third is 0000002, and so on!

How he accomplishes this is perhaps even more interesting (and hacky!)

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.

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.

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.