Least Common Denominators.

Introduction

A while ago, I finally bit the bullet and picked up a copy of Digital Minimalism at the library. It’s a hugely famous book by Cal Newport, a popular (and for decently good reason) productivity author and CS professor. If you haven’t heard of his philosophies surrounding technology usage and mindful technologism, you might want to go take a look at his work yourself. Digital Minimalism specifically focuses about social media and connecting with others virtually. A quick summary of Digital Minimalism: social media is often used for things that aren’t useful, but ‘could be’ - and that ‘could’ is what hooks us to our devices in spite of ostensibly more productive and meaningful activities. The book centers around how to be more intentional about your digital footprint, media consumption, and online interactions with others.

At a very high level of abstraction, Newport discusses how we can make the tools we use less noisy, and to adapt them to work for us, not the other way around. You might recognize this phrasing, for good reason - it’s often used when discussing tools for thought. That’s what I wish to think about in this article. His philosophy is applicable not only to online connections and the endless maze of pings, but with software as a whole as well. I’ve discussed hyperpersonalized software quite a few times on this blog, but Newport distills many of the ideas that orbit around that sort of artisan-created, artisan-facilitating software. However, while his advice centers around the use of social media and tools, I think there’s a lot to be said about how we can create software in a way that pushes more worthwhile consumption and creation.

But What If?

In the book, Newport discusses a sort of ‘but what if?’ logic that people tried to apply in order to push him towards getting on social media (which he had not, and has not done). He recalls that people often told him that he should consider joining social platforms, and when he asked why, they sort of universally came up with a ‘but what if it’s useful?’, and a ‘I’m sure you’ll discover something on [XYZ] that you’ll find really meaningful’.

I’ve felt this way a lot myself. Two big examples of this that come to mind are Twitter and Notion / Roam / Obsidian. With Twitter, a lot of people in my friend circle’ve hinted at the magical wonders of Twitter, and let me know that I’d likely like it there. This is a bit tricky to unpack, because I know I would find it useful. I really do want to immerse myself in communities of people who are doing things much cooler than what I’m working on, and be inspired¹. On Twitter, there’s a sense of having a space to share my thoughts and ideas with a further group of people that I’d really value. But on the other hand, I have a feeling I’ll be constantly pulled into the discussion there. Right now, I do consume a decent bit of Twitter material with my Nitter setup. It’s sort of like having write lock - I can ‘read’ from these systems fine for now, so I’m trying to wean myself off the feeling I want to contribute directly there too yet. As Newport points out, I don’t know what I’d like to get out of Twitter. There’s a bit of a circular dependency: without having been on the platform, I can’t gauge what value it’d return for me, and so I don’t use it.

The same goes for Notion or other notetaking software. Each system has its own benefits: Notion, its centralizability; Roam, its database and linking model; Obsidian, its file-based focus. With notetaking tools, I feel less of what Newport describes, less of the ‘what-if’ effect. I think it’s because I’ve felt the inertia of wanting to stay with my own systems, and because I’m passionate about and know what I’m doing with my knowledge management workflows, at least for now. Notion, for examples, brings a lot of maintenance and workaround effort - sure, I’ve seen people organize their whole lives in it, but for their aesthetic setups they have to bring in custom icons and lots of layered filters. Could the same thing not be accomplished with separate notetaking, calendar, finance management, and habit apps? This isn’t to say I don’t have the same issues in the terminal, but I feel like I’ve learned to cut down on it and recognize when there are better tools, cutting down on my ‘what-if’ effect.

I recently had a conversation with a friend about Remarkable launchers or something - he was discussing with another friend why they’d want to add a launcher to their tablet. Someone asked him what the point of the launcher was, and what he’d personally used it for. He couldn’t come up with any concrete examples (which is fine), but I jumped in and pointed this out. He was recommending a software without having an actual real use case for it, with the same ‘but what-if’ thinking that seems to be so pervasive when working with software workflows.

Least Common Denominators

All this is to say that these recommendations are definitely valid, but in a different way. In Digital Minimalism, Newport specifically advocates for digging deeper into why you want to use a specific social media platform - for example, he notes a discussion he had with a client who realized he wanted to use Instagram to keep connections going with his childhood friends and see visually what they were up to. But Newport pushed him further, and asked if Instagram was the most productive and efficient way to engender that connection. Text messages and SMS photos would accomplish virtually the same thing, cutting out the distractions and even encouraging more meaningful discussion over thoughtless ’like’ interactions. And though messages were good, an in-person visit would add even more! Newport guided the client to go from what they wanted (connection) to a less distracting and more personable way to achieve the same thing (visits and text messages). This isn’t applicable to all uses of social media and software, but there’s an interesting idea I want to pull out in there.

What if we created software in a way such that we could get to exactly wanted, without all the other distraction and features that aren’t useful to us. I thought of the term least-common-denominator software for this, trying to capture the idea of having the least possible component to do what you wanted while being composable and not having other features that you weren’t interested in. Users can then select the exact feature set that matters to them, instead of having to settle for something that does too many things without optimizing for their own use-case. This form of software would break components and systems down into their least common denominator bits - atomic scripts that can do their job and just that. In my Twitter example, I’d retain some ability to interact with people that I Twitter-simp over, without the noise and addiction and spam that’s also on there. With Notion, I’d be able to have a centralized source of truth database while having multiple views for everything, but also avoiding the performance issues and annoying workarounds people often have to use. There’s got to be some reasonable limit for this granularity and control, but beyond that, why can’t we have more composable systems?

For the developers among you, this’d sort of reflect an extended view of the Unix philosophy applied to modern-day software systems. Do one thing, and do it well: so the Unix philosophy reads. Currently, most software is focused on doing multiple things, and doing them all decently. I hate to rag on Notion so often, but it’s the perfect example - infinite capabilities, but each complicated system requiring many workarounds and hours of setup. Least-common-denominator software would optimize for its one use case and for sending its output to other tools. What I envision is something like the complicated multi-command pipes in bash, with commands passing data back and forth, only with a much better user interface.

Another idea that I’d like to touch on is that least-common-denominator software wouldn’t be like SaaSes or the constantly updating tools we use today. Of course, they’d be maintained, and bug-fixes would pop up when needed, but I think having more atomicized software incentivizes it to be done much more quickly. Nowadays, if a product or tool or library is declared done, with work remaining only for issues and such, people tend to mentally mark it as deprecated and move onto the next shiny thing. But because these atomicized components wouldn’t have a lot of interaction to do, there wouldn’t be an endless backlog of features to work through, nor an increased surface area for bugs to pop up - again, they’d do one thing, and do it well.

I won’t go too far into what this sort of software system would look like, mostly because I haven’t really figured that out. As to what technologies might be used: I’ve mentioned Cambria in a previous post about moving metadata around and translating data between sources. Tools like this to automate and facilitate data manipulation’d likely be a central factor of this type of system, as well as open-source and transparent ways to organize and host data.

Conclusion

Though we can dream, I also don’t realistically think a large-scale shift to this sort of minimal yet composable software’ll get very far. For one, companies will certainly not stick to their core products - each big tech company:tm: has its countless failed / attempted / halfhearted ventures out into side businesses. Why wouldn’t they want to monopolize user’s time, and find new ways to appeal to their software / tool inertia to keep them with their existing software? In Newport’s book, he writes that it’s not very profitable for businesses to reduce their distractions. In this case, it’s not very profitable to keep things minimalist and stop mashing new features into the app. As I’ve mentioned before, standardization and the data processing aspects of these components would also get pretty complicated, and it’s not clear what such a distributed model of software would look like without having a more open culture of software usage, where people can control their own tools and information.

I used to laugh at my friends when they’d talk about whatever apps or whatever aspect of their systems being “bloat”², but I’ve started to appreciate why they’re pointing it out. It’s a pattern (I won’t say problem) that’s pretty widespread across software as we use it today, and I’d like to think that reinventing how we work with tools and software could help change that.

I’m writing this during finals season, in between studying for separate exams and cramming practice papers. (Well, now that I’m editing this conclusion, I’ve got through nearly all of my exams already, but oh well.) I had a weird realization a month and a half before the end of term that it was a month and a half before the end of term, and I started trying to work on my study guides and come up with a plan of attack. I’m glad I started early - I don’t think I properly realized just how much there was to do, nor how much time it’d take to get through all the practice materials I’d want to tackle. I backloaded things weirdly, having a lot of my review and study sessions planned just before finals week started, and now I’m slightly suffering my way through all of it. But lessons learned for next time, and I got through most things fine.

I also recently had my first couple of software engineering intern interviews ever, which was both really exciting and incredibly nerve-wracking. (If anyone working at a company I’m interviewing at right now reads this, I assure you that I’m probably overly enthuastic about the possibilities of working there! I assure you I’m not normally this…rambly about software.) It’s kind of scary that an actual company is considering taking me on to do work for them, and that I could potentially be making a very real impact to products. Things seem to be going well, but the sunk-cost is kind of kicking in, and with every round, I keep getting more and more nervous that they’ll just decide I’m not a good fit and not consider me. But such is life, and I’m looking forward to my next couple rounds. Fingers crossed!