Links and Notes - April 23rd 2021
First principles and debugging
Recently, a friend introduced me to the concept of first principles. I had never heard of this until he had mentioned it so I went digging around to find what I could about it. Unfortunately the majority of concrete content that I could find was connected to stories about Elon Musk and little else that didn't just rehash what first principles are.
For some context, first principles thinking is where you take a problem, boil it down to the principles from which no further principles can be derived, and then you solve the problem from there. I think this article does a decent job of explaining it. The concrete example related to Elon Musk is that he looked at space travel costs and said "hang on", went back and calculated rocket building costs from the point of raw materials and decided he could solve the problem much more efficiently. He used "first principles thinking".
The problem with trying to find out more about first principles is that a lot of the conversation suffers from the No True Scotsman fallacy. If you boil a problem down to first principles but fail to solve it correctly, then you haven't used first principles really. If you decided right, there's still a good chance that you'll be told that you used logic. Or lateral thinking. Not first principles. The only area where there's general agreement on the topic is in areas of science such as physics or maths, which is what I believe makes Elon Musk's decisions a poster child of sorts for the concept.
But if we ignore definitions and instead focus on the mental model, some decent insights show up. Take this video of Mick Mountz discussing his robotic solution to warehouse inventory management for example. In the video Mick refers to his thinking process as brainstorming. But the thinking model is roughly the same where he starts thinking of possibilities — a person holding out their hand and receiving the item — instead of limitations, followed by building a new idea from there.
This got me thinking about applying the mental model to debugging. Debugging is a topic I've thought about recently and I've wondered: Is there a way to do it right? Is there a way to avoid inefficiencies and maximise my chance of looking in the right place first? Is there a way to minimise my chance of not falling down a rabbit hole? I think this practice of structured thinking really could help. I just need to think about this a bit more. I think the first goal I'll settle for is not falling into any rabbit holes.
This probably isn't "first principles" though. But then. What is?
A widget to get to the GTD inbox faster
Early this morning I was catching up on my newsletter from Casey Newton. It was a good one. Thought provoking. And that's the problem. Within a few minutes I found myself switching contexts and doing some searches to follow up on my ideas. This is an unfortunate regular occurrence. I wonder, how does one handle not jumping between contexts while still being able to keep track of thoughts to follow up on? For someone following the GTD methodology, the answer is simple: Throw it into the inbox
I'm trying to get used to the idea of throwing things into my GTD inbox. But at this point there's still way too much friction with my process. I need to make it smoother. I could use a piece of paper and pen. But realistically, I don't have a pen and paper on me at all times. Especially when I'm relaxing in bed and reading an article. What I think I need is an Android widget (or an Obsidian plugin). I just need it to be a maximum of two taps away. For this, I do think an Android widget is a better option.
Smart Notes are a reading rate limiter
I've been re-reading Sonke Ahren's How to take smart notes recently. It's my second attempt at reading it. My first ended up with me getting distracted with the GTD methodology — it was mentioned in the book as being similar in workflow. That was one time a distraction worked out really well. Now that I'm fairly accustomed to using the GTD methodology to manage my work, I wanted to go back to trying to following the Zettelkasten method of taking notes of things I read. If you don't want to get the book, there are a couple of articles that do a decent job summarizing it here and here
The book "How to take smart notes" is the go to book today to learn about this. To be honest, I find it frustrating at times that the book doesn't seem to carry a single concrete example of how to apply the method. This is very different from the GTD book by David Allen. In GTD, the book starts out with a lot of fluffy "here's why the thinking is important and here's the benefits of it and here's why you should care". But after a few chapters the book is all business and full of practical examples. I still refer to it from time to time when I'm trying to think of better ways to apply some of the tools in the GTD workflow.
How to take smart notes doesn't have that unfortunately. But it is the only resource available on how to create a zettelkasten. It feels like most articles out there are a rehash of the ideas in the book.
Review of the books aside, what's so striking to me is that even though I feel like I've gotten the hang of taking literature notes, it makes the process of reading go so much slower. I find myself going through the following cycle:
- Read a paragraph or a logically complete section
- Decide if there were any ideas that I care about in there
- If there is, ask myself what the idea is in my own words
- Sometimes I'll re-read if I find I can't translate the section into my own words fully
- Write it down quickly
- Maybe add a few quick questions that might pop into my head while putting down the note.
It isn't hard to see how this can have a dramatic impact on reading time. Right there, this slower reading results in me being able to read less by default. But that's not it either. If I'm really committing to it, I'll find myself making other fleeting notes even while browsing Twitter. All of this is a natural rate limiter. And it goes even further. At the end of the day, we need to take all our fleeting thoughts for the day, all our literature notes for the day, and convert them into what's called "permanent notes". These are notes that are added to your "database" of well thought out ideas. Some notes might be added as new ideas to the database. Some are added to existing ideas. For example, you might already have a note on how hybrid workplaces, i.e., partially remote workforces, will be impossible. You might read an article about a founder of a company specializing in remote work tools and that founder states that they also believe the same thing. You'd add this bit to the existing permanent note with a bibliographical reference to the article you got it from.
Again, it's time consuming. The more you read, the more you'll need to process to permanent notes. And thus, the smart notes/zettelkasten note taking methods act as a natural rate limiter for consuming information. To adopt this method is to say "no" to a lot of reading.
This blog doesn't have a comment box. But I'd love to hear any thoughts y'all might have. Send them to [email protected]
Previous links and notes (April 22nd)
Next links and notes (April 24th)
Posted on April 23 2021 by Adnan Issadeen