Software as Containers.
Published 26 July 2021 at Yours, Kewbish. 1,551 words. Subscribe via RSS.
Introduction
When I was little, I had a thing for lists. Yes, lists - of next year’s required school supplies, of things to bring to summer school, and of groceries that I’d try to optimize a path through the store for whenever I’d tag along shopping. Regardless of the list’s contents, something about its bullet points and orderly collections of information was captivating, and without realizing it, I’d end up structuring my own systems around lists for a while to come1. Even now, most of my notetaking and organization still revolves around list-like methods, though I’ve since drifted from my original requirement for intensely managed structure.
Lists were a way I could distill knowledge down to its core essence, and have it all in one place. Forms of structure and organization like this have become things I value - they drop information I’m interested in into a central location, where I can process them and have an overall picture of everything. Lists serve as containers for information, and easily ordered, edited, and accessed ones at that.
In a way, everything I’ve discussed about lists also relates to certain other organized structures, albeit digital ones. I’ve noticed that I tend towards two specific realms of cyberspace: the Internet, through web development and browsers, and the command-line, with its wealth of terminal user interfaces. In this post, I’d like to think about these platforms as intermediaries for work of all sorts, and explore why I’m so drawn to them.
Containers for Centralization
Web browsers, the terminal, and many apps all aim to be containers: an encompassing solution for their given niche. They’re collections of information, where everything about something in your life can be found. With a web browser environment, for example, that’s likely where you’ll find all of your browsing history, your tabs, and your Wikipedia rabbit holes. Containers range from widely ranging (your computer) to specific applications (consolidating all your social media inboxes into one app, or an all-in-one fitness buddy). Most platforms, I’d say, are striving to be containers - what I want to investigate probably also applies if you architect your life around other systems instead of the web or the command-line, like mobile apps, an e-ink tablet, or plain old paper.
As I discussed in the introduction, containers are nice. I know that if I want to check my calendar, I can trigger a shortcut to open my terminal, where I can see my meetings and todos blocked out. Instead of jumping between a bunch of different apps, one for todos, one for meetings, and an internal one for communications, it’s all in one place. There’s something about containers that makes them so satisfying to use, and so tempting in terms of wholly trusting them with a portion of your life.
The Boxing Principle
I’m not sure if there’s a name for that phenomenon, but I’ll nickname it the boxing principle. It’s the comforting feeling of being able to collect things in one place, and even if it’s at times redundant or not the best place for information, it still feels grounding. It’s the feeling about having the power to draw from a central repository of anything - something I think that’s only become more desired as apps and services become increasingly niche and targeted. And it’s also what I think proponents of platforms like Notion and Roam seek, especially as they characterize their app of choice as the be-all-and-end-all of their productivity needs.
Notion’s premise, right smack on their front page in 74px font, is that they’re the ‘All-in-one workspace’. Users can ‘write, plan, and get organized’ with it, and it’ll be the ‘one tool’. Implied, of course, is the ‘you’ll ever need’ - and if you’re someone who’s filled out entire life dashboards in the app, why would you ever need anything else? For members of the #roamcult, the same follows, and I’m sure everyone’d agree if you switched out the appropriate slogans for the taglines of their apps of choice. These companies actively want you to centralize your life in their products and make use of all of its features, becoming your ‘second brain’, because that’s their business - and to be fair, there’s nothing wrong with that.
I’m not saying the boxing principle or companies that exploit it to entice you into their services are bad. However, I think they’re something to consider as you build your own ’life stack’, or choose the apps that’ll bear the brunt of your digital life. For me, my calendar, notetaking, learning, and (software) development are all terminal-based, and my social media and communications are mainly in the browser. It’d be interesting to build my own set of tools that cover all of these use cases, but for now, I’m trying to keep my tools either easily customizable, or migratable. I’m not worried about Gmail, Discord, or Slack drastically changing - if that happens, I’m sure a more global migration will take place - since I don’t depend on a more customized workflow with those. With my terminal apps, however, they’re all ones that I’ve either heavily configured, built at least partly myself, or decided that fit my needs well. I don’t really see the point of investing so much in a container, and ‘filling it up’, to continue the metaphor, while it doesn’t match the workflow I need.
There’s also the question of if an application for your container is the best fit for the job. Continuing with the Notion / Roam thread, common examples I’ve seen come up when I discuss the topic are things like custom timeblocking views, spaced repetition, and grade calculators. I’ve seen people come up with gorgeous implementations in many different apps, and while there’s the voice in the back of my head going ’they could have just used Google Calendar / Anki / Excel’, I’m suitably impressed. I’m guilty (if this is really something to lay shame to) of this myself. It’s arguably easier to use an existing notetaking app than to rig one that has spaced repetition, linking, search, and more all in Vim - this, I concede. But that’s the draw, and the temptation of existing containers - I have an existing system set up, how difficult can it be to shape it and add new features so I can have everything in one place? It’s a difficult balance, and while I’ll ask myself over and over why I bother to create custom scripts to have things in the terminal or browser, I’m not likely to give up my workflows anytime soon.
Easy Customization
There’s also something to be said for the ability to customize, however. Many apps, including the examples I touched on above (Notion, Roam, and Vim), have infinite, or nearly infinite, ways to add plugins and develop new functionality. With the browser, for example, it’s relatively easy to create your own extension to scrape, manipulate, or connect whatever data across pages as you see fit. I think having the ability to extend and customize itself is almost a core principle of being a container - otherwise, why would people bother investing more into your app if it doesn’t fit their specific use cases?
As well, since containers contain all the information you’d ever need in a specific domain in your life, operating on what’s inside can provide larger insights and innovative ways to work. If a container’s especially large (like a browser or command-line environment), even more can be done to create pipelines and connections. Having these abilities to customize and extend containers is another part of why they’re so attractive. It’s workflow inertia, where people don’t see a point in switching apps or creating a whole new profile if their needs can be addressed with just a couple tweaks or configurations.
Conclusion
I’ve been working on revamping my notetaking system and personal productivity flows recently, so I guess this post is a more in-depth reflection on (and justification of) the choices I’ve made - namely, to stick with a obscure custom-built approach. In the end, it’s my workflow, so there’s no one really to explain or report to, but it’s been nice to expand my ideas on why I’ve stuck to my cobbled-together systems of web extensions and local bash scripts. The containers I’ll use might, and will, change, but I hope the principles of how I use them will stay the same.
Speaking of my notetaking system, I’m very excited about a new addition or two that I’ve managed to work in, mainly centering around linking, searching, and navigating my digital notebook. In typical Kewbish fashion, it consists of misusing an existing tool, as well as some difficult-to-parse regex, so I’m looking forward to creating a writeup on that, also touching on a talk I gave earlier (I’ll discuss both in a bit). I’ve been reading a bit more on the Zettelkasten methodology, and while I’ve changed several key parts of it, I like what I have so far. The system’s likely to adapt and evolve over the next few months, but as with all slightly unnecessary deep-dives on productivity, I’m happy with it.
-
I’m fully aware I sound insanely obsessive over literal lists, but I promise I’m fine, and that this whole introduction is meant to be a segue into the main post. ↩︎