On Being Great

2026.09.06

CLXVIII

[Being Great; Escaping From First Principles; Perpetual Beginner; 2 Years of Failing Up; Low Trust; Anti Bullshit; Beautiful Code; Spaghetti Code; The Power of Seeing Different Levels; Don't Lose the Art]

Thesis: Perhaps mastery comes from seeing what is possible and being able to derive it from first principles more than it does from pattern recognition.

[Being Great]

I want to be great at the things I do.

That is really hard to do. It's easier to NOT be great. It takes a lot of concentrated and consistent effort to be great.

I saw my jiu jitsu instructor, who has been a black belt for over two decades, discover the defense for an uncommon move from first principles in real time the other day.

I think that this is somehow related to greatness, perhaps, or mastery; being able to approximate truth from first principles on the fly.

Getting to that point is super hard, though. Constantly feeling like a beginner must be an important ingredient for it, and building the confidence to know & be able to re derive things from and handful of basic truths.

My post last week, I didn’t really dig into what I think great or beautiful code is. I’ll try again this week. Unfortunately, I don’t have a formula, and can’t prove it, so I’ll telling you why I think it’s self evident that it’s beautiful, not how I can prove it.

Finally, an anecdote from C House to drive home why seeing what is possible is so important to being able to do it.

This post is a bit winding and reflective; I’m trying to articulate these ideas for myself as much as I’m trying to share them with you.

[Escaping From First Principles]

In the Jiu Jitsu leg lock lab I went to on Friday, I got to watch a 20+ black belt teach an absolutely lethal submission I was completely unaware of. And then, when I asked him how to get out, I got to watch him say, "I don't know," followed by 20 minutes of real time experiments before he formalized a succinct, useful answer.

First off, the submission was a short ankle lock with a butterfly hook in. I have been grappling for nearly 5 years and well over 1000 hours, and I had not once in my life seen this exact move before. This is not an uncommon experience in BJJ, to learn something new so far into your journey: it constantly reminds you that, in a lot of meaningful ways, you are perpetually a beginner.

This submission is such an interesting one, because it contradicts a common truism: everyone teaches that if you are in a leg entanglement, and you 'clear the knee line', you are safe from further leg submissions for the moment. I was even taught this implicitly at John Danaher's gym, who is one of the guys who revolutionized leg locks for the sport.

This short ankle lock makes it simply not the case: when an opponent is escaping from ashi garami, you butterfly hook the inside of their leg close to their knee with the leg that was your outside leg, then cross over your other leg to capture their knee.

If you don’t do jiu jitsu (even if you do) that sentence might not make any sense. If doesn’t matter, because they've 'cleared the knee line' but are in imminent danger of a wicked submission.

I asked our coach how to get out of this. More crazy than me not having seen this submission is that this 20+ year, 5th degree black belt didn’t have the escape memorized. He did not lie and say that he did - rather, he said “I don’t know,” then proceeded to spend 20 minutes figuring it out in front of us.

He had an experienced player repeatedly sub him with the lock until he 'discovered' that you need to grab their non attacking arm and pull the elbow toward you without yanking the hand up and out, as that would let them finish the sub faster.

I don’t know if I can overstate how sublime this was to watch: the man was using his deep understanding of the game to arrive at an accurate answer in real time.

He didn’t need to watch a youtube video or go to reddit; he understood the principles so deeply that he was able to independently arrive at a correct answer.

[Perpetual Beginner]

Lately, I have been feeling like a perpetual beginner in everything I do.

When you start a company, you always have some challenge. And when you solve that challenge, if you want to keep growing,you have another challenge immediately after to deal with!

And it's very likely that it's a new challenge or a new non obvious version of an old challenge. Otherwise, it wouldn't be such a challenge, or you would've solved it pretty quickly.

And engineering wise, man, I always expect more of myself. I have an impossibly high aspirational standard that I'm never going to hit. It's easy to forget, though, that you've been getting closer to it, especially when you have your head down for years at a time.

You might have a moment of hubris that gets flattened by some risk or hazard previously unknown to you. The hubris stays, in the sense that you gain the confidence that you will figure it out. But, it’s less that you already are so great and know the thing, and more of an admission that you have no fucking idea what the answer is but WILL find it.

When I was in Greece on a ferry, I was thinking, "What would I do if this boat sank and I knew no one was coming to rescue?" I could always see some coast, even if it was miles away, so I thought, "Oh, I'd just swim to shore."

And I genuinely believe that I would be able to if I needed to! Maybe in reality I'd die, but I'd die trying. But you don't think about that part, and you wouldn't if the situation arose, other than maybe to say, "If I died, what would be the most likely reasons and how do I stop that?" Then do anything in your control to prevent it, and keep going regardless.

Something like starting a business or learning a new skill is like that for me. A weird walking contradiction of "I have no idea what I'm doing but I'm going to do it."

[2 Years of Failing Up]

If you spend so long thinking like this and look up for the first time in a while, there is a certain feeling of shock at how far you’ve come even though you still feel like an ignoramus.

Last week, I found myself explaining to someone the difference between server side and client side rendering for websites and showing her how to watch network calls to learn about a site and how it’s designed. Afterwards, I realized how much more I understood about the internet than I did, say, 2 years ago.

Likewise, NL explained to me his dream product for some analysis he wanted to do with a bunch of job postings he had, and I gave him a very straightforward solution involving a relational database that is quite similar to a pattern I use to process hundreds of gigabytes of data regularly & efficiently. This wouldn't have been so obvious to me years ago either, but now it's instant.

That said, the line between pattern recognition and first principles is thin in the latter example; perhaps it doesn’t matter in the average case, and only matters in specific ones.

[Low Trust]

I'm an incredibly low trust person. When I was in Greece, it took me 5 days to realize that a lot of the people, including the owner of the hotel I was staying at, were just genuinely friendly and not trying to secretly take advantage of me.

I write this blog in the same cafe in a quite safe area of Cambridge every Sunday; when I go to the bathroom, I take my laptop and phone with me without fail, because I don't trust anyone enough to watch them for me.

When someone tells me that something is true, I often times push on it and see how deep their belief is in the thing.

When they get stumped, the most trustworthy people will say "I don't know," and then try to work it out in real time, like my coach did. This happened recently, both when I was talking to C House residents about genetics & quantum: you can often tell when someone is actually working from an internalized understanding of something rather than simply pattern matching to things they know.

I don't feel shame very often anymore, but when I do, it is almost always when I catch myself saying something confidently with insufficient information. I really don't like bullshitting. Sometimes, you say something that you think is true, but as you say it out loud, you start to question it and realize it's maybe not so true. This also happens when you write, which is one reason I like writing so much.

This is why the whole thinking from First Principles thing is so important: there is some set of very basic things that you assume are true*, and then everything else should be derivable from them.

If you operate from First Principles, you can operate effectively from a low trust position. The other person should either be able to recreate their claim from very basic things, or point to repeatable observations, rather than just saying something like "Oh I just know it's true" or "So and so said so!"

Perhaps thinking that the hotel host has knife behind his back is too far, or perhaps it's still the best strategy; guilty til proven innocent, as so many things are.

_{*Of course, these basic things can be wrong, too! Such as our understanding of time as a constant was before the theory of relativity. That said, you try to keep them as basic as possible and revisit them if contradicting information comes up, which is easier said than done.}

[Anti Bullshit]

I think one of the reasons I get so frustrated by LLMs is because they can't obviously hold a model of cause and effect or deterministic rules in the same way we can. And, of course, they bullshit a lot, too!

When a human bullshits you, you can call them out. Calling an LLM out is something that isn't so effective, other than to maybe adjust prompting or a harness, which is still non deterministic. Sure, you can do things like guarantee structured outputs, or could make a complex system that checks citations automatically and flags broken links or links to sources that are semantically dissimilar from the point the LLM is making, but this still isn't deterministic in the sense of this is consistent within a specific worldview.

Perhaps I need to be more detached, and find a way to use them for what they are. But since I know this about their nature, it’s quite frustrating when I depend on one and it gets something wrong for this known reason!

When it tells me something unverified and I believe it and I make a decision based on it I feel like an absolute fool and utter mark.

"Why did I trust that thing to make this decision?! I should've checked!"

Yeah, you should've checked! But when it's so easy not to, it is even harder to check. It's quite easy to get in that state that isn’t flow where you're not really focused when you are doing deepwork, but you feel productive and are paying enough attention but not all of the attention. You let yourself get distracted and those moments of distraction 'feel' productive but aren't.

In all honesty, this is one of the reasons that I don't keep an LLM directly in my IDE or 'terminal': I want it to be harder for me to depend on it and to let it drive.

I actually think that friction is good, because I even see when I am coding with it open in another window, there is a pressure to just use it and nothing else.

[Beautiful Code]

NOTE - this section is more technical than I usually try to write. Regardless, I’ve made an effort to make it clear.

In last week's blog, I think I failed to really drive home the difference between garbage code, okay code, and beautiful code. If I'm unable to show you that, then I don't think my other arguments make as much sense.

Luckily, I do think that when you reflect on it, the beauty of certain code becomes self evident! I wish I could prove the beauty, and maybe one day I'll be able to. For now, I'll give you symptoms of it.

Beautiful Code is easy to maintain, edit, and extend:

• Maintain: Things don't break so often, but when they do, you can quickly identify and isolate what went wrong and fix it.

• Edit: if you decide to change an assumption or edit some behavior, you can quickly pinpoint want needs to change and change it without breaking a bunch of things

• Extend: If you want to add new functionality or iterate on the code, a lot of the core plumbing and tooling should stay intact; adding one more function shouldn't break all of the others!

Now, below is some code I wrote for WhiteWhale that I believe is beautiful. Basically, WhiteWhale sends out a lot of notifications (too many?) to users via Webhook, Slack, Microsoft Teams, and email (mainly email). This pipeline is what we use to identify users who are supposed to receive these emails, grab the data for them, render the email, and send it to them.

    async def email_update_pipeline(self, filter_users: List[str] = [],
        mode: Literal["Base", "Admin-Assignment", "Admin-Overview", ... "Search-Results"] = "Base", tz: str = 'et'):
        """
        ....
        """
        if mode == "Base":
            functions = [
                (self._get_target_users, []),
                (self._add_top_articles_to_users, []),
                (self._add_opportunities, []),
                (self._write_html_template_email, ["signals.html"]),
                # (self._write_emails, []),
                (self._send_emails, []),
                (self._mark_articles_as_sent, [])
             ]
        elif mode == "Admin-Assignment":
            functions = [
                (self._get_users_with_specific_active_emails, ["admin_assignment"]),
                (self._get_*, []),
                (self._get_*, []),
                (self._eliminate_*, []),
                (self._write_html_template_email, ["admin_farsight.html"]),
                (self._send_hermes_emails, ["*"])
            ]
        elif mode == "Admin-Overview":
            functions = [
                (self._get_users_with_specific_active_emails, ["admin_overview"]),
                (self._filter_users_on_*, []),
                (self._get_*, []),
                (self._get_*, []),
                (self._get_*, [False]),
                (self._write_html_template_email, ["admin_overview.html"]),
                (self._send_hermes_emails, ["*"]),
                (self._mark_admin_overview_as_sent, [])
            ]
        .... more functions ....
        elif mode == "Search-Results":
            functions = [
                (self._get_unsent_searches, []),
                (self._get_search_data, []), # filter out any w no data here
                (self._write_html_template_email, ["search_results.html"]),
                (self._send_hermes_emails, ["*"]),
                (self._mark_searches_as_sent, [])
            ]
        else:
            logger.error(f"Invalid mode for email update pipeline, {mode}")
            return

        current_data = None
        logger.info(f"Beginning Email Pipe with {mode} mode enabled")
        for function, base_args in functions:
            logger.info(f"Email update pipeline processing {function.__name__}")
            if current_data is not None and len(base_args):
                result = await function(current_data, *base_args)
            elif current_data is not None:
                result = await function(current_data)
            else:
                if len(base_args):
                    result = await function(filter_users, *base_args)
                else:
                    result = await function(filter_users, tz)
            if result.success:
                current_data = result.data
                logger.info(f"Email update pipeline completed {result.function_name} with {result.result_count} results")
                # print(result.data)
            else:
                logger.error(f"Email update pipeline failed {result.function_name} with {result.errors} errors")
        return current_data

Used * to replace some names. … marks missing docstring plus more function lists. Rest is verbatim.

Some things I'll point out that help with making it beautiful:

• Data Driven: The actual logic is ~ 20 lines at the bottom; in effect, the if / else branches are the same as a dict, and I can and should replace it with such. I really thing it is nice when the data structure can drive the execution of the code

• Low Dependencies: this part is very much plumbing, so we shouldn't really need many outside dependencies. Other than my own functions, I think logging is the only dependency? There are more below, but if I need to nuke one, I don't have to rewrite this core part of the code.

• High Level of Abstraction: This is hardly even code! It's very clearly a list of functions. The only 'coding' I'm doing here is deciding a valid combination of functions! The 20 lines below that have been executed 4 or 5 times a day for over a year without problem!

• Consistent Structured Output: Every single one of these functions returns the same data structure. So, we can succinctly get a consistent 'status update' at each step of the pipeline. This amortizes logging cost.

• Error Handling: The structure is an envelope that catches most failures and brings them up to this level of code; rather than getting a raise that could break some other shit that I don't want to break, the function just tells me when it broke and moves on (this works well here because very rarely if ever is the other code being executed path dependent on this code)

There are problems with this code! But, when errors happen, I can almost always pinpoint the exact failure point rapidly.

And really, the whole thing really doesn't need to be in a class - it sort of feels convenient for holding some constants or configs, but I could do just as fine with a dictionary of such things optionally updated at runtime with arguments. Probably would be better, because I wouldn't have to worry about storing state in both the instantiation of the class and the function call!

Also note that I didn't START with the code like this; the first sending pipeline, if I recall correctly, was standalone. It wasn't until 2 or 3 that I added the lists of functions. And then it wasn't until more than this that I generalized the template filling function and the user selection function. And in some cases, I didn’t bother to change the old functions to use the new general ones, which is lazy and/or efficient.

It was very gradual and incremental and updated maybe not when it was 'obvious' that it should be update, but perhaps just before it was 'obvious.’

Now, if I want to add a new pipeline of this type, it is actually really fast. I perhaps need to write one or two functions to fetch and mutate data, along with the list of functions. And, an email template, which I’ll have an LLM write once I decide on the underlying data structure to feed.

[Spaghetti Code]

Writing code like I showed above is not only joyful to me, but it also creates massive speed gains in terms of my ability to write it.

This is because I've basically raised the level of abstraction on which I'm operating for 80% of the 'work' in this function. Again, adding a new pipeline is typing out a list of functions, maybe two of which I have to define.

I don't have to write a new sender or new html template rendered or a new function to figure out what user's to get, because I've progressively generalized this.

Now, the worst form of that code might be if I rewrote every function for every instance of the pipeline I needed. If I did that, there would be a LOT of code. Something like 2 or 3 times as much! This would be a lot to maintain and pretty bad. If I fixed the sender in one spot, it would still be broken elsewhere.

A more common form you might see would be to have the most obvious things, like the email sending and user selection as helper functions. In my opinion, this is WAY better than the awful form I just mentioned, but not as great as the above form I showed, because you'd need to write a standalone function for each of the instances of the pipeline, and you'd have a lot of redundant code. You might also be less inclined to be disciplined around the consistency with the input / output data structure. Overall, it would be quite a bit harder to hold the whole thing in your head as it grew overtime.

The code above is designed to be held in your head regardless of how many pipelines you add. There is a lot of powerful consistency.

When your code does cross that gap though to the realm in which you can hold enough of it in your head to fully understand what you're looking at quickly, and quickly debug it, and edit it, and extend it, that is where I start to think that speed gains with an AI system are not so relevant because your writing speed is already asymptotically fast.

Perhaps there is a boost from the "parallel processing" in terms of writing you get to do when you have an LLM running on one task concurrently while you run on another, but for a sub 15 minute task, I wonder if the startup and tear down time of that process, as well as your brain's switching cost, kills the gains?

And, if you say, Noah, but my code base is not there yet, I'd wonder: will it ever get there if you let the LLM do the whole thing? Maybe, maybe not! Again, from my own experience using them, they’re like a Siren call towards a normal, average code base that you lose comprehension of overtime.

Remember, nearly everyone who is a complete, die hard vibe coder says they check the code at first and then stops altogether!

[The Power of Seeing Different Levels]

I think that if you build something cool or that you think is beautiful or even just effective, it's nice if you share it with the world. For one, if you're wrong, you want someone to be able to tell you you're wrong, and why, so you can grow faster.

The other reason is that if you're right, you're paying it forward: It's hard to know what performance looks like until you see it.

One of the new residents of C House, PD, said something that shocked me last night:

This came after myself and NL we're talking with him about sales and go to marketing strategy.

PD sells a hardware product to physical trainers and has done quite impressive numbers very quickly. A couple days ago, he asked me how I would scale up if I were him. I just asked him questions about where the bottle neck was, and it sounded like it meetings booked, because he already has a 30% win rate, which is epic.

He asked how he could get more customers, and I asked him if there was a database of people with licenses he could sell to.

Then, last night, he said, "Man, I found the database, but it's not useful! It only has the trainer's LinkedIns, and people don't respond on LinkedIn in my space!"

NL and I started laughing out loud, because the solution was so glaringly obvious to us. NL: "Oh man, I'd also be so pissed if found a database and it was full of absolute gold!"

PD didn't know this, because he simply hadn't been exposed to it before: if you have someone's LinkedIn, it is beyond trivial to get their email address! You can do it with maybe 60 or 70% accuracy with api calls in sub 10 minutes.

PD is already CRUSHING with cold email, so realizing that having the LinkedIns of everyone who can buy from him means he has their email, too, is really quite valuable.

PD is a very smart person. When you don't even get to glimpse what's possible, though, it can be hard to come to it on your own.

As important as I think it is to dedicate a lot of time to deep work and locking in on something, finding the right community of people to talk with too can help so much.

I’m a founder trying to take a two man bootstrap to $1M ARR without hiring anyone. If you want to follow along for reflections on the journey, subscribe.

[Don't Lose the Art]

I'm not a great programmer, but I do believe I am comfortably above average.

Not many people seem so interested in what makes code good anymore; there's a lot more talk around just not writing it.

If no one even shows what they think beautiful code looks like, maybe we'll stop thinking it's meaningful or even possible. Just like if I didn't see my coach work through an escape real time and discover it on the spot, I wouldn't get how much is possible if you deeply understand the sport. Or, if PD stayed in a hacker house with fundraisers, it might have taken him a lot longer to find a path of least resistance to more revenue.

So, even if I’m wrong, I think it’s good to share things that I believe are beautiful like the above code. I’m not bullshitting: I genuinely believe it for reasons that are clear to me and I’m learning to make clear to others. I could be wrong, though; if I am, and you believe it, tell me. I may not agree, but I’ll listen to see if I need to update priors.

I'm obsessed with leveling up. That always means constantly being a beginner, even when you're nearly 5 years into something, like I am with jiu jitsu. Other times, it means having the confidence to put your name behind something that you believe is well done, and explain why, while concurrently poking holes in it and seeing where it could be better.

That's how we keep growing.

No clear substantiation yet, but I can’t help but think beauty and truth and greatness are all aligned.

Live Deeply,