First Principles
Hey!
Welcome back to another week of musings.
A few friends from Guatemala visited the city for GDC, and it's always nice to catch up and compare experiences with game developers.
I hope you had an uneventful weekend or some time to rest!
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I discovered that Pebble Watches are back! I have fond memories of tinkering with mine while I was in college.
- I've been hearing more and more about Vibe Coding and decided to try it out with Cursor, which is a fork of VSCode if you're familiar with that UI. Surprisingly, it has worked relatively well, and I've been refactoring my blog using the power of prompts.
Thinking from first principles is one of those phrases that people like to mention constantly, and its value has probably diluted over time.
What first principles?
One argument against first principles is that they could be too abstract to be helpful for the project at hand.
If you wish to make an apple pie from scratch, you must first invent the universe -- Carl Sagan
In other cases, breaking it down might give overconfidence that we understand the problem, only to miss contextual constraints. In other cases, you might need to go up and down the abstraction ladder to find the right frame of reference for the problem.
Other times, I see people bring up first principles when they don't understand the problem or context or if they feel a process might be too convoluted.
How do we apply first principles?
Ok, we found a problem that would benefit from the first principles approach. What now?
First, we should understand the problem and context. What has failed in the past? What has worked to create the current situation? Then, let's apply Chesterton's Fence to the problem.
Let's say we're trying to understand why delivering software is slow for our team.
I would first understand what steps are part of the current process, if there were any attempts to make it faster or easier in the past, why they didn't work, if the team is still working here, and what they think about this. Do we think it's a cultural block?
Once we understand the context, we can start thinking from the first principles: What are the basic steps required to deliver software to production? Are we missing some of them? Do we have more? For example, some manual verification, explicit approval from the management chain, or even things like not releasing on Fridays.
Once we understand the first principle solution, we need to determine the gap, and the contextual solution might be somewhere in the middle. With all the parts understood, we can work and close the gap to the ideal process.
Once we understand where we want to be, we can start making decisions, trade-offs, etc.
Your turn!
Have you thought about problems at work from first principles? Have you tried fixing problems through this approach? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others