/Best Practices

Write Change-Resilient Code With Domain Objects

- Amy Fu tl;dr: “Although a product's requirements can change often, its fundamental ideas usually change slowly. This leads to an interesting insight: if we write code that matches the fundamental ideas of the product, it will be more likely to survive future product changes.”

featured in #547

Less Is More: Principles For Simple Comments

- David Bendory tl;dr: (1) Adopt the mindset of someone unfamiliar with the project to ensure simplicity. (2) Use self-contained comments to clearly convey intent without relying on the surrounding code for context. (3) Include only essential information in the comments and leverage external references to reduce cognitive load on the reader. (4) Avoid extensive implementation details in function-level comments.

featured in #543

Speed Up Your App By Caching Database Queries

- Jon Harrell tl;dr: Users demand speed and efficiency. Caching database queries can significantly improve your app's performance. Discover how to use caching to get lightning-fast load times and a smooth user experience for all of your users globally, no matter where your database lives.

featured in #541

How To (And How Not To) Design REST APIs

- Jeff Schnitzer tl;dr: "In my career, I have consumed hundreds of REST APIs and produced dozens. Since I often see the same mistakes repeated in API design, I thought it might be nice to write down a set of best practices. And poke fun at a couple widely-used APIs. Much of this may be "duh", but there might be a few rules you haven't considered yet."

featured in #537

How To (And How Not To) Design REST APIs

- Jeff Schnitzer tl;dr: "In my career, I have consumed hundreds of REST APIs and produced dozens. Since I often see the same mistakes repeated in API design, I thought it might be nice to write down a set of best practices. And poke fun at a couple widely-used APIs. Much of this may be "duh", but there might be a few rules you haven't considered yet."

featured in #536

Parse, Don’t Validate

- Alexis King tl;dr: “Historically, I’ve struggled to find a concise, simple way to explain what it means to practice type-driven design. Too often, when someone asks me “How did you come up with this approach?” I find I can’t give them a satisfying answer. I know it didn’t just come to me in a vision—I have an iterative design process that doesn’t require plucking the “right” approach out of thin air—yet I haven’t been very successful in communicating that process to others.”

featured in #536

In Praise Of Small Pull Requests

- Elliotte Rusty Harold tl;dr: “Prefer small, focused pull requests that do exactly one thing each. Why?” (1) Easier to review (2) Can be reviewed quickly. (3) Easier to figure out exactly where the mistake is. (4) Less likely to conflict with other developers’ work. (5) Saves a lot of work if you made a critical error. (6) Easier to make sure each individual pull request is completely tested.

featured in #533

Formal Methods: Just Good Engineering Practice?

- Marc Brooker tl;dr: “Earlier this week, I did the keynote at TLA+ conf 2024. My message in the keynote was something I have believed to be true for a long time: formal methods are an important part of good software engineering practice. If you’re a software engineer, especially one working on large-scale systems, distributed systems, or critical low-level system, and are not using formal methods as part of your approach, you’re probably wasting time and money.”

featured in #526

Good Code Is Rarely Read

- Alex Molas tl;dr: “Good code is rarely read. Good code is so ergonomic that you almost don’t need to read it; you just use it. It allows developers to focus on building features and solving problems rather than deciphering existing code. This is the ultimate goal of good coding practices: to create code that is so clear and intuitive that it almost disappears, allowing the functionality to shine through.”

featured in #524

Don’t Refactor Like Uncle Bob. Please

tl;dr: The author critiques an example refactoring from "Clean Code" by Robert Martin, arguing that Martin's changes introduce unnecessary complexity and side effects. The original function is split into a stateful class with unclear naming and fragmented logic. The author provides alternative refactorings that aim for simplicity and clarity over dogmatic adherence to certain principles.

featured in #524