Announcing The Thinking Builder Book
Letters on common sense in the age of thinking machines
For the past year, my dog and I have been writing a book in secret. One hour every single morning, and we're finally done. I haven’t mentioned it to my friends, not even to my mom.
I wanted to write The Creative Act, but for programming.
The Pragmatic Programmer, but with a more philosophical tone.
A Ryan Holiday-esque technical book you can turn a few pages from every morning.
An equivalent to Seneca’s letters to Lucilius, but from me to an imaginary friend in tech.
This is how I came up with The Thinking Builder.
It contains 60 short letters (300-500 words) about the habits of good builders in the age of thinking machines.
I intentionally use the word builder as a catch-all term for all the developers, designers, and founders who are finding their way.
It’s not a guide.
It’s the things I’ve noticed the good builders around me do.
And my dog and I would love it if you give it a read ❤️
Links
Letters from the book
Beware, this is a weird book… I have used a very specific phrasing that you don’t see in technical texts.
It’s definitely not to everyone’s taste.
To get a feel of my writing in this book, here are three of my favorite letters from the book. If you like them, you will like the rest.
1. The Thinking Builder Strives to Be Good, Not Great
They know they may be above average on a good day, but they want to be more. They want to be better. They are the person who cares too much about what they do.
Being exceptional at any craft is a result of many forces, some of which are outside our control. Our environment, our timing, our upbringing, the people we happen to meet, the problems we happen to encounter - these shape greatness as much as talent or effort do. We can do everything right and still not reach it.
But we can control the work we put in, the care we bring to it, and the standards we hold ourselves to.
The thinking builder knows they cannot be great and have a life at the same time. Exceptional results demand a long-term commitment that often turns building from a profession into a lifestyle. Builders who want to be great sacrifice relationships, health, and the colors of life itself. They give up other hobbies and pursuits to tunnel vision on one specific craft.
There is nothing wrong with that choice, but it is not the only one worth making.
The builders with families, the builders with busy evenings, the builders who have aspirations outside their work - the engineers, the designers, and the founders who love their craft but cannot spend every waking moment in front of a screen - they may not sit among the greats, but they can become good builders who make the world better through their work.
There is immense fulfillment in being good, even if it is only a stepping stone to greatness. Even if one decides they’re ready to work for greatness, they must first become good. No one skips this step.
Good is not a consolation prize. Competence, care, professionalism, and completeness are virtues worth pursuing.
Building software is a form of building interactive art. Practical interactive art. With enough time in the software industry we forget what a marvel it is to be able to create something from nothing, from an empty file to a script that works for you. The builder can use their skills in every job, field, and industry to make their life better.
In fact, more people are building than ever before. The digital world is wide open. Engineers and designers are no longer the sorcerer gatekeepers they once were. The barrier to creating something has never been lower. But the barrier to creating something good has never changed.
Good still requires judgment, taste, and the willingness to think beyond the first solution that works. Good means the software does not just function but solves a problem. The design does not just look beautiful but guides the user.
Not everyone can be great, but anyone can be good.
The Thinking Builder Knows That Priority Is Binary
Something either matters right now, or it does not. There is no middle ground. There is no “low priority.” There is high priority and there is nothing.
Organizations love granularity. Five levels of priority. Color-coded labels. Matrices with axes for urgency and impact. These systems feel productive because they give every item a place. But giving something a place is not the same as making a decision about it.
It seems so logical.
Builders can work on tasks in order of priority. Start with what is urgent, then go down the backlog. If something more urgent appears, they can return to it and pick up “low priority” tasks during downtime - a holiday code freeze, a slow sprint.
Labeling a task “low priority” feels like a decision. It is not. It is a way to avoid making one. It is a polite way of saying “we do not want to say no, but we do not want to do it either.”
The task sits in the backlog, gathering dust, while the product moves on without it. By the time someone revisits it, the world has changed enough that the task no longer makes sense. It was never going to get done, but no one had the courage to admit that at the time. Low priority is where scope creep goes to live quietly.
Open your backlog and find those low priority tasks that have been sitting there for months. How many are still relevant? How many are still needed?
Backlog pruning sessions exist precisely for this - to surface the tasks that were never really needed.
The good builder would rather hear “no” than “low priority.” A “no” is honest. It frees you to focus. A “low priority” is a false promise that clutters the mind and the board alike. Priority is not just a matter of what label we put on the task. An honest backlog enforces discipline and clear thinking - we can’t keep adding future work endlessly.
The thinking builder knows that the high priority label is a dangerous tool as well. Once everything is urgent, then nothing is. Priorities work only if urgency is applied with care and only when needed.
Products are not built like puzzles. They are built like paintings. There are layers, and the parts are connected to the whole. When you treat development as a conveyor belt of independent tasks - each one ranked and queued - you lose sight of that whole.
It shows in the implementation. Tech debt accumulates. Architecture becomes a matter of chance rather than intent. It shows in the design. Screens feel stitched together rather than planned.
That is what “low priority” does to a product.
The good builder knows that some things take precedence over others.
But everything else is equal.
The Thinking Builder Does Not Need the Room to Notice
The industry has built a whole mythology around the builders who give talks, ship side projects, rack up followers, and turn their job title into a personal brand.
We have confused broadcasting with building.
Jimmy Iovine once said that the number one reason music is not as good anymore is that musicians want to be famous, not great. And now you can get famous without being great.
The same disease runs through software.
There are builders who optimize for recognition. They work on things people can see, they articulate their impact loudly, they know how to perform the role. They are not frauds - they produce real work. But they value applause more than good work.
And then there are the quiet builders.
They fixed the thing that was silently breaking for months before anyone noticed. They wrote the documentation that helped their junior colleagues get onboarded. They absorbed the chaos of a hard quarter so the team could keep moving. These things often don’t make it to the performance review.
The quiet builders may fix a performance problem when they have a free afternoon just because they know it is right to do so. Their work will slip by unnoticed while everyone reaps its benefits. The loud builder, on the other hand, will wait until the next all-hands meeting to present their solution and market it as a massive improvement regardless of how small the fix was.
Career ladders were not built to see the quiet builders.
Silently preventing a crisis will not give us recognition. Solving a crisis once it arises will. The quiet builder fixes problems before they become projects, which means the project never exists, which means there is no evidence of their contribution.
We never notice the best software we have ever used. Good technology becomes invisible because it solves a problem so well that using it feels natural. We never stop to think about the people who built it.
The builder may occasionally participate in performance theater to reap the rewards of their work. But they do not let it take focus away from the act of building, because that produces better work than any amount of self-promotion ever could. They want to be distinguished, but they do not yearn for fame. There is a difference between the two.
If a quiet builder becomes a manager, they learn to notice the other quiet ones. They take care of these people because they understand that those steering the ship are too busy to take credit for their work.
The thinking builder has made peace with this. They know their work will speak for them. Maybe not today, maybe not to the people who decide their salary, but to the people who depend on what they have made, and to the engineers who will one day open their code and find it clean and considerate and honest.
That is enough.