Return guests Ben Johnson & Chris James join Mat & Kris to talk about the files and folders of your Go projects, big and small. Does the holy grail exist, of the perfect structure to rule them all? Or are we doomed to be figuring this out for the rest of our lives?

I’ve found myself referencing this a couple times recently. Both of those conversations were in the context of React, but the principle applies to every over-adopted technology.

+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.

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.

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.

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.

Jerod is joined by Yehonathan Sharvit, author of Data-Oriented Programming, to discuss the virtues of treating data as a first-class citizen in our applications and the four principles that make it possible.

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.

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.

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.

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.