Hello!

Welcome to the blog. The traditional reverse-date-oriented feed of essays and such are below, but I've also started working on some material that kinda wants to be gathered together in a non-blog format--more like collections of written resources brought together. So, before wandering through the blog list, maybe you're looking for patterns reimagined or Speaker Tips? Or check out the "Sections" menu above for a list of some of my favorite blog posts over the years. Of course, the Archive has the complete chronological list, most-recent to oldest (2005!). Thanks for reading; at some point, I'll get comments (Disqus) turned on here again, but that's a TODO for now.

Why Writing Matters (to the Technical Professional)

A narrative to go along with my "Busy Developer's Guide to Writing (Prose)" presentation.

11 August 2025

As a software developer in 2025, it is difficult to choose how to spend one's time. New programming languages (Rust, Zig, AssemblyScript, ...), new data storage implementations (NoSQL, NewSQL, multimodel databases, ...), and of course the alluring temptation of "artificial intelligence", all beckon for the developer's time and attention. More importantly, in a world where ChatGPT can toss off an essay on any topic imaginable without requiring any work on your part, why would any intelligent software developer spend a moment's effort on writing prose?

It's a reasonable question, and one that misses three-quarters of the point of writing. Yes, writing is used to communicate, which is in of itself a valuable outcome. Without communication, humans lose their primary advantage over all the other creatures on the planet. Communication is what allows us to erect buildings, advance science, and/or rally to a cause, among other pursuits. Much of written communication comes through informal media, like Slack messages, SMS, or email, and is often used to inform others of temporal items of interest--status messages, PR notifications, and the classic standup what-I-did-yesterday-what-I-will-do-today-any-blockers three-parter. And these are both important and impossible for ChatGPT to provide 1.

As alluded in the previous paragraph, however, writing serves multiple purposes beyond the simpler act of pulling words out of one head into a form that others can consume. Writing serves multiple purposes to the technical professional. The more senior the professional, the more important the ability to write becomes, both on the job and in pursuit of the career. Across literally every company and organization, in every job role and seniority category, no single skill better returns on investment that that of the ability to craft clear and precise prose.

Why Bezos Thought Writing Matters

In June of 2004, Jeff Bezos sent a memo throughout Amazon with the subject title, "No PowerPoint presentations from now on at S-Team."2 In the early days of Amazon, the S-Team would do weekly four-hour meetings that focused on execution on various projects. Each deep dive would begin with the typical oral-presentation-backed-by-PowerPoint-slides by the relevant team, which simply wasn't working. "The format often made it difficult to evaluate the actual progress and prevented the presentations from proceeding as planned. The deep dives were, in short, frustrating, inefficient, and error prone for both the presenter and the audience."3

Seeking a better answer, they latched on to Edward Tufte's "The Cognitive Style of PowerPoint: Pitching Out Corrupts Within", in which he wrote, "As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense, the more damaging the bullet list becomes." This fit the problem they were seeing: their topics were complex, interconnected, requiring plenty of information to explore, yet the PowerPoint linear sequence of slides was not flexible enough, nor was the presenter-led approach. "Besides, the Amazon audience of tightly scheduled, experienced executives was eager to get to the heart of the matter as quickly as possible. They would pepper the presenter with questions and push to get to the punch line, regardless of the flow of slides. Sometimes the questions did not serve to clarify a point or move the presentation along but would instead lead the entire group away from the main argument. Or some questions might be premature and would be answered in a later slide, thus forcing the presenter to go over the same ground twice."4

Despite the heartache and churn the memo caused, they felt they had found a root cause problem: "The real risk with using PowerPoint in the manner we did, however, was the effect it could have on decision-making. A dynamic presenter could lead a group to approve a dismal idea. A poorly organized presentation could confuse people, produce discussion that was rambling and unfocused, and rob good ideas of the serious consideration they deserved. A boring presentation could numb the brain so completely that people tuned out or started checking their email, thereby missing the good idea lurking beneath the droning voice and uninspiring visuals." (Emphasis mine.) 5

Writing as Explanation

Amazon found, as many others have, that moving from PowerPoint to Word as the presentation format forced a deep change in the presentation itself. Ideas would need to be fleshed out more fully, with only the words on the page to carry the weight of the proposal or insight, rather than the force of personality (or relative position in the org chart) of the presenter. This approach is not simpler or easier--in fact, it is much more difficult, on both sides: "... this model imposes duties and expectations upon the audience as well. They must objectively and thoroughly evaluate the idea, not the team or the pitch, and suggest ways to improve it. The work product of the meeting is ultimately a joint effort of the presenter and their audience—thinking that they can all stand behind." 6

Part of this comes from what takes place during a typical presentation. A slide comes up at the front of the room, with the 6 bullet points each with 6 words. By necessity, each bullet point must be short and an incomplete sentence, with much of the content (and all of the nuance) inferred by the reader. Worse, the presenter is often speaking as the audience reads, forcing the audience to choose one or the other media--either they listen to what the presenter has to say, or they read and ignore the presenter's commentary. Compounding the negative impact, the presenter is typically verbally describing the nuanced elements of some or all of the bullet-pointed statements, meaning the audience has now missed exactly the nuanced take on the bullet points. If an audience member spots the nuance, they ask a question about it, requiring the presenter to awkwardly point out that question was already addressed; if they miss the nuance or say nothing, the nuance is never mentioned again. In any event, the nuance itself, not being captured anywhere in the slide, is only available to those who were in the presentation at the time of its presenting. The slide deck, on its own, is missing a crucial dimension that will be lost to time.

In a written narrative, the linear nature of reading requires the author to spend extra time considering the order and flow of the words on the page. The author may (and most often will not) be present when the reader reads, meaning the author must step back and consider how the reader will consume the document: When will they ask the obvious question? Can I move the answer to that question earlier in the narrative to head that question off? Am I presenting the simplest case first, or the most complex? Much of the writing process is, in fact, editing, in order to make sure that the readers are "getting it" the way the author intends. 7

Readers do not want to wade through a 5,000 page novel to understand the quarterly performance numbers, however; brevity matters. Amazon found that six pages, 11-point font, single-spaced, is the right length for a presentation designed to take an hour. Attendees to the presentation enter the room, receive a printed copy of the narrative, and spend the first twenty minutes reading. (Roughly speaking, an average reader fluent in the language can read one page every two or three minutes.) The narrative is free to include additional material, such as charts or graphs or other material, in an appendix, but the mandatory reading material may go no longer than six pages. Any attempts to go beyond that length are summarily rejected. This brevity forces the presentation not only to be consumable within a single hour-long meeting slot, but also the narrative itself to be tightly focused. Many writers throughout history have learned this lesson. 8 (For these same reasons, I set a hard limit on this narrative of 2500 words, excluding the Appendix, despite the Web's obvious lack of "pages" in the publishing sense.)

Writing as Branding

For those who do not (or do not aspire to) work at Amazon, writing still offers clear benefits. In the highly-interconnected World Wide Web, opportunities abound for well-written prose to catch an audience's eye and create positive reaction. Granted, the Web currently contains trillions if not quadrillions of characters, all clamoring for time under our eyeball, and most of it is worthless. This is, however, nothing new--Arthur Schopenhauer, 19th-century German philosopher, recognized the same problem: "In his essays, On Authorship and On Reading, he identified two types of authors: those who write for the sake of the subject, and those who write for the sake of writing (and really, for the sake of making money). Their motivations couldn't be more different. The former write because they are curious and they want to figure something out. They're like a detective, exploring a subject from all sides, trying to come to a deeper understanding. For them the process of writing is how they figure out what they don't know and how they come up with new ideas. The latter because they get paid by the word, not the insight. You can recognize the latter by how they stretch out half-baked thoughts 'to the greatest possible length.' Their writing is evasive, 'lacking in definiteness and clearness.'" 9

This, as an aside, is the primary reason why ChatGPT will, over time, prove to be highly inefficient as a tool for creating effective prose. 10 While it might know facts and figures, because it lacks the ability to reason and understand the underlying ontology or mental model of the subject under discussion, it will never be able to speak in "definiteness and clearness" effectively. In fact, at least to the date of this writing, where it does attempt to speak with such specificity it usually falls victim to hallucination and/or error.

Those who can put forth prose in a manner that is clear, precise, and direct on a given topic will find that their reputation--their "brand", as the marketing-savvy put it--will grow in a positive direction. Moreover, because the prose stands apart from its author, the message and meaning of the narrative will not be diminished regardless of the author's timidity or introvertedness.

Writing as Reasoning

What often comes as a surprise to the new writer is that writing is not just an exercise in dumping thoughts from head to keyboard; Paul Graham put it this way: "A good writer doesn’t just think, and then write down what he thought, as a sort of transcript. A good writer will almost always discover new things in the process of writing." 11 The act of reaching into the brain, exploring what we know about a topic, and transferring it to some communicative medium (such as written, or even spoken, words) causes us to re-examine the material.

Mortimer Adler once said, "The person who says he knows what he thinks but cannot express it usually does not know what he thinks." 12 Consider a hypothetical for a moment: You are asked, without using any reference material, to explain how radio works. If you are like many people, you know that radio is distributed through the air in some sort of invisible "wave" (hence the term, "radiowaves") that can degrade over distance, although AM waves seem to have greater longevity than FM waves, can be interrupted by physical objects such as walls, or by electrical fields such as lightning storms. But the actual act of transforming sound into wave, or wave back into sound, most of us are unclear on how that works. We have a mental model--an abstraction--of how the radio works, and that mental model suffices for most scenarios in post-2000 civilization. But when asked to dive into detail, we quickly discover that our mental model, like most models, is incorrect (yet still useful).

Consider the scenario in which a company seeks to make a significant shift in its operations. Each individual associated with this effort has a mental model of how the effort should proceed. (Or, to be fair, perhaps only some do, and the rest are eager to build such a model based on what those who do tell them.) One individual may be thinking that this is a "software problem" that can be fixed with the proper application of code and databases. Others may think the software is fine, it's a process issue. Others in turn may want to outsource the entire solution. "Whether we realize it or not, mental models help us think at the subconscious level. They shape what we see, what we choose to ignore, and what we miss entirely." 13 Until the models are brought out of the brain and into the world for examination, with some degree of detail, the implicit assumptions resting within a model remain buried, like corporate land mines, waiting until discovery (usually the hard way).

Anecdotally, many programmers have felt this revelatory effect without realizing it: A programmer stares at the bug which has stumped them for the past two hours. They call another developer over to look at the screen, and start to explain the problem. One of two things frequently happens at this point; either the stumped programmer suddenly, mid-explanation, snaps his fingers and says, "Wait! Never mind, I think I got it" and dives back to the keyboard, or the other programmer leans over and says, "Wait, did you mean to have a comma here?" In both cases, the act of explaining the mental model of the bug yielded up an incorrect assumption that was buried in the stumped programmer's mind. Once brought out of the brain, the assumption is spotted and discarded.

Writing something down forces the author to think more clearly, instead of resting on the feeling of having thought clearly.

Conclusion

The degradation of focus in writing is not exclusive to the software industry; liberal arts programs in academia find themselves facing existential questions as well. "The liberal arts, particularly the humanities, are far from thriving on most college and university campuses. Shifting market demands, financially wary stakeholders, and rampant politicization pose an immediate threat to the humanities." 14 Part of what drives this is the incorrect assumption that "learning to code" is the sole necessary focus for success in a technical career. But if coding requires thinking, and thinking is based on incorrect models, then it behooves any "coder" to have a tool in their toolbox that permits--forces, even--them to bring their mental model out, for both collaborative and analytical purposes.

Writing does that.

Appendix

Bibliography

Working Backwards, by Bryar, Carr; ISBN 978-1250267603

The PR-FAQ Framework, by Calbucci; ISBN 979-8991318921

Farnam Street blog; https://fs.blog

Endnotes


  1. Or, perhaps, it is better to say that ChatGPT couldn't really provide without prompting, which would then be unnecessary--the act of getting the prompt out of the standup participant's head and into words is literally the point of the standup, and ChatGPT's participation would at that point be rendered entirely unnecessary.

  2. The S-Team is the senior-most leadership team at Amazon; basically, Jeff Bezos and his direct reports.

  3. Working Backwards, p. 80

  4. Working Backwards, p. 80

  5. Working Backwards, p. 81

  6. Working Backwards, p. 95

  7. In many fiction-writing workshops, when an author puts a particular piece up for review, the author is required to sit in the room with the reviewers, but is required to remain silent while the reviewers discuss. This allows the author to hear the discussion of her work first-hand, but does not allow the author the "crutch" of being able to explain what the readers "should have gotten". It is often simultaneously the most excrutiating and enlightening experiences an author can experience.

  8. A few examples: "I have only made this letter longer because I have not had the time to make it shorter." -- Blaise Pascal (The Provincial Letters, Letter 16, 1657); "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupéry, Airman's Odyssey)

  9. Farnam Street blog, https://fs.blog/schopenhauer-dangers-clickbate/

  10. For the record, no part of this essay was produced by ChatGPT.

  11. Quoted on Farnam Street blog, https://fs.blog/why-write/

  12. Quoted on Farnam Street blog, https://fs.blog/writing-to-think/

  13. The Great Mental Models Vol 1, p. 4

  14. https://manhattan.institute/article/protecting-the-liberal-arts-and-humanities-in-american-higher-education

Book Review: Building A Debugger

A review of the book.

23 May 2025

No Starch Press sent me a copy of Sy Brand's "Building A Debugger", which walks, step by step, through the process of building your own assembly-level, native-executable debugger. It geeks me out in ways I haven't geeked out since... well, since the last low-level geekery book (the ARM assembly book) they sent me.

Synchronous Work, Asynchronous Work

We often talk about teams working "remote" or "in office", but leaving the discussion at that level misses some critical points of analysis--namely, that the real distinction is between "synchronous" and "asynchronous" work.

15 March 2025

tl;dr Over the last two years, we've seen a dramatic policy debate playing out on the feeds of LinkedIn: "WFH (Work From Home) vs RTO (Return to Office)". Nearly everyone has an opinion, and many (if not most) of them are held strongly. Some are held based on data, some on personal preference, and many are based on personal experience. Nearly all of them, however, focus on the wrong part of the debate: it's not really about "WFH vs RTO", but about "async vs sync".

Embrace Change (Not Perfection)

As software engineers, we understand that we can never get it right the first time in our projects. Yet we also spend an exceedingly long time thinking about how to take data in to treat it as perfect--why do we hold these two wildly different beliefs simultaneously?

13 March 2025

tl;dr Ever had one of those situations where you find that some data about your engagement with a company or institution is incorrect, go through the motions to correct it, only to discover it has mysteriously changed back to the original, incorrect, value? The other day I was driving with my wife back from some doctor's appointments and we were talking about some social media friends she has that were complaining about the same. It's the modern take on "tilting at windmills", yet it's so common we just accept it as an everyday part of modern life. It got me thinking about the problem from a software perspective, rather than a human or corporate perspective. And I think we, software developers, are partly to blame for the situation. Incorrect data, it seems, is impossible to correct in any system larger than a single database.

Debts, Tech and Otherwise

While people debate the validity of "tech debt", others are asking, "What other sorts of 'debt' do we have in software development and delivery?"

09 March 2025

tl;dr A colleague of mine, Scott Porad (CTO, VP Engineering) posted on LinkedIn, asking, "What are all the other kinds of debt like tech debt?" He listed out a few, then asked for others to weigh in, and the list grew... kinda long. And interesting. And made me think about the metaphor more deeply.

The Shapes of Data: Tabular

Tabular data is "flat", meaning we have multiple instances of uniformly-shaped entities with no deviations.

05 February 2025

tl;dr One of the "OG" data formats, the tabular data structure, aka "the flat file", is still today a handy and reasonable way of exchanging data in an automatable fashion without significant integration work required. Its shape is ideal for a multitude of data molecules that all share the exact same contents.

The Shapes of Data: Relational

Relationally-shaped data is characterized not by the tables, but by the database-native relationships between data elements, represented by sets and keys.

04 February 2025

tl;dr Relational data is, contrary to popular belief, characterized not by "tables", but by sets and relational variables (also known as "relvars"), and making use of a relational algebra and predicate calculus to make it easier to do set-oriented operations.

The Shapes of Data: Object

Object-shaped data is often characterized by one-way references between clusters of data grouped together by a few key concepts.

03 February 2025

tl;dr Objects, despite being the most common tool form of mainstream programming languages, are often not as well-understood as a data concept as one might think. In an object data model, entities are defined as unions of state and behavior (and behavior is often of much less concern to the data modeler) that in turn can be related to other objects through a variety of mechanisms (type, ownership, association, and so on).

The Shapes of Data: Hierarchical

Document data, more formally known as hierarchical data, is data which coalesces naturally into singular, mostly-standalone entities.

02 February 2025

tl;dr Hierarchically-shaped data is characterized around strictly acyclic data that are arranged in a parent-child relationship, starting from a single well-known root data node. The relationship between nodes is explicit, with the roles of parent and child clearly delineated, but the actual association between parent and child is typically implicit and immutable.

The Shapes of Data: Associative

Key-value, or associative, shaped data is the simplest of the shapes to understand, which makes it both powerful and deeply unuseful.

01 February 2025

tl;dr The shape of data that's associative, or the key-value data store, is a style of single-dimensional, making the key the biggest part of the shape.


Older posts are available in the archive.