/Design

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

Examples Of Great URL Design

- Jim Nielsen tl;dr: Jim discusses the importance of thoughtful URL design, showcasing how URLs can be more than just web addresses. He highlights examples like StackOverflow, where URLs balance computer and human needs by combining a unique identifier with an optional human-readable slug. Jim also mentions Slack's marketing campaign, which cleverly integrated storytelling into URLs. He points out how GitHub and NPM use URLs that map to their domain semantics, providing intuitive navigation and shortcuts for users. 

featured in #583

Designing Data Products

- Kiran Prakash tl;dr: “Working backwards from the end goal is a core principle of software development, and we’ve found it to be highly effective in modelling data products. In this article we'll explore a step-by-step, methodical approach to identifying data products that avoids overdesign while providing just enough clarity for teams to begin implementation.”

featured in #572

Navigating The Scale: How Design Patterns Power LinkedIn’s Infrastructure

- Saira Khanum tl;dr: “We’ve found the Producer-Consumer pattern to be exceptionally effective in reaching these goals. This pattern has been successfully implemented in several of our core infrastructure systems, including the distributed server query system, server console monitoring, and network security monitoring. In this process, we have identified and built general solutions that are repeatable in similar environments, greatly improving engineering efficiency by leveraging proven methodologies.”

featured in #567

Make It Ephemeral: Software Should Decay And Lose Data

- Armin Ronacher tl;dr: “Most software that exists today does not forget. Creating software that remembers is easy, but designing software that deliberately “forgets” is a bit more complex. By “forgetting,” I don't mean losing data because it wasn’t saved or losing it randomly due to bugs. I'm referring to making a deliberate design decision to discard data at a later time. This ability to forget can be an incredibly benefitial property for many applications. Most importantly software that forgets enables different user experiences.”

featured in #563

Examples Of Great URL Design

- Jim Nielsen tl;dr: Jim discusses the importance of thoughtful URL design, showcasing how URLs can be more than just web addresses. He highlights examples like StackOverflow, where URLs balance computer and human needs by combining a unique identifier with an optional human-readable slug. Jim also mentions Slack's marketing campaign, which cleverly integrated storytelling into URLs. He points out how GitHub and NPM use URLs that map to their domain semantics, providing intuitive navigation and shortcuts for users. 

featured in #540

Solving A Math Problem With Planner Programming

- Hillel Wayne tl;dr: “Suppose that at the beginning there is a blank document, and a letter "a" is written in it. In the following steps, only the three functions of "select all", "copy" and "paste" can be used. Find the minimum number of steps to reach at least 100,000 a's. If the target number is not specified, and I want to get the exact amount of a, is there a general formula?”

featured in #530

Ownership

- Saoirse Shipwreckt tl;dr: “This post is meant as an explainer about how substructural type theory can be applied in programming language design. Terms like “substructural type theory” tend to scare and confuse programmers who don’t write Haskell on the weekends, so one thing programming language designers should do when thinking about how they will present their language is invent metaphors, even slightly misleading ones, to help more ordinary programmers understand how their language works. One such term is “ownership.””

featured in #526

Common Design Patterns At Stripe

- Paul Asjes tl;dr: “You might disagree with how the Stripe API is designed, and the design you end up with is likely going to be different than what we use. That’s just fine, since different companies have different use cases. Instead I present here some design patterns that I believe are generic enough to be useful for just about anyone in the API design process.”

featured in #526

Common Design Patterns At Stripe

- Paul Asjes tl;dr: “You might disagree with how the Stripe API is designed, and the design you end up with is likely going to be different than what we use. That’s just fine, since different companies have different use cases. Instead I present here some design patterns that I believe are generic enough to be useful for just about anyone in the API design process.”

featured in #525