The managerial stereotypes aren’t far off the mark. I hate to admit it, but the vast majority of the time spent managing software engineers—when not synchronously communicating with people in-person—is asynchronously communicating with people through emails and documents. As with coding, I’ve found that familiarity with your software tools1 makes for a world of difference in efficiency; investment in establishing workflows pays for itself in saved time and energy, repurposable for tackling new things.
Underrated as an engineer, then: spreadsheets.
They are programming-lite, or perhaps SQL-lite. It turns out that constructing lists, and lists of lists, and occasionally lists is useful when trying to make sense of data about teams and businesses. In comparison with the more scalable relational database, spreadsheets are much easier to administrate, and they have the huge advantage of being trivially accessible to non-technical folks via basic data entry and WYSIWYG interfaces. The proliferation of Google Sheets has then made it trivial to share these data sets, and has elevated the format to the same level of communicative expression as its memo and presentational counterparts.
Of course, what makes the spreadsheet powerful is its programability. The simplest function is the spreadsheet formula: a cell can reference other cell values in the sheet and perform simple mathematical operations over them, be it
=AVERAGE. And since spreadsheets often manage lists (of lists) of data, its tabular format works nicely in capturing the subsequent lists of output, which then become inputs for further formulae. Well-designed sheets show their work each step along the way and leads the reader through its chain of operations, expressing not only the end result but how it arrived there2.
Taking that to the next level is the full set of formulae that elevates spreadsheets to Turing Completeness—boolean logic operators and conditionals—along with convenience functions around string manipulation, arrays, datetime, and even types. Given this complexity of functions and a lack of common design patterns in computational spreadsheet work, debugging complex spreadsheet calculations can actually be a real challenge.
That said, one under-appreciated aspect of good spreadsheet hygiene is output and cell formatting. That is, there are a number of ways to restrict values and vary the formatting on specific conditions—cells can be programmed to accept a limited set of values3, and outputs can be color-coded based on expected ranges. If you squint a little it starts resembling an informal type system, and can offer many of the same benefits around safety and input validation. Since spreadsheets have an audience that is mostly non-technical, these programmatic features become a lot more visible and can act as powerful guardrails.
Put all of that together, and the humble spreadsheet starts looking like a CRUD app, which is admittedly simple but does solve a large class of business problems. I feel like the recent B2B tooling boom, oriented around spreadsheet-like applications, is a reflection of that utility with an eye towards even better user interfaces and some structure around common workflows.
Though there’s certainly some charm to slinging around your custom spreadsheet instead.
When I was still an engineer, that ended up being vim with specific plugins curated by a couple of Square engineers back in the day.↩
One of the most popular posts on this blog features a financial planning spreadsheet I put together.↩