NOAH
JACOBS

TABLE OF CONTENTS
2025.02.09-On-Overengineering
2025.02.02-On-Autocomplete
2025.01.26-On-The-Automated-Turkey-Problem
2025.01.19-On-Success-Metrics
2025.01.12-On-Being-the-Best
2025.01.05-On-2024
2024.12.29-On-Dragons-and-Lizards
2024.12.22-On-Being-a-Contrarian
2024.12.15-On-Sticky-Rules
2024.12.08-On-Scarcity-&-Abundance
2024.12.01-On-BirdDog
2024.11.24-On-Focus
2024.11.17-On-The-Curse-of-Dimensionality
2024.11.10-On-Skill-as-Efficiency
2024.11.03-On-Efficiency
2024.10.27-On-Binary-Goals
2024.10.20-On-Commitment
2024.10.13-On-Rules-Vs-Intuition
2024.10.06-On-Binding-Constraints
2024.09.29-On-Restrictive-Rules
2024.09.22-On-Conflicting-Ideas
2024.09.15-On-Vectors
2024.09.08-On-Perfection
2024.09.01-On-Signal-Density
2024.08.25-On-Yapping
2024.08.18-On-Wax-and-Feather-Assumptions
2024.08.11-On-Going-All-In
2024.08.04-On-Abstraction
2024.07.28-On-Naming-a-Company
2024.07.21-On-Coding-in-Tongues
2024.07.14-On-Sufficient-Precision
2024.07.07-On-Rewriting
2024.06.30-On-Hacker-Houses
2024.06.23-On-Knowledge-Graphs
2024.06.16-On-Authority-and-Responsibility
2024.06.09-On-Personal-Websites
2024.06.02-On-Reducing-Complexity
2024.05.26-On-Design-as-Information
2024.05.19-On-UI-UX
2024.05.12-On-Exponential-Learning
2024.05.05-On-School
2024.04.28-On-Product-Development
2024.04.21-On-Communication
2024.04.14-On-Money-Tree-Farming
2024.04.07-On-Capital-Allocation
2024.03.31-On-Optimization
2024.03.24-On-Habit-Trackers
2024.03.17-On-Push-Notifications
2024.03.10-On-Being-Yourself
2024.03.03-On-Biking
2024.02.25-On-Descoping-Uncertainty
2024.02.18-On-Surfing
2024.02.11-On-Risk-Takers
2024.02.04-On-San-Francisco
2024.01.28-On-Big-Numbers
2024.01.21-On-Envy
2024.01.14-On-Value-vs-Price
2024.01.07-On-Running
2023.12.31-On-Thriving-&-Proactivity
2023.12.24-On-Surviving-&-Reactivity
2023.12.17-On-Sacrifices
2023.12.10-On-Suffering
2023.12.03-On-Constraints
2023.11.26-On-Fear-Hope-&-Patience
2023.11.19-On-Being-Light
2023.11.12-On-Hard-work-vs-Entitlement
2023.11.05-On-Cognitive-Dissonance
2023.10.29-On-Poetry
2023.10.22-On-Gut-Instinct
2023.10.15-On-Optionality
2023.10.08-On-Walking
2023.10.01-On-Exceeding-Expectations
2023.09.24-On-Iterative-Hypothesis-Testing
2023.09.17-On-Knowledge-&-Understanding
2023.09.10-On-Selfishness
2023.09.03-On-Friendship
2023.08.27-On-Craftsmanship
2023.08.20-On-Discipline-&-Deep-Work
2023.08.13-On-Community-Building
2023.08.05-On-Decentralized-Bottom-Up-Leadership
2023.07.29-On-Frame-Breaks
2023.07.22-On-Shared-Struggle
2023.07.16-On-Self-Similarity
2023.07.05-On-Experts
2023.07.02-The-Beginning

WRITING

"if you have to wait for it to roar out of you, then wait patiently."

- Charles Bukowski

Writing is one of my oldest skills; I started when I was very young, and have not stopped since. 

Age 13-16 - My first recorded journal entry was at 13 | Continued journaling, on and off.

Ages 17-18 - Started writing a bit more poetry, influenced heavily by Charles Bukwoski | Shockingly, some of my rather lewd poetry was featured at a county wide youth arts type event | Self published my first poetry book .

Age 19 - Self published another poetry book | Self published a short story collection with a narrative woven through it | Wrote a novel in one month; after considerable edits, it was long listed for the DCI Novel Prize, although that’s not that big of a deal, I think that contest was discontinued.

Age 20 - Published the GameStop book I mention on the investing page | Self published an original poetry collection that was dynamically generated based on reader preferences | Also created a collection of public domain poems with some friend’s and I’s mixed in, was also going to publish it with the dynamic generation, but never did.

Age 21 - Started writing letters to our hedge fund investors, see investing.

Age 22 - Started a weekly personal blog | Letters to company Investors, unpublished. 

Age 23 - Coming up on one year anniversary of consecutive weekly blog publications  | Letters to investors, unpublished.

You can use the table of contents to the left or click here to check out my blog posts.

Last Updated 2024.06.10

Join my weekly blog to learn about learning

On Wax and Feather Assumptions

LX

2024.08.18

The problem is not that Icarus flew too close to the sun, but that he used wax and feathers for his wings. 

Subscribe

-------------------

Wax and Feather Assumptions

I listened to a brief Stanley Kubrick speech this week. A quote stood out: 

Jack & I started building BirdDog on July 23rd. Since then, I can’t tell you how many wax and feathers assumptions I’ve made. The number that I’m aware of is nauseatingly high. The number that I’m unaware of must be a multiple of that. 

Regardless, we now have a product that takes only three minutes of human time to add in a new user… I suppose that’s the beauty of software. This is a huge milestone in the sense that we can start to open the floodgates of feedback. 

It is going to be painful; the platform is so far from what we want it to be. However, the best way to see if your wings hold up is to put them under the heat of the sun. For a startup, there is no better sun than users. Not only will they melt bad assumptions, but they’ll also help us focus in on the handful of features that actually matter out in the “real world.” 

All that being said, we didn’t even need any users to interact with the platform for quite a high number of my bad engineering assumptions to be revealed as just that—bad engineering assumptions. 

Bad Assumptions

Assumptions make our model of the world. More scientifically, you might call your assumptions hypotheses. Whatever they are, we use them to guide action.

Assumptions without action is armchair philosophy. Action without assumptions are random (this statement, of course, assumes that everything you “know” is an “assumption”). 

As I wrote about a couple of weeks ago, I started building the BirdDog backend from the top down, rather than bottom up. The first iteration of what I thought the product architecture would look like was this:



Caption: I wanted something that would last “forever.” I got lots of top level complexity unhardened by knowledge of low level implementation details.

If I were to draw a diagram of what our current actual backend looks like, it would be nothing like this. This was full of bad assumptions, the biggest of which being that we needed three databases, as well as tying the architecture to the technicalities of Mongo DB. Still, planning it out was incredibly useful.

By last Monday, the product “worked” & followed a simplified version of the above schematic. When I say worked, there is a huge asterisk. Because of limitations of both the document database I naively chose and the way I had structured our data hierarchy, when we went to scrape a website, we only could fit a fraction of the content we extracted in the database. This is without mentioning a slew of other logical complexities that went into reconciling the information in the DBs. 

When I designed the fun diagram above, there were many very simple variables I did not focus on, such as, you know, the storage capacity of different parts of a database. Which, you know, is kind of like the point of a database. Rather, I was focusing on a bad assumption around read-write permissions that I had wrongfully generalized after heavy exposure to developers using git repos as DBs. 

As a result, my original plan for BirdDog inherited my bad assumptions and naivety.

However, once it became painfully apparent that this was far too complex, I went back on the assumption as quickly as possible and started learning SQL. Three days later, we had a 3NF SQL DB. 3NF is something I only know about because somebody smarter than me brought it up (thank you, anon).

Implementation melted the wax of bad assumptions. 

Other Bad Assumptions

A few other bad assumptions I made, as well as how they evolved:

Quote Extraction

Assumed Implementation: After a model identified that a paragraph from our database contained a valuable quote, we were going to have another model extract those quotes from the passage.

Actual Implementation: We turned the database into a collection of quotes; now, selecting a quote implies extraction.

Separate Pipelines

Assumed Implementation: We started with different pipelines for 1) extracting & embedding info from websites 2) sorting through and extracting quotes from the embeddings.

Actual Implementation: Now, we have one 165 line generalized pipeline, the core of our data processing, complete with multiprocessing and increasingly reliable error handling. More granular functions are arguments. 

Rust Web Crawler

Assumed Implementation: To preempt performance limitations of Python, I spent the first few days building a 500 line rust web crawler.

Actual Implementation:  We switched to Python; by leveraging libraries built by people smarter than us & 92 lines of our own code, not only can we crawl most websites, but we can also robustly extract the relevant text from the html.

Cost of Iteration

When you’re early, the costs of iteration are time and ego.  

BirdDog has spent  $.01 on OAI in August. I expect that if we had 100 users with 200 prospects each, the cost might be $10 a week, likely much lower.



Caption: Pop off, only on occasion, Brother. We are using my personal OAI account for BirdDog. The $.13 came from my website’s usage. The other one cent was from BirdDog.

The cost benefit analysis will get more complex as time goes on and we have paying users and expenses and all of those things, but, right now, the costs are time and ego. I’ve committed all of the former to this and am always trying to conquer the latter.

As of now, our entire code base is 1,177 lines, including the sql schema*. I need to set up GitHub Stats to be sure, but I’d guess that last week, before the big database switch, we peaked out above 2,000 lines. Trading maybe three or four days of time for a code base that’s half the size as it otherwise would be and even more powerful and useful is a trade I would take every time.

The benefit of melting wax and feather assumptions is a more accurate world view. In terms of code, that generally means doing the same thing better with fewer & more clear lines. In terms of life, it can mean a lot of things, most of which are good.

*31% of the code base is the SQL wrapper, which I’m sure is a product of me being a total SQL noob. Learning more about SQL will help me slash that. If there are any books or blogs or videos you like, send them my way. 

Lampson’s Law

An assumption is part of your model for the world. Maybe you believe that with these wax and feather wings, you can fly. The trick to figuring out if you’re right is to ask the world for feedback.

For BirdDog, asking the world is about to be literally asking users. The last few weeks, though, asking the world was seeing if the code would do the things we wanted it to do under different foreseeable conditions.

Many of my assumptions in that regard ended up being quite silly. An experienced engineer would have known that, when asked what it thought about those assumptions, the world’s answer was going to be more negative than positive. As a matter of fact, some experienced engineers did tell me that some of these were not great assumptions. If that was you, thank you; I’m sure that those conversations helped me to know which direction to go when it became apparent that my direction was wrong.

Having tried these things was not a waste of time, though. As a matter of fact, I’ll keep trying things, and I’ll keep being wrong. But, each time, I’ll be closer to right.

In the context of software, I think getting it right means building a tool that provides value to the users in a sustainable way. Sustainable means the value created and captured is ultimately greater than the cost of maintaining it. 

Getting there will require many mistakes and perpetual humility. Sometimes, when I realize that I’ve overcome three or four bad assumptions in a row, I counterintuitively have this momentum and attitude of “Oh, I understand, now. I was an idiot then, but I get it now.” Confidence is good, but never arrogance.

I am learning that no matter how many times I melt the wax wings, there will always be a more powerful sun and a better way to fly. 

Subscribe

-------------------

I am a naive engineer.

Being naive at something is probably the most exciting part—you get to learn at a mile a minute.

Live Deeply,