A Year Before

At the beginning of the pandemic I decided to start something called a Zettelkasten. My first note is dated March 6, 2020. That’s just about a week before my employer sent out official notice that everyone would be working from home “until further notice“. As of my last day there, we were still working from home.

The motivation for starting this accessory tool, this “second brain”, was mostly in turning out design documents, specifications, proposals, and such for work. I had already spent some time refining and focusing my styles and templates for the usual sorts of documents programmers write. I was struggling with pulling together and organizing the available information effectively, I believe because the organization had information scattered across team silos within the organization and across different places, even within one team. Just a partial list of places includes

  • wiki, in the form of Atlassian’s Confluence
  • git repositories in Atlassian’s Bitbucket
  • tickets in Atlassian’s Jira
  • Slack
  • email
  • my meeting notes (I take a lot of notes, by hand, on paper)
  • corporate internal website
  • various other one-off tools like Trello and documents on the share Microsoft OneDrive.

Notably, there was no use of any Google products, as they were considered a direct competitor.

We had the wiki, but no one really spent any time curating it. Some teams put a lot of great documentation in git repositories on the BitBucket server. The search function for the Wiki was only marginally useful, and BitBucket’s search was effectively useless. I could clone a repo and search it locally pretty easily – even git grep is better than the built-in search function of the server – but searching across repos was another story. Quite a lot of good information was only in various channels (there had to be hundreds of them) in the company Slack server. Many discussions that resulted in important decisions were only in Slack. The best I can say about that is that Slack’s search is better than BitBucket offered, and Slack by nature records who was involved and when. There was also email. Although email definitely took a back seat to Slack for day-to-day work, the communications from corporate levels and with vendors and customers lived there. My solution, a Zettelkasten, allowed me to collect together the important information from all the sources and organize it in personal repository in a way that supported my style of work and ways of thinking.

The term “Zettelkasten” is a German word compound of “Zettel,” note or slip of paper, and “Kasten,” meaning box. Zettelkasten is then “box of notes,” also called a slip box or card index in English. It’s not just a collection, though, the power lies in methods of using the box of notes to connect ideas. It’s meant to be what we think with, not an archive to file memories.

C. Wright Mills wrote about a similar way of intellectual production an appendix, titled “On Intellectual Craftsmanship“ in his 1959 book  The Sociological Imagination. Ted Nelson’s 1965 paper “Complex Information Processing: A File Structure for the Complex, the Changing and the Indeterminate“ describes a “file” structure for similar purposes. That paper helped inspire the World Wide Web, and it has some applicability to how to represent a Zettelkasten.

Of course, I don’t have a physical card catalog full of paper index cards, I have a digital Zettelkasten. It’s a bunch of markdown files and some tools I wrote for managing them. In the intervening 14 months I’ve created 329 notes, or just a little under a note per day. Some days I didn’t create any, some days I created a lot, and some days I just worked on the notes I have, updating and refining them. I’ve refined and expanded my tools to address different aspects of my workflow. I’ve changed the format of my notes, added integration with my Zotero library, and tried out a variety of editors.

What do I put in my Zettelkasten? A least a third are about programming, some of it to help with producing documents like presentations, designs, tutorials, and how-to guides for work, some of it just for keeping up with industry developments. There’s some stuff about productivity, including working with the Zettelkasten itself, as well as writing generally, knowledge-work skills, note-taking, and so forth. There’s some about Zen and spirituality, and some on photography.

For my sabbatical, I’m going to work though Cracking the Coding Interview, using my Zettelkasten to record and capture what I learn. I’m also going to continue to record what I do and see for my sabbatical as a whole, and bring insights here.

The process of building and keeping a Zettelkasten indirectly led me to decide to take this sabbatical. Reading about taking notes and writing led to me to looking into techniques for improving my knowledge work, and being led to read about Deep Work, which led me to Will Larson and his series of questions for someone considering switching jobs or taking a sabbatical.

  • Are you financially secure for at least a year without working?
  • Do you work in a high-density job market, remotely, or are you flexible on where your next job is?
  • Do you interview well?
  • Could you articulate a coherent narrative to someone asking you why you left without a job lined up?
  • Are there folks at your previous company who can provide positive references?

I was able to answer in the affirmative for all those questions. The last question I asked myself is “am I really burnt out enough to make taking time off the best choice for me?”. That was a harder question to answer.

Working through Cracking the Coding Interview will take a while. I’m not sure how long, though. I suspect more than a few weeks, but I’m not setting a firm timeline. I will work on it an hour or so a day, within my usual self-imposed routine, and see how far I get over time. As I progress, the content I add to my Zettelkasten will help me gauge my progress and allow me adjust my rate.

Net Negative Programmer

At more than one job, I’ve worked with programmers whose efforts were consistently flawed enough that others had to spend as much or more effort correcting them. Whatever code they wrote, settings they changed, or documentation they created, it was wrong in some way, and required another programmer to come and correct or revert. Some enhancement they spent three or four hours on meant someone else spending a half day or more to understand and correct. Disclaimer: I was almost certainly in that category at one time or another in my career.

When a programmer’s contributions result in total programmer hours spent with no net improvement or added functionality, they are a drag on the project and a net negative for productivity.

If a project’s code looks like this before the net negative programmer starts:

It looks like this when they have completed their work.

By Cecilia Giménez - https://www.nytimes.com/2012/08/24/world/europe/botched-restoration-of-ecce-homo-fresco-shocks-spain.html, Fair use, https://en.wikipedia.org/w/index.php?curid=54153025

In my individual contributor days, I could only try to find ways to persuade my manager that there was a problem. When I’ve had more senior roles I’ve always preferred to work with a person. I tried to find something that would be interesting and challenging to them that added value to the company. I’m humble enough that I don’t claim to have never been, if not a net negative, somewhat of a drag to a team. I would hope in that situation the team and management would see enough potential to point me in a productive direction.

Sabbatical

Friday, April 30, 2021 was my last day at my employer. This time, rather than waiting to be let go when the project wound down and they had no other place for me, or getting so burnt out and stressed that the company decides I’m no longer wanted, I decided to take a sabbatical. I was inspired by a couple of sources that one, this was a good time to do it, and two, I could do it.

Max Frenzel’s work on disconnecting and deliberate rest inspired me to assess my condition, and look into whether or not I was burnt out or approaching burnout. Spoiler: I was. Frenzel has a book out, by the way, titled Time Off, it’s about learning to slow down and appreciate how leisure is essential. The other inspiration was Will Larson, who mostly came to my attention for his book Staff Engineer, which I bought and love. But more directly, in his blog, Irrational Exuberance, made it clear to me that I needed a change to continue my programming career and take it up another step.

And the Inside Times had their say, too. After a year of sheltering in place, not traveling, not going out to bars or restaurants, and pretty much only leaving the house every couple of weeks to get groceries, I was about to be fully vaccinated. My second Pfizer shot was, as I was planning, scheduled for May 5, and I knew that by Memorial Day I would be as safe as I was going to get until the US finally drags itself out of the pandemic. I didn’t get a summer in 2020, I was determined to have a good summer in 2021.

After quitting, I set up a schedule for myself, based on ideas from Frenzel and other sources, that boils down to doing Deep Work for half a day, in the morning, and spending the rest of the day on, well, rest, as well as taking care of all the little things like chores and errands. It’s a good schedule, it works, but I’ve had trouble sticking to it. I’m writing this post during my morning work time.

TimeActivity
8:00Wake up
8:15Feed Yuli 😻, make coffee
8:30Have coffee while reading daily inspirational text
9:00Meditate for 25 minutes
9:30Study and reading rotating topic list in 25 minute intervals, Pomodoro-style.
Alternate with Yuli playtime, reading for book group
Daily Topic List
Sunday: Spirituality
Monday: Photography
Tuesday: Writing
Wednesday: Productivity
Thursday: General Programming
Friday: IAM
Saturday: wildcard or off
NoonFeed Yuli
12:15Meditate for 25 minutes
13:00Lunch
14:00Unstructured time: nap, exercise, chores, errands, shower, Yuli playtime, journalling
19:00Dinner
21:30Meditate for 25 minutes
22:00Bed
Daily Schedule for May, 2021

Here at the end of May, though, I’m going to launch into the actual task I set for myself in this sabbatical. After a few unsuccessful jobs interviews earlier this year, before I decided to take a sabbatical, I realized that however much I detest the coding part of interviews, I still have to deal with them. Will Larson in his guide to interviewing for staff-plus roles, mentioned the book Cracking the Coding Interview and the companion website. I feel quite a bit more inclined to work through it than spend any time on one of the coding practice sites. Starting June 1 I will modify the above schedule to fix a hour-hour block of two rounds every day, and the rest of my work time I’ll continue with daily the rotating topic list.