Max Mulatz:

This is a call for solidarity and a love letter to good commit messages. Read this to find out why it’s worth to care about commit messages and how to get better at writing them.

Distributed systems are hard. Building a distributed messaging system for these systems to communicate is even harder. In this episode, we unpack some of the challenges of building distributed messaging systems (like NATS), including how Go makes that easy and/or hard as applicable.

This post is part of a sample chapter from Essential Tools and Practices for the Aspiring Software Developer — a self-published in-progress book by Balthazar Rouberol and Etienne Brodu.

I estimate that I spend around 50% of my day working in my text editor and my terminal. Any way I can get more productive in these environments has a direct and measurable impact on my daily productivity as a whole.

If you spend a good chunk of your day repeatedly hitting the left and right arrow keys to navigate in long commands or correct typos, or hitting the up or down arrow keys to navigate your command history, this chapter should help you get more done quicker. We will cover some shell features you can leverage to make your shell do more of the work for you.

On a personal level, I probably use some of these up to 30 times a day, sometimes even without thinking about it, and it gives me a real sense of ownership of my tool.

Everyone knows that all code has bugs. Code is written under constraints. Deadlines. Goals other than quality. Imperfect knowledge of the future. Even your own skill as an engineer is a constraint. If we all tried to write perfect, bugless code, we’d never accomplish anything. So how does it make sense to apologize for bugs?

It’s certainly interesting to ponder how to store data for as long as you possibly can, which Drew highlights very well. But I really enjoyed the questions at the end on “actually storing data forever”…

Let’s say you’ve managed to keep your data around. But will you still know how to interpret that data in the future? Is it in a file format which requires specialized software to use? Will that software still be relevant in the future? Is that software open-source, so you can update it yourself? Will it still compile and run correctly on newer operating systems and hardware? Will the storage medium still be compatible with new computers?

Nicholas C. Zakas asks himself these five questions (in order) to make the best decisions possible:

1. Is this really a problem?
2. Does the problem need to be solved?
3. Does the problem need to be solved now?
4. Does the problem need to be solved by me?
5. Is there a simpler problem I can solve instead?

Read on to find out why these questions have become the basis for his problem solving approach.

What is a microservice, and what is a monolith? What differentiates them? When is a good time for your team to start considering the transition from monolith to microservice? And does using microservices mean you can’t use a monorepo?

Lj Miranda explains their architecture decisions with a metaphor I’ve never seen applied to software systems…

In this blogpost, I’ll explain why we need Flask, Celery, and Redis by sharing my adventures in buying McNuggets from Mcdonalds. Using these three (or technologies similar to them) is integral to web backend development so that we can scale our applications.

I love these “why we did X” style posts where folks share their real-world decision making processes and how they played out over time.

Jonathan Chang and Michael Deng share all the details of the systems required to deploy at Slack.

Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback. We also have hundreds of engineers who are trying to be as productive as possible. Keeping to these values while growing as a company means continual refinement of our deployment system.

Almost every week I accidentally get into this logging argument. Here’s the problem: people tend to log different things and call it a best-practice. And I am not sure why. When I start discussing this with other people I always end up repeating the exact same ideas over and over again.

So. Today I want to criticize the whole logging culture and provide a bunch of alternatives.

In short, I use git branches very rarely, preferring to work on my local master branch almost every time. When I want to work on multiple tasks in the same repository (i.e. often), I just… work on all of them on master. I waste no time creating a new branch, or switching to another branch to change contexts; I just start writing code and committing changes, all directly on master, intermixing different workstreams freely. This reduces my startup time to zero, both for starting new tasks and revisiting old work.

If the blog post ended here, you might think Drew is crazy. But he goes on to explain how he uses rebase to clean things up before pushing upstream.

I enjoy hanging out on master quite a bit, myself. However, when I’m ready to take on something “big” or “gnarly” I don’t hesitate to git checkout -b and work from there.

Jerod and KBall are joined by Micro Frontends in Action author Michael Geers to discuss (you guessed it) micro frontend architecture. We ask: what is the concept? How is it similar/different to micro services? Who is it best fitted for? How do you put it in practice? And much more.

There are many ways to SSH. Some have more security “risks” than others. Yet, we SSH everyday…but could you improve the security of your SSH infrastructure? Maybe. Let’s find out.

Most people can agree that using public key authentication for SSH is generally better than using passwords. Nobody ever types in a private key, so it can’t be keylogged or observed over your shoulder. SSH keys have their own issues, however, some of which we’ve covered in a previous post about SSH key management.

The next level up from SSH keys is SSH certificates. … With SSH certificates, you generate a certificate authority (CA) and then use this to issue and cryptographically sign certificates which can authenticate users to hosts, or hosts to users….

One of the great things about Git is everyone can develop their own branching strategies. One of the terrible things about Git is everyone has to develop their own branching strategies. In this quick post on the Adeva blog, Vedrana Tozija describes a strategy she believes is on point for small teams.

This is a written summary of Katerina Trajchevska’s Laracon 2019 talk on SOLID. Tosho Trajanov says it is a “must-read for every software engineer.” Here’s a primer on the primer:

SOLID is an acronym formed by the names of 5 design principles centered around better code design, maintainability, and extendability.

Dave Cheney talks to us about the Zen of Go (ten engineering values for writing simple, readable, maintainable Go code). What makes code good in Go? What guiding principles should we bear in mind when writing Go?

This is an excellent refactoring story using one of Shopify’s core classes.

As you can imagine, one of the most critical areas in Shopify’s Ruby on Rails codebase is the Shop model. Shop is a hefty class with well over 3000 lines of code, and its responsibilities are numerous. When Shopify was a smaller company with a smaller codebase, Shop’s purpose was clearer: it represented an online store hosted on our platform. Today, Shopify is far more complex, and the business intentions of the Shop model are murkier. It can be described as a God Object: a class that knows and does too much.

They use Martin Fowler’s Strangler Fig pattern to achieve the refactoring. You may recall we discussed this on our episode with Amal Hussein.

What do you do when you’ve determined you can’t refactor your way to greatness? For us, we knew where we needed to be, but the application architecture challenges we were facing seemed to be pointing us towards fully replatforming 😱. We had to get creative…

John Graham:

This article is written form the perspective of a medium sized software company, so not someone with an infinite budget. It talks about the way I started writing engineering road maps, how it helped me sell engineering to our upper management, and how it helped the engineering team deliver results.

The Fyne toolkit provides the easiest way to develop beautiful, lightweight and user friendly native applications for desktop, mobile and beyond. In this post, I describe our design process and why we take a considered approach, moving slower than you might think.

Umer Mansoor’s Technical Debt is Soul-crushing made the rounds last month and he followed up by adding a survey.

117 software developers from all over the world took the survey. The majority were from the USA, followed by Canada, Australia, Germany, India, Russia , UK and other European countries.

Not a huge sample size, by any means, but the results are interesting and worth scrolling through. This pairs nicely with our episode on good tech debt.

Dan Abramov and Dave Thomas got me thinking. Why did DRY come to mean “Don’t cut and paste”? I have a few thoughts on the subject…

When it comes to configuring Kubernetes…

You should use tools such as yq and kustomize to template YAML resources instead of relying on tools that interpolate strings such as Helm.

Dave Cheney’s ten engineering values for writing simple, readable, and maintainable Go code. Some of these apply outside of Go, as well. For instance, Simplicity matters:

Simplicity is not a synonym for unsophisticated. Simple doesn’t mean crude, it means readable and maintainable. When it is possible to choose, defer to the simpler solution.

(Originally presented at GopherCon Israel 2020.)

Jon Thornton (Engineering Manager at Squarespace) joined the show to talk about tech debt by way of his post to the Squarespace engineering blog titled “3 Kinds of Good Tech Debt”. We talked through the concept of “good tech debt,” how to leverage it, how to manage it, who’s in charge of it, how it’s similar to ways we leverage financial debt, and how Squarespace uses tech debt to drive product development.