[ MAIN IDEA ]

Three years ago I was teaching web development at a bootcamp. ChatGPT was generating kludgey code and writing SQL. My students kept asking me questions that they could’ve easily gotten from ChatGPT during my lecture. After polling them, only about 10% of them had an account. I stopped the lecture to share my screen and ask ChatGPT the question they just asked me. They were amazed, and the rest of the class stopped paying attention to me as they created an account and played around with it.

Then I quit.

Shortly after, I made a YouTube video encouraging people to just open-source 95% of their code, arguing that code’s inherent value is going to plummet anyway. Some people agreed, some got offended. Either way, it happened.

I’m not always right about these things, but I’ve found that if you put in the work and read between the lines, you can’t help but build convictions.

After delegating daily coding to agents and 5Xing PR velocity the last few months, I have a new conviction.

Code won’t be a thing for long.

Sure, our sites and apps will run on code. Those who learned to code by hand will have a deeper understanding and more nuanced prompts, just like those who went to trade school to become a mechanic will know how to diagnose a squeak faster. But code won’t be something we think about as valuable on its own. Code won’t be something we think about at all. Syntax, algorithms, frameworks, languages, who cares.

Identifying as a coder of JavaScript will be like identifying as a coder of Assembly: silly. There won’t be ‘${LANGUAGE} Engineer’ jobs, there’ll just be Engineers. Going to ${LANGUAGE} conferences will seem weird.

PRODUCT IS THE NEW CODE

Instead of the language or framework we use to make the thing, we’ll identify by the thing we make.

“I’m Bob, I make budgeting apps for SMBs.”

“I’m Jill, I make calendar apps for remote workers.”

“I’m Hillary, I make tools to help lawyers get leads for workers comp cases.”

The time we used to spend learning a new API version or performance tuning will be spent talking to customers or marketing.

Instead of owning one small module, one engineer will own the entire repo.

Instead of having to raise VC to pay for 5 SWE salaries, an ambitious guy with an idea will spend $1,000 in tokens and create the MVP overnight.

WHAT THIS MEANS

I’m still wrapping my head around how this changes the world and our psychology. However, the spirit of this newsletter is to share my notes as I go, so here’s what I’ve got so far.

• Products become living entities. Many versions of a product will exist at a time and we will be able to adapt it with a grumble. Making apps will be more like playing with play-dough than laboring at the keyboard.

• Humans become the scarce resource. There are only so many eyeballs, credit cards, and human time available. As long as humans are the ones who gate-keep their wallets and attention, they will be the ones people compete for.

• Reputation will be the GTM. A digital trail of undeniable proof and a lack of scandal will do more to convince people than a campaign or a glossy sans-serif landing page.

What do you think? How will the abstraction of code impact our lives and work in the near-future?

[ INSPO ]

If you liked this post, consider sharing it on Hacker News so others can find it.

What a time to be alive.

Despite using AI daily for a while, I wasn't comfortable with letting agents do most of the work until 60 days ago. Since handing over the nitty-gritty details, I've merged over 900 PRs in two months.

Flooding GitHub with more LOC isn't a flex. In fact, I resisted doing volume because I didn't want Compass Calendar to turn into a mountain of slop.

However, it's finally possible for agents to do work without messing everything up along the way.

What I'm most proud of from the last two months isn't the PR count, but how the product has actually become SIMPLER.

It takes a lot of restraint to keep refining an existing UX instead of rushing into more features. But man, it feels good to go fast and not break things.

If you're a developer who's been considering handing over more of the work to your agents, this is your sign.

Here’s a simple way to get started that doesn’t require any extra tools.

1. Tell the LLM to plan a feature by creating well-groomed issues under a single milestone in GitHub

2. Tell the coding agent to work through each of the issues on their own until the milestone is done (use “/goal”).

3. Repeat

[ INSPO ]

If you liked this post, consider sharing it on Hacker News so others can find it.

Richard Hamming was a 20th-century mathematician who surrounded himself with greatness: Feynman, Oppenheimer, Shannon, and his colleagues at Bell Labs. He started wondering why some of his smart colleagues did significant work, while others, although smart, only did mediocre work.

In an incredible essay, he gives his answer. The ones who achieved great work had:

1. The courage to seek the significant problems

2. The humility to resist their egos

3. The mental preparation to pounce upon a “lucky” opportunity

The first point surprised me the most.

“Of course you have to work on the significant problems to make a significant contribution,” I thought indignantly.

But then I reflected on my own project choices, and realized much of my work was small-minded and inconsequential to others.

I’m not alone. Most of the people Hamming worked with at Bell Labs, although top 1% thinkers, never stopped to identify the most pressing problems in their field. Hamming would go to the Chemistry or Physics tables at lunch and play the fool, asking them what the top problems were. Then he’d find out what each of them was working on. Finally, he’d ask why they were all wasting their time on problems that — by their own admission — weren’t significant. (He then had to find a new lunch table.)

[ THE TRAP ]

The trap for us who aren’t working with the top 1% is to pretend like we’re at the modern Bell Labs. You and I are going to be massively impacted by AI, but we’re not going to contribute to AI chip architecture like an Nvidia engineer might. We’re not going to become a Shannon, Hamming, or Sutskever. But that doesn’t mean we can’t do significant work.

[ THE WAY OUT]

How to have top 1% significance without having top 1% intellect.

1. Niche. Instead of trying to compete with frontier labs on LLM engineering, combine AI with other domains and become an expert on the combination. For example: AI engineering for solo bootstrap founders with 10k in savings, 2+ years of coding experience, and building B2C iOS apps for US-based marketing firms with $500k+ ad budgets. That’s a lot easier than competing on just AI.

2. Leverage your work style. Your interests can help you pick a niche, yes. But you can work in a way that complements your natural way of consuming and producing. For example, I love to read, write, and watch ASMR cooking videos. I take what I’ve learned from my readings to write things like this. Then I record ASMR-style videos, add a voice-over track, and turn it into a quick YouTube video. Whereas my old YouTube videos were complicated and draining, this approach actually gives me energy and makes it easy to stay consistent.

3. Leverage your experience. There’s an epidemic of brain-fried iPad kids who’ve spent a decade of their youth scrolling. But young CEO Roy Lee points out how that’s their advantage, because they know what’s good. They know what type of video makes them stop scrolling. It’s become a deep-seated intuition, enough so that they can make these types of videos themselves and sell them to marketing firms. Millennials or Gen X could do the same, but we don’t have the same intuition for the vertical medium that a 16-year-old kid who's spent 4 hours a day for the last ten years scrolling does.

All of these tips are variations on the same thing: If you can’t do significant work in one single domain, keep stacking domains until you can.

• AI + consumer + indies + marketing + US

• Reading + writing + ASMR + YouTube

• Shortform + marketing + Gen Z

[ INSPO ]

The 3 Hidden AI Gold Rushes | Roy Lee x Jack Neel Podcast (youtube.com)

New software releases? Who cares. Learning new CS concepts? Whatever. Studying for the next interview? Job probably won’t even exist in a year. Working on that side project? No one will care because it’s just another addition to the mountain of slop, and the guy bagging your groceries can do it. Everything is done and cooked with AI now.

It’s exactly like that feeling once you enable cheats in a game; sure you can do anything, but everything is meaningless now. Our entire purpose and joy in life has been taken from us.

[ MAIN IDEA ]

I sometimes feel this way, too. It’s natural. Unfortunately, it’s not an empowering mindset. It positions us as victims being crushed under a technological wave, rather than leaders riding it.

So here are a few things that can counteract this mentality:

1. Recognize that it was never ours to begin with. Nothing was “taken from us.” Just because we know how to code by hand doesn’t mean we’re entitled to an infinite stream of validation. We learned the skill of coding by hand and were compensated for it handsomely because it was scarce. Now that this is no longer the case, we’ll have to learn new skills.

2. Writing code by hand was never the point. The point is helping people. It’s not about us; it’s about them.

Founder Patrick O’Shaughnessy explains in an interview how surrendering to helping others helped him find purpose during a time of seeking. I love the simplicity of it. It’s simple yet flexible enough to adapt to the rapid changes AI is ushering in.

I’ve been considering what’s next after my recent launch. It’s scary to try to come up with an answer, but asking questions that embody the spirit of helpfulness is much easier. Here are a few that I like:

1. Who can I help the most?

2. Who are the easiest people for me to help?

3. What skills of mine are the most useful to them?

4. What skills do I need to learn to be more helpful?

Answering these will lead to a short list of things to do: services to offer, products to create, things to learn, places to go. Then you can narrow the scope and ask again.

1. Who can I help the most this week?

2. Who are the easiest people for me to help this week?

3. What skills of mine are the most useful to them this week?

4. What skills do I need to learn to be more helpful this week?

The hard part, of course, is taking action, validating assumptions, and iterating based on feedback. But doing this has helped me flip the mindset from “I’m cooked” to “I think I could still be helpful.”

That’s a good place to start.

[ INSPO ]

[ MORE ]

DHH: How to Build a Profitable Company Without Losing Control (youtube.com)

How it went - by the numbers

PH Stats

• Daily Rank: #17

• Upvotes: 81 points

• PH followers gained: 50

• Comments: 2

Marketing stats

I promoted the launch on my socials and the app’s email list. I also hosted two YouTube livestreams, where I answered questions and showed the launch progress.

• Followers gained: 0

• YT Live views: 86

• Peak concurrent viewers: 17

Conversions

Basically, more casuals. Of the 256 visitors, three went through the full onboarding and then connected their Google accounts.

How it went - vibes

Spam. The product went live at 12:01 AM. By 12:02, I had a dozen LinkedIn connection requests, cold emails, and new PH followers. They all said they loved the product and would be happy to promote it to their audience … if I paid them a fee.

PH disengagement. I was encouraged after seeing a thoughtful comment from a fellow maker, until realizing it was ChatGPT. He went through all the products of the day, posting generic messages to draw more traffic to his launch. I got one comment from a real human, an old friend.

Direct engagement. I got some congratulatory emails, texts, and messages on the livestream. People were more willing to share their support directly, rather than from a PH account.

Recommendations

Of my four PH launches, this one had the best product and marketing. Yet I got the least amount of PH engagement and the most spam. Something just felt off about the PH experience. Then I found that PH is actually dead and has been for a while. It’s sad to see another site I used to frequent be consumed by the dead internet black hole. But it’s not all for naught. I didn’t get the same launch day zeal from the old days, but I got traffic, feedback, and identified a few areas where the product could improve.

So, if you have a product and are thinking of launching on PH, here’s what I recommend.

1. Keep it simple. Don’t overthink the marketing or launch mechanics. 80/20 it by making the page presentable, but focus most of your efforts on the product. The only way you’ll get organic growth on this day is if real people reshare it, and there are so few real people on the site now that it’s tougher to get them to do that than before.

2. Don’t try to become product of the day. Doing this would violate the first rule. Instead, just think about the site as a free source of traffic for a day and a bump to your SEO.

3. Harden your LinkedIn by enabling the setting that requires people to enter your email before making a connection request.

4. Host a livestream. This is much more natural and fun than trying to get people to sign up for a dead platform and have fake convo in the comments

5. Set up auto-fixing PRs. Error happens → AI fixes bug → AI merges and deploys to staging→ AI notifies you → you verify and deploy to prod. This will allow you to get some sleep on launch day while also fixing critical bugs quickly. I didn’t do this, but I wish I did, because most of my day was just watching logs.

My PH experience may have been underwhelming, but I’m still a fan of official launches. It allows you and others to celebrate progress. In a field where our projects never really end, having these milestones is good for the psyche.

Good luck.

The second requirement for Edison's 1870 contract for an autographic telegraph: simplicity.

The sixth requirement says the same in different words: "Have no elaborate preparation..."

If Edison could invent new ways to communicate in the 19th century with simplicity...we should be able to build CRUD apps in 2026 with simplicity.

For anyone else who didn’t know what an automatic telegraph was: Think of it like a pre-internet fax machine. They’d transmit exact copies of handwritten writing or line drawings over electrical wires twice as fast as Morse code operators could.

[ INSPO ]

[ MORE ]

Naval’s advice on simple sales (substack.com). TL;DR - Make it good, then tell the truth.

[ MAIN IDEA ]

Occasionally I’ll run into a fellow unemployed indie dev who is actually focused on a single project. Once I find this out, I always ask this question excitedly:

”What’s your runway?”

So far, I’ve never gotten a straight answer. Instead, what follows is a ramble about how their wife is supporting them for “a little bit,” how they can sell some crypto, and how they can probably go back to their old job and moonlight if things flop.

I used to get so frustrated that I’d jump in --

“No, I mean how long until you run out of money??”

That only elicited even longer rambles, this time about their 401k rollover, their history as a consultant, their HSA, their father-in-law’s welding business, Airbnb, and property taxes.

I finally realized this:

Bootstrappers don’t know their runway.

“Runway is for those YC companies,” they think.

No, runway is for us way more than it is for them.

That’s because if you don’t know your runway, your financial decisions are driven by your emotions, which is bad.

So here’s how to figure out your runway as a bootstrapper.

Part I: Get your numbers

1. How much are you losing? Add up last month’s expenses (business + personal) so that you have one number.

2. How much is coming in? Add up last month’s income after taxes. One number.

3. What’s the gap? Expenses - Income.

4. How much do you have? Add up the cash and assets you’re willing to part with.

Part II: Divide

1. Cash (#4) ÷ Gap (#3). That’s how many months you have.

2. Multiply that by 30 if you want it in days.

Now you know your runway.

This’ll help you see how big of an impact your lifestyle has on your startup’s success. Let’s look at a few scenarios; you’ll see what I mean.

Founder A is confident, because he’s sittin’ on $100k cash from an IPO. But he spends $15k each month, and has nothing coming in.

100,000 / 15,000 = 6.6 

Hotshot has less than 7 months of runway.

Founder B is young and broke, but frugal. He set aside $3,000 before getting laid off. He’s spending $1,500 and makes $800 from landscaping on the side. His gap is $700.

$3,000 / $700 = 4.3

The hotshot founder with a hotshot lifestyle only has two months more runway than a broke kid with a landscaping job!

Founder C got things off the ground before quitting her job. She’s spending $4,000 but earning $3,000. Her gap is $1,000. She’s got $20,000 stashed away.

$20,000 / $1,000 = 20

20 months of runway! 600 days to figure out how to earn an extra $1,000 and become ramen profitable. Founder C has 1/5 of the cash of Founder A, but over 3X the runway.

It’s wild to see all the gibberish in your head reduced to one number, isn’t it?

Clarity is king.

Although it’s initially scary, I find that tracking this number is empowering.

It reminds you that you always have two levers: make more money, or spend less money. Hotshot Founder A could triple his runway by making $5k recurring revenue more next month. Or he could make $0 and triple his runway by downsizing to a smaller apartment.

If you don’t like your runway, you can cut expenses, pick up consulting work, charge more, or pivot. These are all rational responses to a financial reality.

It also keeps your emotions in check. Bumping into a high school friend who got a Big 4 Job and just bought their second Audi doesn’t spike your FOMO anymore; you already confronted the reality of your decisions in a spreadsheet that morning.

So whether you’re sitting on a mountain of cash or scavenging for change, please calculate your runway, if only to make our conversation more enjoyable for me when we bump into each other.

[ INSPO ]

[ MAIN IDEA: SIMPLE PAYMENTS ]

In 2004, Howard Wein started selling Philly cheesesteaks for $100 each.

In 2013, Nipsey Hussle sold 1,000 mixtapes for $100 each.

In 2014, he sold 100 for $1,000 each.

In 2023, MSCHF sold a microscopic 3D-printed handbag for $63,750.

This blew my mind.

But after thinking about it, it started making sense.

They may have been offering similar products to their peers, but they were playing an entirely different game.

Howard was challenging your perspective on classic food.

Nipsey was using music as a funding mechanism to uplift his community.

MSCHF was leveraging clout to highlight our insatiable appetite for status and small handbags.

These creators knew they were doing things differently, so they refused to market and price themselves like commodities.

We devs should take notice, because our traditional funding sources are empty at their core.

• Deal sites like AppSumo enroll you in a race to the bottom, where you’re selling lifetime deals for $29

• Launching an NFT involves a lot of education and convincing people you won’t rug pull

• VC often requires you to trade your soul and control for time.

• Raising from friends & family exposes the wholesomeness of your relationships to the brutality of the marketplace.

But what if, like those creatives above, we took a different path?

What if we found a few people who valued our stuff so much that they’d be willing to pay 100X what a normal user would?

That’d change things, a lot.

You could make it insanely useful for them.

Suddenly you have daily users who really care.

They’re emotionally invested, so they give better feedback and are less demanding.

With that extra profit, you can reinvest in improving the product, support, and your local community … while also having enough left over to feel stable enough to shoo away those VCs who tempt you with a quick flip.

Your perception of yourself improves. Most importantly, you keep your soul — the pure essence that gave you the courage to start in the first place.

It sounds too good to be true.

Well, I figured I’d find out for myself if this theory holds weight.

[ THE STACK ]

So today my goal was to create a high-ticket offer — the simplest way I could.

No fancy landing page, no pipeline of automations, no ads, no images, no analytics, no funnels.

Just a blog post and Calendly.

Here’s how it works:

• The blog post explains the offer. Here it is for reference: https://www.compasscalendar.com/blog/crew

• There are two CTA links in the post that redirect to Calendly. Part of the offer is a call with me, so I wanted people to book it directly without adding a delay or another step.

• Calendly requires payment before finalizing the meeting. I connected Calendly with Stripe, so payments get tracked there. I didn’t even have to create a new Stripe product to set this up.

• When someone books, I get an email from Calendly and the money. Calendly handles the reminders, and then I just have to worry about fulfillment, which requires me to send a physical CD in the mail.

This whole project took fourteen hours, but eleven of those were crafting the offer and refining the copy. So if you already know what you’re selling, you could copy-paste this approach and be live in three hours.

I didn’t have to fuss with ads, product demos, screenshots, or high-res pictures. Just words, a link, a $12 subscription, and a few integrations.

That’s not bad!

Will the offer work? I guess we’ll see. Either way, it’s pretty cool that you can go from having an idea to having a way to monetize it in one day.

[ INSPO ]

In the last seventeen days, I’ve merged 266 Compass Calendar PRs. That’s 16 per day, a 14X increase since June.

One reason why I feel comfortable pushing so much code is that I enforce simplicity in each PR. Here’s how:

• A “/simplify” skill runs on every PR, which creates a commit that reduces complexity. Since this is a new commit, I can review it to ensure that we’re preventing sloppy abstractions.

• A PR template has a “Simplicity” heading, where the agent has to explain what was simplified or why the implementation is already minimal.

• My system prompt explains the supreme value of simplicity.

• I do a manual sweep of the code and keep a list of things I want simplified, and then kick off another session

Basically, I’m letting the agent do the first implementation. Then I’m nagging it to simplify things without breaking tests. Then I’m nagging it again to simplify it further.

It’s the equivalent of Henry Kissinger repeatedly asking his assistant, “Is this the best you can do?” before reading a draft. After a few rounds of revisions, the assistant eventually spats back, “Damn it, yes, it’s the best I can do!” Kissinger replies, smugly, “Fine, then I guess I’ll read it this time.”

When your assistants’ tokens are less expensive than your time, why not set a high bar before reviewing yourself?

If you’ve found a clever way to keep things simply, reply here to LMK.

[ INSPO ]

[ MORE ]

Kissinger: a biography (archive.org)

https://berkshirehathaway.com/ — the conglomerate that has enough money to buy half the internet hasn’t veered from its 90s aesthetic of blue font and direct links.

https://telegram.org/ — A consumer messaging app that doesn’t try too hard. The combination of simple text and whimsical rubber ducks is eye-catching without being try-hard. If one of the top 5 most-downloaded apps in the world can get away with this, so can you.

https://yaml.org/ — A site that’s structured to mirror a real YAML document. A great example of how to break out of the generic WordPress or technical doc site layouts.

https://www.barebones.com — a 34-year-old text editor that “(still) doesn’t suck.” The site is clearly written by a cowboy indie developer who doesn’t care what the cool kids in the valley think.

https://news.ycombinator.com/ — it’s amazing how much use they’ve gotten out of this simple hyperlink + feed concept. Their commitment to the chronological feed is what keeps me coming back.

https://www.space150.com — an agency that proves that simplicity doesn’t need to be old-fashioned. A lot is going on, but it’s controlled and well-structured. They redo their website very frequently, so revisit this site in a few months for another variation of elegant simplicity.

Whenever I’m tempted to restyle a landing page (again), I revisit these. Before long, I usually conclude, “Ya know what, I kinda like it how it is.”

More

Rich Siegel interview (substack)

Rich Siegel explains how he works (usethis.com)

This idea originates from Lambda calculus, a mathematical system developed by Alonzo Church in the 1930s. Its impact didn’t extend beyond formal math until the late 1950s, when John McCarthy created Lisp, which treated functions as first-class objects. Soon after, linguistics applied lambda calculus to the semantics of natural language.

Now that functions are inextricable in programming, we rarely have to consider their origins. But think about it, whatever programming language you use treats functions as entities with the same status as other data types like integers, strings, or arrays. Treating functions as first-class citizens is what allows us to

• Assign them to variables

• Pass them as arguments

• Return other functions (func-ception)

• Store them in objects, lists, or tables

Without the ability to treat functions as data, we couldn’t have:

• Higher-order functions (.map, .filter, .reduce)

• Callbacks that run when an event (like a button click) occurs

• Asynchronous programming (async/await)

• Closures

• TypeScript

Programming at its best is building complex systems by combining simpler building blocks in a disciplined manner. It’s easy to glorify the builder or complain about the system’s complexity. But let’s also appreciate the simple building blocks that our predecessors gave us. Without them, modern software would be unthinkable.

BTW - Isn’t it amazing that we’re still coming up with new math concepts? Your great-grandpa lived in a world that couldn’t reason about functions and integers at the same level of abstraction.

AFK primitives

If “treat functions as data” is a simple building block that empowers programmers to tackle computer problems, what are some simple ideas that could empower programmers to tackle problems AFK?

Here are a few.

Move in a way that you enjoy. Box, run, lift, power walk, swim — as long as you’re moving, you’ll avoid the traps of this sedentary profession. Hunched posture, processed food, sleepless nights, chronic distraction, and social anxiety are enemies of movement.

Do something you believe in. Main characters have points of view and fight for them. NPCs believe whatever they’re told and accept submissive positions. Changing your character doesn’t require you to quit, relocate, buzz your head, or get another degree, though. You already possess one of the highest-leverage skills available (building robots), anyway. If you apply your skills to your beliefs, your aura will grow. As your aura grows, so does your ability to handle hardship.

Think with simple tools. You don’t need an LLM, a second brain, or Spotify Premium to clarify your thinking. A pocket notebook is enough. Take a walk to organize your thoughts, then write down the important stuff. The more you outsource your higher-order thinking to artificial tools, the less competitive your ideas. If you combine your unique perspective, experiences, and voice, then your thoughts become more singular. Thinking differently is differentiating in a world where everyone is asking the same two apps the same questions.

Got a building block you swear by? Reply here to LMK.

More

Lambda Calculus (wikipedia.org)

Ergo: a case study in approachable invention (keepsoftwaresimple.com)

minimal bullet journal setup guide (youtube.com)

Brian Beckman: Don’t fear the Monad (youtube.com)

The first lecture of my college English class taught me to survive as a software engineer.

The professor asked everyone to open their notebook and write down the following class guidelines:

1. Bring books to class

2. Late work is not accepted

3. Submit hard copies only (no emails)

4. If you come late, don’t come

5. Hold your pee

6. One person talks at a time

7. No neighbor idle talk

8. Don’t sleep

9. Take notes during movies

10. No cell phones

11. No texting

12. No computers

13. Sign in

14. No food (drinks OK)

15. Paper grades are based on 70% content, 30% editing

16. Grades will be returned promptly

17. Discussions & lectures are mandatory

18. No hoodies (see #8)

19. No extra credit

20. No absences

21. No cheating

My high school teachers warned us that college would be different. I assumed they were exaggerating to scare us into being quiet. I quickly realized they were just telling the truth. I glanced across the room and saw dozens of other wet-behind-the-ear students having the same realization.

Some scoffed indignantly, as if the professor’s standard was unreasonable.

Some looked defeated, as if they had already received a C-.

But a few lit up.

These were the future A-students. They came to college hungry for knowledge. They were excited that an authority figure challenged them, rather than admired their intelligence. They appreciated that he was also holding himself to a high standard (#15, #16).

The high standard offended the C students and inspired the A students.

You probably know where I’m going with this:

This phenomenon doesn’t stop after college.

Show me an engineer who reads a job description and complains, and I’ll show you a C-player.

High expectations threaten these people because they expect to coast without consequence.

The same expectations excite the A-players because they recognize that they need to get to improve.

What to do with this info day-to-day?

Depends what kind of student you want to be.

Are you good with modest improvements in skill, income, and influence? Do competition, candor, and performance metrics drain you? Do you need work-life balance? Then you can expect to get a C or B.

All good, I won’t shame you or try to convince you to go for an A. Just don’t fool yourself.

If you aspire for As, on the other hand, don’t let the C players bring you down. You might be in the same company as them, but the rules are different. They just need to show up and do the minimum. You need to do the most.

Practically, this means doing the functions listed on your job description and then doing part of another person’s job.

^ That seems crazy, but it works. Instead of trying to explain it here, I’ll just point you to my deep dive on YouTube.

I was hesitant to share this harsh message until I realized that silence comes at the expense of the aspiring A-Players. Every scoff from someone who doesn’t aspire towards greatness has the potential to discourage someone who does.

We need more A-Players in this field, especially now.

If you’re on the fence, it might help to know this last detail:

Although I was initially terrified by my English professor’s expectations, I decided to give it my all anyway. It was hard work, but I got an A. But this is the best part: We stayed in touch after the class ended. We initially chatted about books, then music, then life. It’s been fourteen years since that first lecture, and I’m so proud to say that my professor is now my best friend.

Takeaway:

A-Players attract one another.

If you want to surround yourself with exceptional people, you need to become one yourself.

While prepping to launch Compass Calendar v1.0.0 this week, I dug up my early designs from 2021.

(Yes, it took 5 years.)

(Yes, that’s insane.)

I couldn’t help but chuckle at what I saw.

I envisioned a superapp that’d support a plethora of data types: events, tasks, habits, reminders, tags, and routines. I wanted it to be as powerful as Notion, but less heavy-handed.

So I started coding.

Then I made every first-time founder mistake in the book:

• Stuffing it w/ features

• Ignoring feedback

• Using Electron

• Chasing VCs

• Wearing fleece vests

I built a bloated app that no one used.

Eventually, I looked in the digital mirror and thought:

“I gotta lose some weight.”

I spent the last seven months deleting, consolidating, uninstalling, and refining.

As a result, v1 does a lot less than v0:

• It only has events and tasks

• It only works on the web (not desktop, not mobile)

• It only syncs w/ GCal (not Outlook, not iCal)

• It only has two views (initially it had five)

But what it does, it does well.

In 2021, shipping something so lean would’ve embarrassed me.

In 2026, the product’s minimalism is what makes me proud.

That’s because along the way, I learned a priceless lesson:

Simple !== easy

Entering B&W gym felt like a Teenage Mutant Ninja Turtle scene. I descended hesitantly to the basement of an unmarked Chicago building. The air was heavy, sweaty. The pipes were exposed, the ceiling low. At the entrance was a Master Splinter-esce old man staring at a spreadsheet running Windows 7.

Instead of greeting me with a fake smile, he stared at me.

After a few seconds of silent eye contact, I told him I wanted to buy a month pass. He said it was $65, cash or Zelle. I told him I don’t have Zelle, and that I only had $46 cash on me. He said, “Fine, you can pay the rest next time.”

I handed the money over and waited, expecting him to take my picture on a USB webcam, give me a tour, talk about the personal training packages, or hand me a long waiver to sign.

Instead, he stared at me.

After a few seconds of eye contact, I asked, “Anything I need before I start?”

He said, “Just common sense.”

I worked out with the old yet functional equipment that commercial gyms avoid — metal plates are loud, and unbranded cable machines from the 90s aren’t as aesthetic as monotone NordicTracks.

On my way out, the man handed me a laminated card:

Name: Tyler Dane
Exp: 7/7/2026
N/R: N

He told me to hang it up on the sign-in board next time.

The experience was void of the pageantry and fake salesmanship that I had gotten so used to at commercial gyms. Master Splinter didn’t care about hitting a quota or guilting me into a customer success survey. He didn’t want my email for a funnel. He didn’t wanna hear about my weekend plans. He didn’t need me to download an app, create a profile, share my checking account routing number, or consent to a $120 initiation fee.

In fact, it seemed like B&W didn’t need anything from me at all.

Just hang up my card. Don’t break things or get hurt. Then leave.

After some research, I learned that B&W was founded in 1978 as one of the original powerlifting gyms. The guy who checked me in wasn’t Master Splinter. It was the owner, world champion bench presser Dennis Brady.

Things started to make sense.

This gym wasn’t built to optimize revenue or expand a global franchise. It was built to give lifters a place to lift.

Operations are so simple because everything except lifting is a distraction.

A gym built by lifters for lifters.

Experiencing that purity was more motivating than any polished commercial gym.

It’s gotten me thinking:

What would B&W look like in the digital world?

What would an app feel like if its developers were also its users?

How would a tech company feel different if it planned to operate for half a century instead of half a decade?

I’m still figuring out the answers, but I know one thing:

» Things would be simple.

Or just keep skimming this =]

These examples follow the playbook that Elon runs across his companies, officially called “The Algorithm”:

1. Question every requirement

2. Delete as many as possible

3. Simplify

4. Go faster

5. Automate

Last issue explained how Elon resorted to this playbook to solve bottlenecks at PayPal, Starlink, and SolarCity.

The same framework also works proactively, as we see with Tesla’s Optimus robot.

The one requirement Elon mandated was that it should resemble a human. But the designers, already students of The Algorithm, knew to eliminate. When designing the hand, they initially tried to omit the pinky, which seemed like overkill. They quickly realized that it made the robot too creepy, so they added it back.

This satisfied Elon’s corollary that 10% of eliminated parts should be added back (otherwise you’re not cutting out enough).

Estimating costs early also helped the team surface unnecessary complexity. When they reported that the actuators for the wrist would balloon costs by 54%, Elon pushed back hard:

"This is a shitty design. Use the damn lift gate actuators from our cars, which we know how to make cheaply.”

They eventually settled on a more refined design that included two finger joints (not like our three), two degrees of wrist rotation (unlike our three), and cheaper parts.

Takeaway for engineers

It’s never too early to push back against complexity. Although many of the Optimus meetings indulged in distant-future planning scenarios (like robots on Mars), Elon used cost to bring things back to earth.

We engineers usually don’t have as much visibility into costs, but we know how long things take. So when a PM proposes something complicated to placate a demanding client, it’s on us to push back about how much time that extra feature will take. Even better: explain how the real solution to going faster is not to add more parts, but to remove them and prevent more from being added so carelessly.

More

Elon keeps it simple (fullstack.zip)

Elon Musk, Walter Isaacson (amazon.com)

How Elon Works, Founders Podcast (youtube.com)

Or just keep reading =]

How Elon protects simplicity

Elon created “The Algorithm” as a playbook to accomplish great things quickly at low cost. It goes like this:

1. Question every requirement. Requirements are recommendations. The only immutable ones were those decreed by physics.

2. Delete any part or process you can. You may have to add them back later. In fact, if you don’t add back at least 10% of them, then you didn’t delete enough.

3. Simplify and optimize.

4. Accelerate cycle time. In other words, “Go faster.”

5. Automate.

Remove, simplify what remains, then automate the process. It seems trite in the abstract, but a few examples will show how radically committed Elon is to this philosophy in practice.

During the early Paypal days, opening a financial account required the user to fill out long forms and hand over their SSN and address. Elon rewrote his site to get the fewest number of keystrokes to open an account by eliminating those forms and even the requirement to have a username (using email as the userid).

When Starlink’s satellites became too bulky and expensive to manufacture, Elon fired the leaders and led marathon meetings to challenge every little requirement. A rat’s nest of parts was turned into a simple flat satellite, and costs decreased by orders of magnitude.

Life got way easier because we culled those parts. I was too chicken to propose that, but Elon made us try it.
— Mark Juncosa, Starlink

When SolarCity’s panels lagged, Elon fired the leaders and eliminated the requirement that they must work around every vent and chimney pipe. Instead, they decided to shear them off and put the panels on top. The 240 roof parts were halved. The website was simplified to offer just three roofs: small, medium, and large.

When SpaceX’s Raptor engine proved incapable of a Mars mission, Elon instructed his team to focus on a lean design, one reminiscent of a gnarly post-skinned cat. He suggested some extreme ideas, like deleting the whole gas manifold and booster skirt. Then he emphasized his commitment to leanness with a flurry of emails.

We are on a deletion *rampage*!!

Nothing is sacred. Any remotely questionable tubes, sensors, manifolds, etc. will be deleted tonight. Please go ultra-hardcore on deletion and simpli cation.

Takeaways for software engineers

There’s a clear pattern throughout the book: When Elon sees a bottleneck, he removes rather than adds. Instead of adding more employees and materials, he fires people and removes parts.

This instinct is worth appreciating for us engineers, who have gotten used to adding with impunity. When a senior engineer imports a library, adds a framework, and integrates with a third-party, no one blinks an eye. Code is cheap, and it’s only getting cheaper.

But just because adding lines of code is easier than adding rocket ship parts doesn’t mean it’s free. There is a cost to every abstraction. For us, that cost is time. It takes time to dig through convoluted business logic, to wait for long CI runs to finish, and to tiptoe around a brittle part of the codebase.

When things become bloated, slow, or pricey, we should resist the urge to optimize and instead question whether we need the thing in the first place.

Removing abstractions, imports, and requirements will poke some egos, but so will becoming a team that’s incapable of shipping anything good.

More

Elon Musk, Walter Isaacson (amazon.com)

How Elon Works, Founders Podcast (youtube.com)

What people don’t know is that his books are written on a DOS machine running WordStar 4.0, a VBA word processor that dominated in the 80s thanks to its portability and WYSIWYG interface. Slow revisions, kludgey code, and corporate drama slowed progress long enough for Word to dethrone WordStar as the corporate standard. After a failed merger and relaunch, WordStar was officially abandoned in 1992.

So why does he still use it thirty years later?

Because it works.

It does everything I want a word processing program to do, and it doesn’t do anything else. I don’t want any help. I hate some of these modern systems where you type a lowercase letter and it becomes a capital. I don’t want a capital. If I wanted a capital, I would’ve typed a capital. I know how to work the shift key!
— GRRM.

Lessons

George’s preference for less is refreshing in an era obsessed with more.

Young carpenters might lose some sleep researching the benefits of Milwaukee vs DeWalt tools, while mechanics compare Gearwrench to Ryobi. But then they wake up, buy a set, and use those tools until they die.

We digital craftsmen, on the other hand, will try five IDEs and LLMs in a week. It’s easy to rationalize this schizophrenic adoption as an attempt to keep our skills sharp. But that mindset reveals a mistaken understanding of our role in the world.

It’s not about the tools, it’s about what you create with them.

Carpenters translate ideas into houses. They can do that with a nail and hammer, or a cordless track saw with an attached vacuum bag.

Writers translate ideas into words. They can do that with a DOS machine running WordStar 4.0, a phone with the Notes app, or pen and paper.

Coders translate ideas into code. They can do that with an agent window, vi and a keyboard, or ChatGPT and their voice.

Examples

Pieter Levels continued to write plain HTML, CSS, SQLite, and PHP in Sublime Text long after VS Code became the standard IDE. His friends made fun of him for his outdated tools. His followers pointed out the superiority of TypeScript and Docker. Yet he focused on his users and products long enough to generate $3M ARR with an ancient stack.

René Rebe codes in a single terminal with vi and basic motions. That elementary setup helped him focus on the code long enough to write a USB driver from scratch in three hours.

$LOUD_ENGINEER_ON_X uses NeoVim, configured through LazyVim, with a fully customized setup that auto-provisions via dotfiles managed by Chezmoi, stored in a private self-hosted Forgejo Git server running on a home Kubernetes cluster. His workflow is so “optimal” that he sells a course to young engineers on how to replicate it. (He hasn’t shipped anything helpful for normal people in years.)

Which type of engineer do you want to be?

If you want to be like the last engineer, then keep jumping on whatever new VC-backed tool shows up on your feed this week.

If you want to be like the first two, your path is much simpler:

1. Use simple tools that do a few things well. Really, just pick any IDE, calendar, task app, and OS and don’t overthink it.

2. Keep using that tool until it breaks or your craft suffers.

“BuT tEcH mOvEs So FaSt. I nEeD to sTaY rElEvAnT!”

Yes, occasionally a truly innovative tool appears that is so superior it’d be questionable to resist it (think: computer vs. typewriter). Between those paradigm shifts, a constant stream of “new” tools appears, each overhyping its benefits, downplaying its costs, and distracting you from your craft.

You’ll know when a paradigm shift is happening, and you’ll have plenty of time to transition. You’re not jeopardizing your career by moving to the right of the adoption curve.

The real risk is maintaining a greater allegiance to novelty than to your craft.

When GRRM’s old computer finally died, he had his assistant build a state-of-the-art computer for him….so that he could run DOS and WordStar 4.0.

WordStar shipped seven versions after 4.0. Instead of using this computer upgrade as an opportunity to try the latest version from 1994, he stuck with the 1987 program that he already mastered.

One of the most successful living writers demands simplicity. He wants his tool to do a few things well and let him handle the rest.

Let’s make George proud.

Close social media.

Open whatever IDE you’re already used to.

And get to work.

More

Interview with James Corey (lightspeedmagazine) | GRRM’s assistant

The best engineer doesn’t have the best setup (fullstack.zip)

A Tour of Word Star 4.0 (youtube)

WordStar (wikipedia)

The simplest $30k playbook

It was called “Bootstrapping Your E-Commerce Empire Side Hustle With No Money,” led by Jonathan Spaulding. He walked us through how to find a niche, set up a no-frills store, and ship, all without spending a nickel.

There were some pragmatic cost-saving tactics, like 3D-printing custom products and offering only small items to minimize shipping. What I enjoyed the most, however, was how simple he kept his operations.

His go-to-market involved walking around his house with a cardboard box, adding things that he didn’t need, and listing them on eBay that day.

For market research, he asks coworkers what small items they recently bought and makes them for less with his 3D printer.

To fulfill orders, he gets a bundle of USPS boxes and puts them in his home mailbox.

For support, he responds through the eBay mobile app during downtime.

However indignant the e-com gurus may feel about these elementary strategies, they work for him. This side hustle nets Jonathan $30k of yearly profit.

That headline isn’t going to make him HackerNews famous. But so what? That’s a year’s tuition. Runway for a startup idea. $66k in 10 years at 8% growth. An epic vacation. Enough Claude credits to create a custom C compiler. It also fits his lifestyle by allowing him to work from his phone and stay home with his family.

Why simplicity sells

Our feeds are so good at convincing us that we need more information before we’re ready to do things in the world. We need to watch the next video, finish the course, or get a few more years of experience before starting something new.

People like Jonathan prove them wrong.

You can just do things.

Yes, right now.

Really, it’s that simple.

Not easy, but simple.

This is especially true for engineers, who have more agency than ever. We don’t need to learn a new framework, refactor the API (again), or wait around for a job offer.

We just need to walk around our metaphorical house with our metaphorical cardboard box and sell things to people who want to buy.

There are two ways to be loved as a software engineer:

1. Solve the most complex problems so others don’t have to

2. Make complex problems simple enough for regular engineers to solve themselves

The first path is for master craftsmen maxxing out their engineering skill. The second is for those who enjoy teaching as much as coding.

Let’s look at a few examples of the second type of person.

Jeff Delaney & YouTube

Jeff Delaney is the man behind the Fireship, a YouTube channel for devs with over 4M subscribers. Although the videos are well-produced and sprinkled with the dry jokes devs enjoy, there is a deeper reason why developers love the channel: It makes them feel smart, quickly.

After watching a regular technical video, I often feel even more overwhelmed than when I started the video 20 minutes earlier. Jeff’s videos, on the other hand, are so straightforward and down-to-earth that I actually understand the core idea. His flagship 100 Seconds of Code series, for example, makes CS topics like Big-O notation and GraphQL feel refreshingly approachable.

Jeff probably isn’t the best engineer, nor does he try to be. Instead, he combines his “good enough” engineering with a world-class ability to cut out complexity.

I always ask myself, ‘How much can I cut out of this video and still teach the concept effectively?’

I try to distill the concepts into a very potent shot of whiskey.

— Jeff Delaney, creator of Fireship

Rich Hickey & Clojure

Rich is a great engineer — he created the Clojure language after all. Instead of trying to become an even better engineer for its own sake, though, he spends a lot of time teaching others. During the first few years after Clojure’s launch, Rich went on a conference tour, spreading the good word about the language. In his classic Simple Made Easy talk, he defined the problem of complexity so well that a generation of programmers started valuing simplicity.

Rob & CS

I felt imposter syndrome during my first two years as a junior engineer. During that time, our lead engineer, Rob, gave lunch talks about engineering. He’d whiteboard draw simple diagrams about the basics of computing: transistors, data structures, the difference between OOP and functional languages. Every time I’d walk back to my desk with a lil’ pep in my step, because for just a few minutes it felt like I understood what was going on and that I belonged. That’s why everyone loved Rob.

If you’re the type of engineer who wants to balance both hard and soft skills, consider teaching your peers. We reward those who make things simple: they make the world less scary, which makes us feel more capable. Whether in a PR review or a big conference presentation, the most popular message will be the one that shows the audience that they have more agency than they realized.

You’re a non-technical founder selecting between two Founding Engineer candidates. This hire will be responsible for creating your MVP, scaling the engineering team, and solving the hardest technical problems along the way. They’ll set the bar for engineering excellence, and everyone will try to mimic how this person works and thinks.

You shadow both candidates for a day while they work on a passion project. Although you won’t understand the details, you’re hoping to observe their workflow and the tools they use, since they’ll likely set something similar up for you.

Engineer 1

This engineer runs Fedora on a Framework laptop, with Sway as his tiling window manager, but tmux layered on top as a second window manager inside the terminal. His editor is Neovim, configured through LazyVim, with a fully customized setup that auto-provisions via dotfiles managed by Chezmoi, stored in a private self-hosted Forgejo Git server running on a home Kubernetes cluster. All development happens inside dev containers via DevPod, so there’s always a container runtime running.

Every tool is picked to keep workflows in the terminal and on his hardware. He uses w3m as a terminal browser to avoid trackers. He uses Aerc for email, an open-source terminal client. He also operates his own databases. Claude is kept in a container so Anthropic can’t see his notes or dotfiles.

His setup lets him sit down at any machine and be fully operational in minutes. As the owner of a DevOps education business, his workflow also demonstrates to prospects what’s possible if they commit to privacy and the terminal.

Engineer 2

This engineer works in a single, full-screened terminal. He uses vi with only basic motions and no syntax highlighting. His “workflow” involves changing the default font to Comic Sans.

He’s decided that he needs a USB driver for his kernel. He starts by googling “apple xserve frontpanel usb driver github,” scans the repo, and concludes, “Ja, this is super simple” (German accent).

He starts by copying and pasting Linux kernel code, mumbling in C, and sipping espresso. Thirty minutes in, he leans over to boot up the physical server next to his desk, which hums loudly for the rest of the session. Then he starts writing his own code. After 2.5 hours, he calmly reports back, “So, ja. It works. The future is now.”

My pick

I’m going with Engineer 2. He gets it. It’s not about fancy tools or impressive workflows that require a paid course to understand. It’s about shipping software. If this guy is comfortable raw dogging C in vi without any AI, I’m comfortable trusting him with the codebase.

The people on YouTube agree:

“I trust this man with my life.”

“This guy is not getting replaced by AI.”

“Writing code without syntax highlighting is demon level.”

“This is engineering.”

“Every time he says ‘Yes, of course,’ I just nod along. ‘Yes, of course.’”

To be fair, I straw-maned Engineer 1 big time. He’s a DevOps pro with serious credentials. Comparing his workstation demo to a C programmer’s live stream is apples to oranges. But by Engineer 1’s own admission, his system is elaborate. After all, it took him 70 minutes to explain how it all works. There’s a coherent philosophy of protecting privacy and flow state underneath it all…but it’s still a lot.

Solving meaningful problems for customers will bring plenty of necessary complexity. I want to work with people who are content to keep everything else simple.

Who you picking? Reply to LMK.

More

Watch Linux kernel developer write a USB driver from scratch in just 3h for Apple Xserve front-panel (youtube)

My Entire Neovim + Tmux + AI Workflow (2026 Update) (youtube)