If your team can't agree on a course of action, conduction a short-term experiment instead.

"It's not operation's job to keep the site stable and fast. Operation's job is to enable the business."

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

In the same way that tools don't make art, tools don't make DevOps.

In this episode of Developers Eating the World, Chris sits down with Johnathan Hall, AKA the Tiny DevOps Guy. Johnathan is a DevOps expert and recently started focusing his efforts on tiny teams with big ideas.

As frequently happens when consulting with small projects and startups, this week I was asked “Should we manage our own service, or use a hosted solution?” My answer is pretty consistently the same: Start with a hosted service, and switch to self-managed only if and when it makes financial sense. This question, and my answer, are generally applicable to all sorts of services: Kubernetes, log search, service monitoring, databases, mail automation, etc.

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:

When you review a pull request, what do you look for? Bugs? Misspelled words? Broken error handling? Missing unit tests? That’s all fine and good. But there’s one aspect of pull request review that I think usually does not get enough attention: Metadata The pull request title and description, as well as the individual commit messages (and each commit’s contents) are all important parts of a pull request, and deserve attention during a review.

It’s almost inevitable that when I participate in a conversation about pull requests and code review, someone suggests pair programming as an alternative. For those unfamiliar: Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

Lately I’ve seen several people reacting against the idea of pull requests, on the basis that pull requests are a mechanism to safeguard against untrusted code. Consider this post from LinkedIn: [Pull requsts are] about distrust. Apparently people don’t trust their team mates to do the right (enough) thing. A similar sentiment can be found in Kief Morris’s article Why your team doesn’t need to use pull requests. I’m willing to accept as granted that pull requests can be useful in low-trust situations, such as vetting code changes from a stranger on the Internet.

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.