Does "code quality" actually mean anything to a business? It sure can!

How to use feature flags if you don't have feature flags.

Why do we change code? In his book, Working Effectively with Legacy Code, Michael Feathers offers four reasons: Adding a feature Fixing a bug Improving the design Optimizing resource usage I’ve yet to think of a 5th reason. So what? These 4 reasons are the basis for a personal rule when writing code: Each pull request must address only one of these reasons. Mixing concerns in a single PR can lead to all sorts of problems:

If there’s one programming anti-pattern I see repeatedly, that makes everyone’s lives more difficult, it’s this: req, err := http.NewRequest(http.MethodPost, fmt.Sprintf(checkVerifURL, t.cfg.ServiceVerificationSID), strings.NewReader(body.Encode())) if err != nil { t.log.WithError(err).WithField("phone", phone).Error("failed to create request for check code") return err } This is actual code, copied verbatim, from a project I’m consulting on. For those of you who don’t speak Go, let me translate: Create an HTTP request object. If that results in an error, log the error, then return the error to the caller.

This week I started helping a small startup evaluate and streamline their prototype application. Every time I start one of these projects, I’m struck in the face by how many common anti-patterns I see repeated on practically every project. Today I want to talk about the over-use of configuration. Here’s an (anonymized) snippet of the configuration for the application I’m working on (extracted from the docker-compose configuration): - S3_LOCAL_PATH=./static/ - EMAIL_TEMPLATE=.

Are you tired of waiting for your colleagues to review your pull requests? Here are some quick tips to help your PRs filter to the top of the proverbial review queue. Short and sweet — Nobody likes reviewing long PRs. It might not be fair, but ten 10-line pull requests will generally get reviewed faster than a single 100-line pull request. Limit scope — One of the surest ways to confuse someone reading your change set is to mix concerns.

Sometimes a build tool requires version numbers. JavaScript tooling generally requires semantic versions. Go modules also require the use of semantic versioning. This is good, for publicly-used packages. But the overhead of managing the different types of changes indicated by semantic version increments isn’t always needed for internal projects—even when cross-project dependencies are in use. One simple strategy you can employ, in place of strict adeherence to semver, is a rolling compatibility window.

Yesterday I talked about three reasons we use versions in our software. Now I’m going to try to convince you that you may not even need version numbers at all! Or more accurately, that you can just use your version control commit ID as a version number. Why would you even want this? Well, simply put: Managing version numbers can be a pain. In the simplest case, a version number usually corresponds to a tag in a git repository.

Practically every software project must answer one question, regardless of the tech stack it uses, regardless of the team’s size, or which version control system it employs: What versioning scheme should we use? What does it really matter? Well, there are different reasons that the version scheme can matter. Let me offer three broad reasons to care about versions: Marketing — When your product is marketed to humans, it can be useful to have a human-friendly version number.

Yesterday I explained that GitFlow is anti-agile, but what’s the better alternative? Trunk-based development is the core method I advocate. The one-line summary is: A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’*, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. main or master, in Git nomenclature There are a number of variations I use in specific situations, but the core practices of meaningful trunk-based development are:

GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.