Bricolage 001

Hello friend,

When I started this Soulful Computing newsletter project, I promised myself that I would prioritize consistent publication. I'll send out a newsletter every week, no matter what. People talk about a productivity technique called "don't break the chain." It's often misattributed to the comedian, Jerry Seinfeld. From the doist blog:

The productivity method commits you to completing a daily goal for an extended period of time. Each day that you complete your daily goal, you add an "x" to a calendar. Eventually, you build a chain of x's that extends days, weeks, or months. This streak of accomplishments is increasingly rewarding and dissuades you from breaking the chain. Eventually you're able to build a long-term habit like daily journaling or morning stretching.

I don't want to break the weekly chain. So, you should expect an email from me every Thursday. Consider it a zeitgeber.

At some point, I'll reevaluate whether or not I'm still enjoying writing these, but I'm going to show up for this until then. I want to improve my writing. To do that, I need to put in the repetitions.

However, if I'm to make writing Soulful Computing a sustainable habit, then I have to think about tactics that will help me deliver a newsletter even when I'm under time constraints imposed by the rest of my life. At the very least, there will be some weeks where I'm not feeling especially creative or just tapped out.

For instance, I've recently been participating in an online course at about writing micro-textbooks. From the course description:

A micro-textbook is a substantial work of instructional writing. It's bigger than a tutorial, but much smaller than an actual textbook. On the low end, it could be about 2000 words, and on the high end could get up to about 20,000.

By the end of October, I will have written a little book (about deploying digital signage and media players in museums), and I'm now generating lots of words for the book chapters in earnest. The micro-textbook endeavor is taking up a lot of my daily writing time and mental energy.

I made a plan for weeks like this, where an extended essay on a single theme is a bit out of reach for me. Every once in a while, I will publish a much shorter, skimmable (but hopefully still surprising and joyful) email.

These smaller newsletters will contain one or two quick thoughts and links about Soulful Computing that I may have found over the past week. Sometimes I'll use this opportunity to provide updates on topics covered in a prior email. These letters might exist in that taxonomic space somewhere between a Twitter post and a short blog article.

Consider these interstitial episodes a bit of a release valve for us, or perhaps a palette cleanser to let us catch our breaths between the longer essays.

I'm calling these interludes "Bricolage."

bri·co·lage noun

  1. a construction made of whatever materials are at hand; something created from a variety of available things.
  2. (in literature) a piece created from diverse resources.
  3. (in art) a piece of makeshift handiwork.
  4. the use of multiple, diverse research methods.

Bricolage, in theory, should take less time for me to research and produce; they'll be a byproduct of what I'm reading and thinking about, pulled together over a week as I'm voyaging online. However, if I'm honest, I don't want to write just a "curated links" newsletter. For me, this exercise is about the art of storytelling and not necessarily about just delivering a list of links.

I've considered reducing the frequency of publication to give me more time to develop the essays. It may be the right approach long term, but for now, I need the weekly self-imposed deadline as a motivational tool.

All this to say, it should be evident that I'm playing around with style and approach every week. I'll probably start experimenting with cadence and pacing, as well.

Would love to hear what you think,

David Nuñez

Spreadsheet Errors

In episode 5 of this newsletter, I wrote a short story, Abandon All Hope ye Who Enter (Data) Here, about a voyage beyond the edge of a spreadsheet

The system is straining under the pressure of a spreadsheet this deep. Every new cell takes longer to render. Nobody anticipated the software would need to support a dive like this, and the laptop fans are screaming in an attempt to give me air. I continue, my every muscle pounding. It feels like someone has set up freeze panes all around me.

In the past week, we learned that almost 16,000 people infected with coronavirus went unreported as part of the United Kingdom tracing program due to the data sets extending beyond an Excel spreadsheet's limits.

Unfortunately, the process produced XLS files—an outdated Excel format that went extinct in 2003—which had a limit of 65,536 rows, rather than the around 1 million-row limit in the more recent XLSX format. With several lines of data per patient, this meant a sheet could only hold 1,400 cases. Further cases just fell off the end.

What do you do when you run out of spreadsheet space? You make more spreadsheets, of course:

Public Health England has worked around the present problem: Serco Test and Trace still takes an Excel 2003-formatted XLS spreadsheet as part of the data pipeline—but the process now uses multiple sheets, so the files don't overflow again.

The underreporting of COVID-19 cases isn't, of course, the first costly spreadsheet error. The European Spreadsheet Risk Interest Group maintains a staggering catalog of spreadsheet horror stories.  One prominent example is the spreadsheet data entry mistake at the London 2012 Olympics, where the organization oversold synchronized swimming events by 40000 seats.

When scientists entered the names of specific human genes into an Excel spreadsheet, the software would use autoformatting to transform those names into dates. For example, Membrane Associated Ring-CH-Type Finger 1 is abbreviated to" MARCH1," which Excel translates into a date, "March 1st." Twenty-seven genes [have been renamed to work around]("symbols that affect data handling and retrieval") these technical constraints. Because of this, the HUGO Gene Nomenclature Committee published guidelines for gene naming, including guidance for "symbols that affect data handling and retrieval."

JP Morgan Chase lost over $6 billion in 2012 because an analyst copied formulas from one spreadsheet to another without checking the math.

Harvard Professors Reinhart and Rogoff published an academic paper, Growth in the Time of Debt that Republican politicians used to justify austerity cuts to promote economic stimulus.  As part of a routine homework assignment, a University of Massachusetts Amherst student, Thomas Herndon discovered severe errors in the Reinhart-Rogoff research due to missing data and other errors in a spreadsheet.


  • Here is a lovely video of a man drawing the "hardest kanji."