On Being (Mostly) Analog

(Mostly) Eschewing from the digital world

Says the guy using a digital platform to write his blog posts…

Well, that’s why I said, “Mostly.”

This post was inspired by Using a logbook to improve your programming.

Partly inspired by When we only hire the best means we only hire the trendiest.

I always found myself thinking, “Why does everything have to move so fast?” I’m pretty sure many of you have as well.

I’ve always struggled with fast moving things. I like taking things slowly, especially when I’m learning something new. But I’ve always felt the pressure to “keep up with the market.” Sure, give me something new and I can “learn” it quickly to implement something relatively simple but I have always felt uncomfortable having this weak foundation around said thing. So, I spend some time later on to try to give myself a stronger foundation so I can tuck away this new thing into my toolbox instead of it being a one-off.

If you have kept up with my posts (I won’t be offended if you haven't), you’ll notice a theme. I keep talking about foundations and how mine are weak especially in the computer science/software engineering field. In addition, one of the reasons I am blogging is to hold myself accountable to strengthening my foundations.

I know it sounds strange being in the software/tech world, that I try to eschew from the digital world but I’m not all about being “trendy.” I like having strong foundations such that I can be flexible to trends but not have to pigeonhole myself on one trend so that the next day when a new trend comes out, I’m already outdated. So, if I’m not going to be trendy, then I’ll need to have strong foundations to show I can be trendy (or traditional, or quirky, or anything). I do this by being as analog as possible.

Good ole pen and paper and highlighters and whiteboards and books and tiny notepads. I’m pretty sure I lost a lot of you at the previous sentence.

I used to take notes on my laptop in school and then like many of you, probably barely peeped back at those notes later on unless it was for some test. I actually fooled myself into thinking that I had learned the material. What’s worse was that when programming, I didn’t use many comments (a programmer’s taboo that most programmers commit every hour) so when I would go back to my code, I had no earthly idea why the hell I did certain things or worse, not understand my own code.

I like painting roadmaps from thought to thought. So, I don’t just take notes linearly, I like to draw circles around ideas and connect them with arrows and stuff. The notes look like a train-wreck after I’m done with the first draft but that’s why I always rewrite them and store them digitally.

I started doing this at the end of college and I am probably not going back. It has been studied that people who take notes traditionally remembered more and have a deeper understanding of the material. I had stopped doing once I entered the workforce because as I said above, I felt the pressure to “keep up with the market. Writing things down is slower than just typing something out but I truly wasn’t learning on the previous team. I just became a parrot. Indeed this looks like how the general market is in software engineering. We have eschewed understanding for “Googling.” I mean, most of the answers are found on Stackoverflow. I didn’t study this field to become a good “Googler.” That’s not to say I don’t read blogs. I definitely do but I deploy the same method as below.

So, after I switched teams two months ago, I started taking handwritten notes on my learnings and about the product we service. It has been a boon for my understanding. I know that, even if I am slower in the beginning, it becomes a lot easier for me later on to connect more dots and faster.

So, that brings me to books, specifically those that are not of the fiction, fantasy, or the like genres. I try as much as possible to get the physical book. This is more expensive but I can afford to sacrifice a few extra bucks so I can have the physical book in front of me. There’s also always the library.

If I own the book, I mark it up and highlight as much as makes sense. If I don’t own the book, I have a notepad/pieces of paper and a pen right next to the book to start taking notes on the passage. I try not to read books I don’t own on my commute since it’s very difficult to write on a notepad on a very crowded train car. I tried Post-It Notes for a bit where I would just take one from my pocket, put it on the passage and write a small note to myself. In the end, I decided to just read those books when I am at my desk.

Edgar Allen Poe once said,

“Marking a book is literally an experience of your differences or agreements with the author. It is the highest respect you can pay him.”

So, when I read a book, I take notes in the margins usually asking questions or jotting down thoughts on specific passages. I also highlight impactful passages. At the end of each book, I run through the book again, transcribing my notes to paper. I actually don’t transcribe all of them. I generally summarize the notes and highlights. Once I am done with that process, I transfer the written notes digitally. This way, I don’t have to reread the book again unless necessary. I also don’t have to worry about losing paper, and if I need a reference to the book, I can easily search the digital version of my notes.

I recently just finished reading How to Read a Book by Mortimer Adler and it has solidified my opinion on being analog. Yes, I understand this book was written in the 40s but I’ve really not found a better option for me to battle against the “move fast era.” I think this mindset of moving fast is quite toxic on creativity and learning.

This brings me to programming and programming books. I generally do the same things in programming books as I do with the nonfiction books but I actually do write out pseudocode first before I get into the real coding. Yes, I handwrite parts of my programs first. In James Routley’s post, he describes the logbook method:

“To use a logbook successfully, you have to:

1. Consider the problem you’re attempting to solve

2. Describe your method for solving it

3. Describe the process of carrying out the method

4. Record what happened, and ask how it could be improved”

He further describes the benefits of logbooking (yes, I just turned that word into a verb):

“1. It provides a framework for solving hard problems by encouraging you to break them down into a series of smaller ones.

2. It helps you focus on the task at hand by providing immediate context on what you’re doing. If you forget or become distracted, you can quickly get back to your train of thought.

3. It helps you learn quickly. You can observe your method for problem solving, see what works and what doesn’t and make improvements.”

Routley does this method in a series of markdown files (something I also do, especially when I am lazy). However, I do try to write down as much as possible and do my little method of circling ideas and connecting them and then writing out design and psuedocode.

This brings me to when I’m on the go. Sometimes I get some ideas while I’m walking around. Sometimes I even solve a part of a problem that I stepped away from. I have a small notepad (usually Field Notes) with a pen in my pocket. I quickly jot down whatever I need to, think about it for a bit, and place the items back in my pocket so I can further inspect when I get home or to a chair/desk. I try to keep my phone use to a minimum. When I’m out, I like to actually engage in meaningful, uninterrupted conversation. I don’t like the superficiality that has come from our conversations. I understand sometimes we need to look at our phones because we are on call for some reason but not all the time. I will abstain from the discussion of phone use for another post.

For many of the reasons above, I also do analog photography, but for the sake of brevity, I will leave that to another post and not put it on Hacker Noon.

In conclusion, I believe in a world that is moving very fast, we need to slow it down a notch; not try to catch up all the time. I believe we can achieve that by being more analog. With slowing things down, we can establish deeper connections to our learning and creativity, and even our interpersonal communications.

Resources

• Scientific American — A Learning Secret: Don’t Take Notes with a Laptop
• How to Read a Book by Mortimer Adler
• Using a logbook to improve your programming by James Routley
• When we only hire the best means we only hire the trendiest