/Best Practices

Six Ways To Shoot Yourself In The Foot With Healthchecks

- Phil Booth tl;dr: (1) Aggregate other services into your app’s healthcheck. (2) Set a short timeout on healthcheck requests. (3) Set a long timeout on healthcheck requests. (4) Leave a long delay before starting healthchecks on new instances. (5) Set a low threshold on consecutive failures before turning unhealthy. (6) Set a high threshold on consecutive successes before turning health.

featured in #573

How We Choose Technologies

- Ian Vanagas tl;dr: “Our solution is trust and feedback over process and letting product teams own the process from beginning to end. We can't tell you what technologies to use, or the perfect way to pick them, but this is how our company of ~60, remote and async people does it.”

featured in #568

How To Fork: Best Practices And Guide

- Joaquim Rocha tl;dr: “Over the years, my work did sometimes involve maintaining forks of various open-source projects. That’s not the case with my job now, but when a colleague reached out for help with a fork that hadn’t been rebased in ages, it got me thinking that the steps I follow might be useful for other developers too. Hence this article.”

featured in #560

Writing System Software: Code Comments

- Salvatore Sanfilippo tl;dr: “In this post I analyze Redis comments, trying to categorize them. Along the way I try to show why, in my opinion, writing comments is of paramount importance in order to produce good code, that is maintainable in the long run and understandable by others and by the authors during modifications and debugging activities.”

featured in #560

Responsible Engineering Prevents Costly Failures In A Scaling World

- Dr. Panos Patros tl;dr: Dr. Panos Patros, VP of Engineering at Raygun and a seasoned expert in the engineering field, recently wrote an article about the importance of building robust, scalable software by prioritizing quality. 

featured in #558

An Engineer’s Checklist Of Logging Best Practices

- Rox Williams tl;dr: (1) Structure your logs. (2) Consolidate your logs at creation time. (3) Use unique identifiers. (4) Standardize log field names and types on your structured logs. (5) Avoid logging sensitive data. (6) Treat your logs as data. (7) Use a centralized logging management system. (8) Configure log retention. (9) Set up alerts. (10) Document log formats and practices. 

featured in #558

Use Data That Looks Like Data

- Thorsten Ball tl;dr: “Time for me to pass on something I've been practicing for years but haven't found written down somewhere. It's a simple thing. A practical thing. Forged in the trenches. It won't win any contests in which the audience gasps and says "oh, now that is clever." But it’s easy. Simple even. And it can save a lot of time and tears and, at the end of the day, isn't that some of the best stuff? When debugging or testing your program, do not use data that looks like a variable or type name.”

featured in #557

Responsible Engineering Prevents Costly Failures In A Scaling World

- Dr. Panos Patros tl;dr: Dr. Panos Patros, VP of Engineering at Raygun and a seasoned expert in the engineering field, recently wrote an article about the importance of building robust, scalable software by prioritizing quality. 

featured in #554

The Life-Changing Magic Of Tidying Up Code

- Kent Beck tl;dr: “Tidying up works through a series of small, safe steps. In fact, Rule #1 is If it’s hard, don’t do it. I used to do crossword puzzles at night. If I got stuck and went to sleep, the next night those same clues were often easy. Instead of stressing about the big effects I want to create, I am better off just stopping when I encounter resistance.” Kent shares his approach. 

featured in #551

On Over-Engineering; Finding The Right Balance

- Eliran Turgeman tl;dr: “A big debate among developers is whether to write code for today’s problem or to build a general-purpose solution for future needs. Both approaches have their pros and cons. Specific-purpose code can quickly become messy. But overly general code can add unnecessary complexity. This post, obviously opinionated, argues for a middle ground. That’s the sweet spot, as always.”

featured in #548