Practices Icon


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


Start all of your commands with a comma

Brandon Rhodes’s solution to conflicts between his ~/bin scripts and system binaries: the humble comma

I heartily recommend this technique to anyone with their own ~/bin/ directory who wants their command names kept clean, tidy, and completely orthogonal to any commands that the future might bring to your system. The approach has worked for me for something like a decade, so you should find it immensely robust. And, finally, it’s just plain fun.


The problem is that your users hate MVPs

Building products is a difficult and time-consuming effort. Figuring out what the problems, finding a potential solution to that problem, and then building that solution all take a decent chunk of time and effort. It’s due to this process that the minimum viable product was born. The motivation for building an MVP is still valid. Build something small and easy to test, launch quickly, and pivot or trash it if it doesn’t perform as desired.

There is another, less selfish way.

I read an article by Jason Cohen a few years ago which changed the way I think about product development. Instead of building MVPs, we should be building SLCs. Something Simple, Loveable, and Complete.

I like the thinking behind SLCs. So simple, so loveable, so…

Hat tip to Henry Snopek for linking this up in the #gotimefm channel of Gophers Slack! When it comes to thinking about your projects, Henry says:

I like to use MVP for fast projects, and SLC for “effective” projects…

Yeah, I like that framing too. So simple, so loveable, so…

Nolan Lawson

The collapse of complex software

Nolan Lawson:

Anyone who’s worked in the tech industry for long enough, especially at larger organizations, has seen it before. A legacy system exists: it’s big, it’s complex, and no one fully understands how it works. Architects are brought in to “fix” the system. They might wheel out a big whiteboard showing a lot of boxes and arrows pointing at other boxes, and inevitably, their solution is… to add more boxes and arrows. Nobody can subtract from the system; everyone just adds.

Nolan posits the center cannot hold and the current market shift from bull to bear might help bring the collapse of complex software. But it’s never that simple, is it?

One thing working in complexity’s favor, though, is that engineers like complexity. Admit it: as much as we complain about other people’s complexity, we love our own. We love sitting around and dreaming up new architectural diagrams that can comfortably sit inside our own heads – it’s only when these diagrams leave our heads, take shape in the real world, and outgrow the size of any one person’s head that the problems begin.


Start test names with “should”

Victor Engmark thinks we should start test names with “should” for a handful of reasons, here’s a few:

  • It removes redundancy, because the function name should already be in the call stack.
  • It is falsifiable, a person reviewing the test can decide to which degree the name agrees with the actual test.
  • It encourages testing one property of the function per test

I don’t disagree, but I like to take it a step further: Let the “should” be implied by the rest of the test name.

Instead of: should replace children when updating instance

I prefer: replaces children when updating instances

Instead of: should apply discount when total cost exceeds 100 dollars

I prefer: applies discount when total cost exceeds 100 dollars

Most of Victor’s reasons for using “should” still apply with this format, but it’s less verbose and more accurately describes the software working as expected when the tests pass.

Marko Milojevic

Two techniques for solving unreproducible (random) bugs

Unreproducible issues, although rare, are typical for each project, sooner or later. They can affect different system parts and make us many causes for investigating and fixing them.

In this article, I try to share some of the techniques I have used in such investigations, which gave me great help in such scenarios. I hope they are helpful to you (if you did not use them already). And, if you have techniques of your own, share them!


Smaller is better (the rise, fall, and rise of flat file software)

Billy Wilcosky:

Flat file web software is about having a set up which doesn’t use a “traditional” database. Instead it uses plain text files, other files, and/or maybe something like a json feed to store the data.

In this post, he explains why he thinks flat file web software is on the come up (again):

Flat file software can be powerful. Depending on what you need. And I think with the right developers and brain power behind the movement it can be more scalable and secure. The sky’s the limit. When I hear a developer saying, no, flat file isn’t good because… really all I’m hearing is they don’t want to change the way web software works. Because what I’ve found is most anything is possible.

Here’s a couple of flat file platforms which are incredible. One is a CMS/blog, the other a forum. Yes, a flat file forum.

A somewhat-related categorical question: Does SQLite count?

Chris Kiehl

The mindless tyranny of 'what if it changes?' as a software design principle

Chris Kiehl hits his hammer right on the head of this common sentiment in software circles:

Developers from certain languages [Java] have learned to wield this design principle with more power than many others. It’s how we end up with so much stuff in code bases that’s just… there. Existing. Superficially it appears unused, but silently and stoically, we know it protects us from the turbulent future change which lurks ever ahead.

The antithesis of one of my favorite design principles: YAGNI

Jerod Santo

Having to maintain your own cleverness 🎧

I had the honor of joining Robby Russell (who you may remember from Oh My Zsh) on his Maintainable podcast for a super-fun discussion on well-maintained software. Here’s how Robby describes it:

Robby has a chat with Jerod Santo, the Managing Editor and Partner of Changelog Media. Jerod helps lead and co-host Changelog’s flagship podcast, The Changelog, and builds all the cool stuff that makes Changelog awesome. Jerod shares his journey from being a typical networking engineer (Infosec) to the experienced programmer that he is today and his programming wisdom from the trenches.

Tune in as he highlights the undeniable importance of automated test suites and code readability, describes the arc of an engineer’s career, and talks about the past experiences that make him lean more towards clarity over cleverness when coding. He also shares some of the things engineers should consider in regard to pulling in third-party code or writing from scratch, and so much more. Enjoy!

Thanks for having me, Robby! 💚

James Simone

The life & death of software

James Simone ponders the relationship between healthy teams and performance in the software world.

Here’s what it comes down to: teams perform well when successes are shared and failures are owned… We don’t celebrate successes enough, and part of that (I think) is caused by the feeling of pressure that comes from working on a project that seems dooomed to fail without meticulous and ever-present attention.

He goes on to delve in to the source(s) of engineering failures, the dangers of “brightsizing”, known predictors for project success, and a bunch of related topics. Lots to ponder here alongside James, who’s seen a lot of software projects live & die during his eight years in the business.


How i fell in love with low-js

Andraž Bajt:

Basic premise is: browsers are great at navigating pages, let’s leverage that by serving users directly with HTML. This already gives you half-decent pages but you can go further and sprinkle on some sugar. A bit of JS. Instead of reinventing the world in JS let’s try to really use what modern browsers provide natively and then push just a bit forward.

Is the pendulum starting to swing away from SPAs/client-side rendering and back toward MPAs/server-side rendering? Will we ever find balance somewhere in the middle?

Shekhar Gulati

Factors to consider when architecting systems that uses third-party systems

In this post, I will talk about important factors you should consider when architecting systems that are powered by third-party systems. The factors I detail are:

  1. deployment model
  2. technology coherence
  3. NFRs and SLAs
  4. Infrastructure and hardware needs
  5. API style and documentation
  6. Idempotent APIs
  7. Getting data out of the third party provider
  8. Community

Martin Heinz

Why and how you should leave Google Analytics

With the recent events relating to Google Analytics platform, it’s becoming very clear that the time has come for many of us to migrate from Google Analytics to different platforms.

In this article we will go over both the “Why?”, so that you can make an informed decision whether you need to migrate of not, as well as the “How?” of migrating from Google Analytics - that is, quickly and easily taking your data and moving to different analytics platform without too much hassle.


How to freaking find great developers by having them read code

Sounds like Jacob Kaplan-Moss isn’t the only hiring manager who’s keen on the reverse code review:

When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice. Because of this, I have found that some methods work better than others to discover talent.

… instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:

The advantages in brief:

  1. Reading probes the most fundamental skills
  2. Reading code is way more efficient than writing.
  3. Reading puts candidates at ease compared to writing code.

Click through for the details and how to put this in to practice.

Nils Norman Haukås

Innovating beyond libraries and frameworks

Nils Norman Haukås:

I have been a big fan of the write libraries, not frameworks argument for a while now. Lately, I’ve come to ponder that there might be a fruitful expansion to this argument, that we should start to value principles over patterns, patterns over libraries, and libraries over frameworks.

I don’t disagree!

The challenge with principles & patterns is they are more difficult to formalize (and communicate) than libraries & frameworks because they’re by nature less specific and more meta (lowercase “m” ftw).

In other words, libraries & frameworks are an end product. Principles & patterns are means to an end. It’s easier to ship a product than to ship the means to it.

The latter is the realm of documentation, education, and conversation.


Why we don't use a staging environment

The Squeaky team goes from dev straight to prod (same here), but many people advocate for (and use) staging or other “pre-live” environments instead.

While there are obvious benefits to deploying to different environments, at Squeaky we’ve decided to take a different approach. We only have two environments: our laptops, and production. Once we merge into the main branch, it will be immediately deployed to production.

Perhaps that sounds unusual, but so far it’s outweighed the benefits of pre-live environments, and we believe it’s helping us to ship faster, and lower the number of issues on production. So, I thought I’d write this post to share why we think it works, and why you should consider it too.

Alexander Lolis

Authorization in a microservices world

Fine-grained authorization in microservices is hard. Definitely not impossible, but hard. You would expect that a more standardized, all-around, full-proof solution is out there, but I am afraid there isn’t. It’s a complex matter and depending on what you are building, implementation varies.

You will probably start with a boolean admin flag in your User model and then you will replace it with a role field, as we all did. However, as things progress and the business model becomes more and more complex, so do the solutions that we need to implement in order to deal with that complexity.

But how do you actually go from a simple flag to Role Based Access Control (RBAC) and then to Attribute Based Access Control (ABAC), especially in a microservices environment? In the following post I hope to help you get there.

Lars Wikman

Fundamentals & deployment

Lars Wikman reacts to Gerhard’s excellent conversation with Kelsey Hightower on Ship It!

So he essentially said, I’m interpreting here, that when it comes to deploying software to servers the documented manual steps for deploying something need to be the canonical reference. Then whether you build bash scripts, Ansible playbooks, Makefiles, Dockerfiles, Terraform, Kubernetes or something else to encode that procedure into something repeatable and scalable that’s a separate step. Having documented the process required to set it up means that there is an answer to the question: How do I get this running? An answer that doesn’t require you to parse the .yml files or grok Ansible roles and groups.

Lars springs forward from there with many thoughts of his own on the matter.

Nicola Lindgren

How do you actually prevent bugs?

It’s not hard to find articles or pieces of research claiming that the sooner you find a bug, the cheaper it is to fix. But I’ve found there isn’t actually a whole lot of information out there on exactly how to prevent bugs in the early stages of a software development project. i.e. before code is written, while requirements/user stories are being written or just after the requirements/user stories have been written.

Here I would like to share exactly how I help prevent bugs on projects and how I help others come up with ideas on how to prevent bugs as well.

Abdulfatai Popoola

When sleeping dogs bite: Unmaintained systems breed disasters

There is a general belief that legacy systems, stale code, and archaic tooling are sleeping dogs – we avoid them fearing a collapse from interference or deprioritize them for seemingly more important projects. I think this strategy of intentional avoidance and/or deprioritization is perfect for disasters.

The challenge with systems that do not fail is that they have no fixes when they eventually fail. Thus, it is more urgent to fix these systems than is usually accepted.


Why you should start self hosting

A short, cogent argument why hosting your own cloud services is worth the time/effort:

Consider this, you carefully curate your playlists on Spotify but every now and then you see a certain song missing from your playlist. Same goes for videos saved in your YouTube playlists or other music/video streaming services. Then there is also the case of OTT streaming platforms where the show you were going to watch over weekend has now disappeared.

The author points to r/selfhosted and this awesome self hosted list as good resources to get started.

Jean Yang

Building for the 99% Developers

Jean Yang:

Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.

As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.

Good stuff to be reminded of. That reminds me: You are not Google/Amazon/LinkedIn.

0:00 / 0:00