Yesterday, You Said Tomorrow

Table of Contents

"Yesterday, you said tomorrow." Entering the first week of being a full-time graduate assistant, I want to start a more earnest attempt to share more of the experience and the journey. I've always maintained that the journey itself is the worthier part, the ends only a different way to spell "beginning".

Any time I internally commit to doing something, I remember the mildly ridiculous quote from Shia LaBeouf's GreenScreen recording "Yesterday, you said tomorrow". Yesterday, I said tomorrow I would write this post. Today is now tomorrow and here goes.

I am starting my transition from a full-time software developer/site reliability engineer to being a full-time graduate assistant, working towards a PhD. This post is a first in a series of posts where I will attempt to share my research; technical tangents that come along the way; my thoughts and inspirations; and likely many other random topics in between. It's my intention to write and share these fairly regularly. Of course, we'll see how the energy maintains through the weeks.

Inspiration and Conflicts

Let's traverse the path that planted the seed of this post, where it originally came from and where it is now. Finally, there's a bit of a dilemma to be posed that I am not completely certain of the answer.

A lot can be said about each of the below. In introducing them, my summaries likely will not give justice to each. There's a lot to unpack in each of these and the connections may not be as obvious as I claim. I certainly wish I had the time or space to clearly delineate the various connections of points. Instead, I encourage the deep dive into each; perhaps a different and contradictory conclusion will be reached!

Going Write Only

Back in 2015, Joe Nelson posted "Going Write Only". I was only just starting to write blog posts, but I certainly didn't write with any particular frequency. "Going Write Only" was certainly inspiring, but I didn't have the material nor the confidence to share and write that frequently, let alone make a public commitment to that end.

The thesis of the going "write only" resonated, however, since I had similar problems of consumption only, being in a state of "read only": go to work, read HackerNews, check emails, wait, when did it become lunch time? I clearly couldn't articulate my frustration nor had the thought of breaking the cycle and going write only fully awaken within me.

Makers vs Managers

Around this time, 2016, I stumbled into Paul Graham's "Maker's Schedules vs Manager's Schedules" post. At the time of reading, I was poorly balancing both schedules as a lead developer of a small team. Issue triage and team coordination consuming all remaining vestiges of my maker time, I immediately connected with the principle of the article.

However, I failed in attempting any version of execution of the idea. I never had the clout or the gravitas to effectively move meetings to one side of the day. This has continued to be a struggle of mine as I have moved to different roles in different companies.

Deep Work

Several years ago, approximately 2017, a friend and colleague of mine recommended Cal Newport's "Deep Work" to me. I ate it up and again recommended it to anyone who would listen. The arguments against social media and other distractions in life rang true with my own experience. Being on top of emails and other forms of communication already seemed wrong; how can we be deep in thought and be deeply connected to the various conversations that we might be participating. Newport's thesis and my own experience would both answer this question with unequivocal "no". Modality of tasks seems to be a more healthy and appropriate model of working. Work deeply without distraction, focus the limited energy to the problem at hand.

(Laboratory) Notebook Skills

The earliest reference I can find, Notebook Skills was posted to HackerNews in 2017. Dutifully keeping a log of work, notes, results, thoughts would be helpful in the likely event of context switches. Being able to review these notes to reintegrate into the flow would be invaluable. How many times have I been stuck on a problem feeling aimless in my approach, not sure where I left off, unsure what changes were made, when, why they worked, or why they did not?

Switching to Emacs and starting to leverage Org Mode as much as possible, these skills seemed like a very natural extension.

However, I have certainly failed at maintaining this habit. Our patterns and behaviours are dramatically influenced by the amount of friction involved.

Show Your Work

Recently, another colleague loaned me a copy of Austin Kleon's "Steal Like an Arist". A very short book that describes and enumerates steps for investing in your own craft. The craft itself is not material to the discussion, the content can be lifted to any creative endeavor without too much mental gymnastics.

I was caught by the idea of sharing the work, even if it's not complete.

The next book in the series started by "Steal Like an Artist" is "Show Your Work". Naturally, I'm working my way through it (even convinced my colleague whom recommended the first book to purchase the second book). But for the past week or so, I've been stuck thinking about "daily dispatches", posting a blog, a tweet, an email, really anything that someone– anyone– may be interested in. Sharing the progress, snapshots of the creators mind or the project itself if possible. Again, the journey and experience is the worthier part.

Confluence and Insolubility

Most of these articles dovetail or otherwise co-relate to each other in fairly obvious and intuitive ways. It's pretty easy to see parallels and connections between "Going Write Only", Notebook Skills, and "Show Your Work". It's fairly easy to draw connections between "Deep Work" and "Makers Schedules vs Managers Schedules". Conversely, however, it's much less obvious to see the connection between the former set of articles to the latter set.

Clearly, deep work is a necessary ingredient to creating. It's less clear that sharing the work in progress is a necessary component to making great work. How to integrate these two ideas and philosophies has been the underlying root of this post some weeks ago, the issue that begs for resolution.

The only answer that seems to hold water for me is this: by sharing the work in progress, by forcing its digestion into something consumable to others helps (re)organize the information; the information is more thoroughly understood and accessible in our own brain as a result. The final summit of acquiring knowledge is to teach the knowledge gained.

Challenges and Commitments

As this new chapter opens, I want to make the commitment of going "write only"; the commitment to become a disciple of deep work; the commitment of keeping good notes; and the commitment of sharing the process, the knowledge, the tangents, and the thoughts along the journey.

Certainly, here be dragons. There are many challenges to overcome. How best to manage and appropriate time for reading, developing, and writing (not to mention other obligations that don't fit the scope here)? How to maintain balance and energy in the pursuit of the commitments and ultimate goals? How to overcome personal qualities that inhibit and scream out against everything here?

These are not insurmountable hurdles, "Nothing is impossible". Through dedicated and concerted, these challenges can become merely small obstacles which can be easily stepped over.