/Best Practices

[Webinar] Best practices for AI Agent Tool Calling

tl;dr: “Why doesn’t my AI agent call the right tool?” For AI agents that automate work across 3rd-party tools to be adopted, tool calling and tool use accuracy is critical. Join this webinar, where our dev advocate will cover the basics around AI agent tool calling as well as evaluations we ran to uncover optimizing tool calling performance. Register here - you’ll receive the recording and slides afterward, even if you can’t make it.

featured in #594


"A Philosophy of Software Design" vs "Clean Code"

- Robert Martin John Ousterhout tl;dr: The document that features a dialogue between Robert "Uncle Bob" Martin and John Ousterhout discussing their differing software design philosophies. They debate three main topics: method length, comments and test-driven development.

featured in #594


What Is Device Fingerprinting And How Does It Work?

- Zack Proser tl;dr: “Every time a device connects to your server, it broadcasts a wealth of information through its browser. Some of these signals are obvious, while others are subtle technical artifacts of how browsers and hardware work together.” Zack breaks down what servers can see and how to mitigate bad actors. 

featured in #594


What Is Device Fingerprinting And How Does It Work?

- Zack Proser tl;dr: “Every time a device connects to your server, it broadcasts a wealth of information through its browser. Some of these signals are obvious, while others are subtle technical artifacts of how browsers and hardware work together.” Zack breaks down what servers can see and how to mitigate bad actors. 

featured in #592


Patterns For Building Realtime Features

- Zak Knill tl;dr: “These patterns rely on a connection between the client and the server, where the server can notify the client of some data. This connection could be websockets, sse, event-streams, or polling (long or short). The connection just needs to allow the server to send data to the client without the client knowing that there is new data.”

featured in #590


Summarizing Our Recommendations For Software Documentation

- Nicole Tietz-Sokolskaya tl;dr: A software engineer and anthropologist conducted a case study on engineering documentation practices. Their key recommendations include starting with high-level docs, implementing design reviews, considering audience needs, maintaining docs as part of workflow, and documenting test plans. The study involved literature review and engineer interviews, revealing how documentation practices reflect and reinforce company values.

featured in #589


Five Coding Hats

- Patrick Dubroy tl;dr: The article presents five different approaches to coding, symbolized as "hats": (1) Captain’s Hat: methodical, by-the-book. (2) Scrappy Hat: minimal, straight to the point. (3) MacGyver Hat: results-focused, quick-and-dirty. (4) Chef’s Hat: focused on presentation, aesthetics. (5) Teacher’s Hat: emphasizing clarity, communication. Patrick argues there's no single "right way" to code; instead, different situations call for different approaches.

featured in #588


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 #588


How To Write A Good Design Document

- Grant Slatton tl;dr: “Think of a design document like a proof in mathematics. The goal of a proof is to convince the reader that the theorem is true. The goal of a design document is to convince the reader the design is optimal given the situation. The most important person to convince is the author. The act of writing a design document helps to add rigor to what are otherwise vague intuitions. Writing reveals how sloppy your thinking was.”

featured in #587


Don't Make These Feature Flag Mistakes

- Ian Vanagas tl;dr: As I’ll reveal shortly, badly managed flags have caused huge outages, a mountain of tech debt and, on one infamous occasion, almost bankrupted a company. Typically, this happens because: (1) Complexity creates confusion. Embedded and interlinked flags create many potential states that can quickly become untestable and unpredictable. (2) Poor maintainability creates tech debt. Old “zombie” flags get reused in unintended ways, or negatively react with new changes. Ian shares how you can avoid these problems. 

featured in #587