Practices Icon


Development and business practices, methodologies, workflows, etc.
492 Stories
All Topics


How to be a -10x Engineer

+10x engineers may be mythical, but -10x engineers exist. To become a -10x engineer, simply waste 400 engineering hours per week. Combine the following strategies:

I know the 10x developer is a myth and all, but one thing we don’t talk about very often is that it is sometimes easy to out-pace other devs simply by moving forward at a decent clip.

This is because there are easy (yet non-obvious) ways to make negative progress as a developer. It’s not hard to move orders of magnitude faster than someone who’s headed in the wrong direction.

Tom Hummel

Four ways to build web apps

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 Fernandes da Costa

Why backlogs are useless, why they never shrink, and what to do instead

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.

Ship It! Ship It! #88

Treat ideas like cattle, not pets

In our ops & infra world, we learn to optimise for redundancy, for mean time to recovery and for graceful degradation. We instinctively recognise single points of failure, and try to mitigate the risks associated with them.

For some years now, Daniel Vassallo has been doing the same, but in the context of life & work. Daniel talks about the role of randomness, about learning from small wins & about optimising for a lifestyle that matches your true preferences,. Apparently, ideas too should be treated like cattle, not pets.


Why we ship the most code on Friday

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

The best part of pair programming is when things go wrong

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 your default choice for data engineering pipelines

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

What happened when we invested 10% to pay back tech debt

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.

What happened when we invested 10% to pay back tech debt

Scott Antipa

How to store your app's entire state in the URL

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

Goodhart's Law isn't as useful as you might think

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.


Names should be cute, not descriptive

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

Agile isn't about speed, it's about direction

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.


You want modules, not microservices

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.


An alternative to `deleted_at` for soft record deletion

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…

Ship It! Ship It! #82

Red Hat's approach to SRE

Narayanan Raghavan leads the global SRE organization that runs Red Hat managed cloud services including OpenShift Dedicated, Azure Red Hat Openshift, Red Hat OpenShift Service on AWS, and Red Hat OpenShift Data Science among others across the three major cloud providers: AWS, GCP & Azure. We start with a high-level discussion about DevOps, SRE & platform engineering, and then we dig into SRE specifics, including what it takes to safely roll out updates across many tens of thousands of OpenShift clusters.

Changelog Interviews Changelog Interviews #517

ANTHOLOGY - Wasm, efficient code review & the industrial metaverse

This week we’re back at All Things Open 2022 covering the hallway track. Up first is Shivay Lamba and he’s schooling us on all things server-side WASM. It’s the new hotness. After that, we talk with Yishai Beeri, CTO of LinearB about the world of code review, PR queues, AI developers, and making human developers more efficient, and happier. And last, we talk with Guy Martin from NVIDIA about what’s going on in the Industrial Metaverse. He shares details about an open source project developed by Pixar called Universal Scene Description (USD) and what they’re doing with NVIDIA Omniverse.

Player art
  0:00 / 0:00