‹ go back

Time in Writing.

Published 16 January 2022 at Yours, Kewbish. 2,886 words. Subscribe via RSS.


Introduction

Over my break between my fall and spring terms of university, I’d been writing a lot - mostly thinking of new article ideas for this blog. I’d finally had more time to read through the huge backlog of interesting articles I’d found for myself, so I spent some time riffing off of concepts that I’d encountered and wanted to discuss. It was very peaceful to be able to sit down, unencumbered by the prospect of having to grind through endless maths problems, and just write. I honestly felt like I did a lot of good thinking over that break - it was like all the noise finally quieted down, and my brain decided to overcompensate for not doing much concrete work by coming up with a lot of thoughts. I decided to transform some of those thoughtchains into articles, and some into personal notes for myself. Bottom line - I spent a lot of time reading, writing, and musing this break: it was very enjoyable, and a good mental rest before I was thrown back into term two.

One of the things that was on my mind near the start of break was, as usual, still schoolwork. After classes let out for exam period, I still had one assignment left: my English paper1. This was something I’d been working on for almost half the term, and was worth a rather significant 25% of our grade. Needless to say, I was stressed about it, even after I’d finally sent it off and started studying for other things. But after the chaos of exams faded away, I was still thinking about some of the pain points I’d experienced while writing that essay, and specifically about the role of time on my writing. I don’t mean time as in the time crunch, though that was certainly fun - I mean how time impacted my the contents of my writing, how my essay went from an outline to an actual paper, and how it changed over that period of time. There were other English assignments for the same class where I followed a similar process - with each piece, I realized just how drastically they’d changed with editing; how they’d changed over time.

There’s a lot of buzzwords surrounding tools for thought, especially those referencing software that claim to bring new mediums for thought, elevating the human consciousness to unlock some magical thinking powers that we didn’t see possible. I’m only joking, but I think there’s opportunities to explore how time is a significant effect on writing and on thought. Building software to be more ‘aware’, in a sense, of time has the potential to drive new innovations in tools for thought.

This post is a collection of a few ideas that I came up with while reflecting on writing my essay, particularly focusing on the role of time, history, and perspective on content and expression.

Semantic Version Control

With writing, I usually like having some way to access the history of my files. With Word, I used to be able to enable some option to be able to access the version history - I think a friend recently mentioned this is somehow built directly into the Office 365 product now. However, I currently use Vim for most of my personal notetaking, and LibreOffice for more formal schoolwork. Both of these softwares have ways that I’m aware of that could enable me to ‘step through’ these files in time, sort of like a literary debugger. Within Vim, I could enable the infinite undo tree and be able to track changes that way. LibreOffice, on the other hand, there’s a single backup that’s on by default, but also a Versions feature that’s somewhat reminiscent of source control like Git. Both of these methods are a bit overkill for me at this point - for my Vim writing, it’s backed up to a Git repo that syncs automatically each day, and I usually don’t update more frequently than that. For my formal schoolwork that I have to write up, I generally just copy paste my main points below any new drafts, or litter my editing with comments that refer back to older versions of the document.

An interesting use case that I found myself thinking about recently is what I’d term semantic version control. Maybe ‘semantic’ isn’t a great description for it, but you’ll see. My guiding question for this whole thing was ‘why isn’t it possible to keep file chunks separated, so I can Ctrl-Z changes in one part of my writing, but not others?’.

My reference model of the typical version control software is the ubiquitous Git. As far as I can tell, it operates on line-based diffs, essentially comparing individual lines within files to see where new chunks have been added or removed2. This works well for most (almost all?) software development, where it’s not logical to have files represent any intermediate states in between code changes. If something is committed, we want it to reflect that update. But for writing, and projects with more semantic nuance, it’s hard to preserve these ‘in-between’ states. For example, let’s say I have three paragraphs, and I’m editing each one. Before I start working, I commit my changes, and when I’m done, I also commit my changes. At the end of my revisions, maybe I’ve decided that I don’t like my changes in paragraph one. Fine - I can revert incremental changes, even in typical VCS like Git (with git checkout -p), but this process is a bit complicated. I’ve only tried this once (with a non-binary file), and managing merge conflicts was a nightmare. Perhaps I did the entire thing completely wrong: we’ll give it the benefit of the doubt. However, where Git starts breaking apart, or at least being very complicated for this workflow, is when you’d be pulling parts of commits all over the commit tree. Maybe you even want to fast-forward a paragraph or two down in the tree and start working off those changes, but how can you apply commits from the future? That’s a rhetorical question - I think with enough git checkouting and git rebase -iing, a system like this’d be possible.

But think of a semantic version control system, where each little atomic piece of writing could be individually manipulated, with its own version history. One way to implement this would be a system where each paragraph (or each sentence, each word, each character, even!) was a unique document, in Git terms. While you could edit the entire thing in one piece, each sub-document, with some arbitrary level of smallest unit, would be able to have its own history and own undo tree. I’m reminded of software like Roam and other block-based note-taking systems, which could ostensibly integrate individual history systems for each block. If I understand their system correctly, RemNote could also do something similar with its ’everything is a Rem’ model.

This ties into the post I previously wrote about metadata - here, the aspect of metadata I’d be looking to enrich is time. As it stands, the most time-related metadata available for most notetaking systems is the date created, and date last updated. History, another facet of metadata involved in the above system, is also usually not very rich. It can’t be manipulated very easily, nor is it intended usually as anything more than a simple worst-case-scenario-only backup system. But in writing, time usually plays a pretty big role, at least in my thought processes. I felt this a lot this past term, especially in some of my writing classes, as I mentioned in the introduction. Sometimes I need to step away from an essay for a couple days, or to keep writing page after page of useless drivel to finally hone down my actual point. With current systems, I’m not able to cherry-pick paragraphs from a couple paper versions ago, or use time, in a way, as best as I could be.

There are trade-offs for this model - a major one would be the insane amount of data storage needed to keep infinite undo trees. Even if the scope was limited to the last couple edits, having each individual atomic block have its own history would add many orders of magnitude of both code complexity and storage required. Power users likely have tens of thousands of blocks - storing diffs that may never be used for each of those is likely unfeasible. But I can dream, and I can come up with slightly shoddy systems to replicate behaviour like this with my current systems. As I mentioned, with LibreOffice, I first work on an outline, then copy that entire outline above itself, and work on drafting that into coherent language. Then, when I edit, I either use Track Changes, or if that gets too messy, just make notes of old sentences that might be useful with comments. It gets a bit messy sometimes3, but it works, and it’s pretty satisfying to finally delete everything right before I hand in an essay.

Recency Bias

In terms of what I write about, one thing I’ve noticed about the role of time is that whenever I write, there’s a strong influence of wanting to write about what’s currently on the top of my head. Over the past few blog posts, I think this’s really manifested - I connect to recent conversations I’ve had with friends more frequently than, let’s say, something I read in a tech book a couple months ago. Maybe that’s to say that the books weren’t as interesting or as memorable as discussing with friends. Regardless, that memorability, or lack thereof, lends itself to a recency bias that tends to show up in what I write about, and what I draw on to support it.

One example of this, bringing it back to the English essay, was the way I chose the angle from which I decided to study it. We’d read several books throughout the term, and I was starting to think about the essay somewhere through finishing the third. That third book happened to be a play adaptation of Mark Haddon’s A Curious Incident of the Dog in the Night-Time. I remember feeling like I really wanted to analyze this play - especially as I’d read it before for other purposes. I think that was the recency bias kicking in, because I eventually settled on a different work, Thi Bui’s The Best We Could Do.. Even though I’d initially planned to study the role of memory in TBWCD, I ended up focusing on the themes of family, which happened to be what we were discussing while reading A Curious Incident. Perhaps this is just a coincidence, and maybe I really did end up analyzing Bui’s depiction of family simply because that was what I found to be the most interesting and held the most potential for a unique reading. I can’t help, however, noticing examples of this throughout the rest of my writing, and wondering if this is one of the strongest effects of time in sharing ideas.

This focus on fresher topics isn’t a problem per se, but I’ve realized one way to combat this recency would be to have a resurfacing mechanism that brought up old thoughts for you to process again. I think this is why systems like the original Zettelkasten, then workflows like Roam’s or Notion’s, hold so much promise and are so frequently used. With bidirectional backlinks and endless possibilities for you to stumble onto an old idea that you’ll see anew, there’s more serendipity at play here to rediscover thoughts. As well, the danger of forgetting ideas that weren’t fleshed out as much is diminished with systems like this. Users can be gently reminded of them in due time, when they explore adjacent subjects. I think this is why so many people feel so attached to their personal knowledge management systems - they offer an assurance that their ideas won’t be relegated to the bottom of the proverbial bucket. Write up a quick synopsis on this or that, link it and/or tag it up, and forget about it until you magically need it again. For me, I don’t use typical PKM software, so I have to do this a bit more manually, but there’s a certain sense of happy chance that happens when I go through old folders in search of something. With my system, I suppose this resurfacing is a lot more active rather than passive, but who knows - maybe that strengthens the ideas’ connections in my own brain.

Editing is Writing

On the other hand, I can also definitely see how time plays a role in editing of my writing as well. Of course, the point of editing is that you can take the literal time to improve your work, and see how it changes over time, but I think time also works to hone your ideas. I’ve talked about my outlining system before, but again, going back to the English essay, I’ve noticed how my ideas significantly changed over time and through editing. At first, I had ideas all over the place - tying in memory, identity, race, culture, second-hand experiences through a very wobbly thesis. When I first tried to edit things down, I blindly picked the subcategory that had the most sub-points and that I thought would be most relevant (second-hand memory) and chopped up my essay to deal with only that. My thesis got no stronger, and my writing was frankly even more messy - there just weren’t that many examples that I could tie into a single overarching statement. But as time went on, as I edited more and pulled in different examples, I somehow had several eureka moments, and I finally realized what it was that I was trying to say.

Part of this comes down to the feeling that sometimes I have an idea, but I can’t express it, and I don’t even know what it is. It took time (a lot of it, might I add) to distill my analysis down to one line of argument. The thing is, all of my examples had been connected by a central theme (family and identity), but without taking loads of time to write and rewrite, I couldn’t come up with the words to put it down, nor the realization of what I actually wanted to write about. When there’s a lot of ideas swirling around in my head, it takes time for me to compartmentalize and learn to actually communicate them. In Ahren’s famous Take Smart Notes, he writes that ‘writing is the thinking’. My version, I guess, is ’editing is the writing’. My point is that throughout coming up with an idea, and refining that idea, there’s always a role of time: of iteration and of interconnection.

Conclusion

I’m happy to say, I did much better on the English essay than I expected, and hey, writing it even sparked a long chain of thoughts about the role of time in writing, which turned into yet more writing! Even as I edit this article, I’m realizing it is itself a result of the recency bias, and that I went through much the same process of turning a messy brain dump into something slightly more coherent while writing it. I think exploring how time shapes ideas, and how it lets them mull and grow and change completely, is an interesting aspect of thought to consider with regards to the whole tools for thought phenomenon.

While, as I mentioned in the arrangement section, most Zettelkasten-like software already brings some backlinking feature, I’d like to see software that plays better with time, history, and resurfacing context. For the semantic version control system I proposed, this might be possible with a very deeply-nested Git-like model. There’re possible applications of NLP in doing better backlinking and idea retrieval, in a more serendipitous way. As well, there might be other possibilities in NLP in summarizing thoughts and suggesting potential ‘what was it that you really wanted to say’, to help users distill their messages. Those are just a few of the posible ways more time-sensitive tools for thought could be built - and I might start looking into proofs-of-concepts for some of these.

I wrote this post while procrastinating on all the work that’s hit with the start of Term 2 here at UBC. It’s been kind of crazy the last week - I feel like through the past 5 days of classes I’ve done the equivalent of 10+ days of break-time work. It’s felt slightly overwhelming - there’s been a lot of information and syllabi and course structures thrown at me at once, but we’ll get through it. I’m enjoying all my classes so far, and all my professors have been super wholesome. We’ll see what this new term brings, but my goal is to reach out more - to friends, to professors, to peers. We’ll see how that goes.


  1. Interestingly enough, all the parts that I thought my TA would criticize for weak analysis were the parts that they liked, and the introduction, something I was pretty happy with, ended up being the main point of commentary. ↩︎

  2. Binary files notwithstanding, which according to the git-diff documentation use something like 64-byte chunks. ↩︎

  3. Cue the essayfinalnomoreeditsv2.docx memes. ↩︎


‹ go back