Learn to build your own tools

It’s worth it to learn to build your own tools. If you don’t, the only tools you’ll be able to use are those that someone else made, created a company around, then brought to mass market (henceforth, “the song and dance”).

That’s a herculean task, even for software tools which are the easiest to do all that with.

But just because someone didn’t do the song and dance (or failed at any of the infinite points to do so along the way, possibly even due to sheer bad luck) doesn’t mean that tool couldn’t exist today and be actively improving your life, right now.

There is a mind-boggling effort difference between making a prototype product that provides value today, and productionizing that product for the mass market and doing the song and dance.

Prototype products which are only ever used by the creator (i.e. expert user) for utilitarian reasons don’t need to have clean UIs, graceful error handling, or intuitive, consistent, and discoverable UX. They just need to kind of do the job.

The unreal effort required for mass market means that the actual products on the market today are only a tiny subset of the actual products possible in the world now without a technological breakthrough.

You, personally, would probably benefit from some of both sets of products; some that exist today on the market, some that could but no one did yet. Some of the latter might have even been game-changing for you.

But if you know how to build your own tools, you can access that superset of possible products today. Even if it’s just prototype quality tools, that might be good enough.

I’m talking mostly about digital tools but argument applies to anything. What I find especially interesting is how trends in technology continually decrease the effort to build prototype software. This used to require code. Then no-code came around. And finally AI generated code is here. People at large already do this today with tools like Excel, but I wouldn’t be surprised if many more people in the future are using bespoke one-off prototype mobile apps, desktop apps, and web software they’ve built for themselves to solve specific everyday problems.

Personally I do this a bunch already using code and no-code solutions:

And a few no-code apps I’ve built for myself using AppSheet:

  • Personal metrics tracking app
  • Simple personal finance and budgeting app
  • Simple personal CRM

I’ve also created a custom calendar in Google Sheets which has really improved my life in 2023. Maybe I’ll write about that later.

Life is a business; life is a game; life is art

Here are three ways to view your life:

Life as a business

Life is a business, and you are the Founder & CEO.

You have goals, resources, and agency. The idea is to build the strongest business and life for yourself. You do this by making good decisions and generating profit.

The most savvy founders look for holes in the fabric of society, the market, their industry โ€” and exploit them. They seek trends that allow them to be ahead of the curve.

Life as a game

Life is a game, and you are a player.

You are initialized with random parameters that inform your strengths, weaknesses, and initial environment. There’s an endless world in front of you to explore and play in.

The idea is to do well at the game โ€” build points, power, connections. You encounter other players, transact with them, exchange moves, determine if they are trustworthy or hostile.

You learn the rules over time and understand what game you are even playing. You discover that within the greater context of “the game”, there are many sub-games you can play.

Randomness and luck are all built into the game.

Life as an art piece

Life is an art project, and you are the artist.

You have a blank canvas in front of you and an infinite number of creative decisions to make. The idea is to find a beautiful & satisfying creative endpoint for your piece.

There are many creative paths to take, leading to different ends. There is no best end, but some ends are better than others.

Like any other artist, you must apply techniques to manage the decision space. You apply constraints โ€” sometimes artificially, sometimes destructively โ€” to move forward.

Art/Artist Fit

Product/Market fit is when you’ve made a product that people actually want.

Product/Founder fit is when your product is a good fit for you, personally, as a founder.1

Art/Artist fit (something I just made up) is a generalization of Product/Founder given the point of view that products are art and making a product is an artistic practice.

Given that art is a reflection of the artist, it makes sense that certain kinds of art will be more or less natural for someone to make, given their personal inclinations.

A few examples from the wild:

In this episode of the Art of Product podcast (1:11:00), Adam Wathan talks about how a subscription-model content business isn’t a good fit for him, while it is a good fit for a friend. Adam doesn’t like the idea of “being on a treadmill” to constantly create new content for the subscribers but conversely his friend appreciates the continuous dopamine hits as opposed to a longer 4 month long effort to create something like an e-book or course.

Next is from Dan Luu, one of my favorite bloggers:

[Paul Graham’s writing] uses multiple aspects of what’s sometimes called classic style. […] . What that means is really too long to reasonably describe in this post, but I’ll say that one part of it is that the prose is clean, straightforward, and simple. […]

My style is opposite in many ways. I often have long, meandering, sentences, not for any particular literary purpose, but just because it reflects how I think

Dan Luu, https://danluu.com/writing-non-advice/

Last is from Kareful, one of my favorite musicians:

“does anyone have tips for finishing a song? these days i can only write the intro and 1st drop, and i can’t get passed this point” – Vavn

Maybe you’re not meant to write long music, I also had this discovery recently, now all my tracks are around 2 minutes, but I find this means I now finish 3/4 tracks a week.

Kareful

Personally, I find short, several-paragraph posts about a specific thought very much a fit for me right now. This blog started in a very different way, doing long, deeply technical researched pieces which were a fit for me at the time (gap year) but no longer are.

Musically, I loved hyper-technical electronic music production ~2020 (also during my gap year) but recently have been doing simpler, more “beatsy” music.

Personal projects are like free weights

I thought of this 7 years ago and I still think it rings true. In my experience, school projects were tightly scoped and had things like a basic build system and boilerplate runnable code (e.g. main) already provided. Maybe even some tests. It trains a specific muscle in a certain way.

With personal projects, you do all of this yourself and incidentally also train the equivalent “stabilizer” muscles. Things like: making the repo, writing the main and boilerplate code, setting up unit tests, setting up CI, setting up dependencies and their management.

And in my experience, it’s all these “stabilizer” activities that define what it means to be a senior engineer. Junior engineers work within an existing project; senior engineers own the entire thing, including these “little” (critical) parts.


The point here isn’t to necessarily criticize CS education; there are good, practical reasons for setting up such project structure to ensure all students have a good experience, given the time constraints. The point is that students should be wary of not doing any personal projects at all throughout a CS education. Maybe it would be possible so students don’t have to do this in their free time, and build it into some kind of flexible course. I suppose this is the point of final capstone projects, but I think senior year is far too late to be doing this for the first time.

Creativity is like gardening

I see a strong parallel between creativity and gardening. Like a fruit, growing from seed to ripe, ideas do the same.


Idea seeds are those vague, half-formed thoughts that quietly appear in your mental space. They occupy a strange state where you are aware of them, but would struggle to write them down or explain to someone else coherently. That is the defining characteristic of an idea which is not mature yet.

Slightly more mature ideas are in the growth phase. They form of the idea has started to emerge, and you can half-express it, but there might be logical errors as you still haven’t fully thought it through yet.

Ripe ideas are fully developed and can be coherently expressed with the fewest words necessary.


Ideas can grow along this path explicitly or implicitly. You can explicitly grow ideas by sitting down and trying to write them. Or they can grow implicitly in the background as you live your life and expose yourself to experiences and other ideas.

Sitting down to write an idea is like trying to harvest it. It’s easiest and works best when the idea is ripe โ€” the idea will almost pour out of your brain onto the page in this case. If you try to harvest an idea before it’s ripe, it will be harder.

The analogy might break down slightly here. With ideas, the act of trying to harvest them actually accelerates their journey towards ripeness. Trying to express an idea forces you to understand it better and clarify it. This is one way of growing an idea: the explicit way.

Ideas can also grow implicitly. They can quietly sit on your mental back burner as you live your life and expose yourself to experiences and other ideas. Maybe another idea acts as a bee that pollinates the first idea and together they form a complete, ripe idea. But in order for them to be able to safely sit on the back burner as long as it takes, they should be still captured in some kind of way, or else you’ll probably forget them.


Note that an idea’s state of being written down vs in head, and public vs private are each orthogonal qualities. Ripe ideas aren’t the only ones that can be written down and published. Idea seeds can still be attempted to be written down (although it will be hard), and also published.

A lot of my friends have been sucked up into UFOs lately

A lot of my friends have been sucked up into UFOs lately
I’m happy for them
at least i try to be

I want to be sucked into a UFO too
Iโ€™m working hard at it
at least i try to be

we didnโ€™t think it could happen
but then it did
took about ten years

then again
and again
it wasnโ€™t a fluke

iโ€™m happy for them
at least i try to be

itโ€™s not always easy
but i try to be more proud than envious
more inspired than jealous
but i have a confession

i write this from a UFO
yes, i got sucked up too
in my own special ufo, in my own way

i once dreamed of it
but now itโ€™s not enough
i want a bigger, newer one

maybe I should be more grateful
iโ€™ll try to be


This poem was inspired by watching people in various areas of my life achieve incredible success. Y’all rock and I look up to you.

The difference between computer science and computer engineering

I first wondered this question as a confused 17 year-old, considering options for university โ€” this blog post is for that kid and people like him. It’s my opinion on this after working professionally in both fields and earning a degree in one them (CE).

I think tracing each back to its roots is a good way to gain an intuition for the difference. Computer Science is ultimately derived from Mathematics, while Computer Engineering derives from Electrical Engineering.

The boundary is blurry, but CS is classically more concerned with topics like algorithms & runtime (“Big O”), data structures, and the theory of computation (“What kinds of problems can we solve with computers, what kinds can’t we?”). You’ll do many more formal proofs in CS.

CE concerns itself more with how digital computing systems work in the real world, starting from foundations in electronics (i.e. transistors), to digital logic, building up towards embedded systems, the hardware-software interface, and computer architecture. The latter is where things get blurry and bridge to the “lower levels” of CS.

In practice, most practitioners of either have some awareness of the other, although I suspect (without evidence) that CE’s tend to know more about CS than vice-versa, on average. However I also expect that CE’s tend to write “worse” code than CS’s, on average โ€” “writing good code” and “knowing CS” do not necessarily correlate. 2

So which should one choose?

I can only offer this scattered set of anecdotes and advice:

  • I knew many more CE majors that switched to CS, than the other way around. (Mostly people that just wanted to become “programmers” and realized that circuits & electronics are not for them. I’m not sure if they enjoyed the theory courses more, though.)
  • I have heard and personally agree that it’s easier to go “up” the stack than “down”.
  • Don’t give any experience building computers or doing IT support too much weight in the decision โ€” those topics are neither CE nor CS and rather fall into the field of “IT” which is largely separate. You might be surprised how possible it is to study either CE or CS, work in these areas professionally, and not know how to physically build a computer. But in general, building a computer falls closer to CE than CS โ€” but you will be learning how to design (some of, at a very high level) these lego pieces you are putting together.
  • Personally I’ve always been foremost curious “how computers actually work” and CE has served me well.

Lastly, what about “software engineering?”

Software engineering is an even newer field, derived from Computer Science, but describes the job descriptions of many (if not most) people that study either CS or CE. My view of it is that a degree in it focuses on the most practical elements of CS, focusing less (or not at all) on the theory. I don’t expect much of CE is covered it in, except for maybe a cursory overview of digital logic and computer architecture. But frankly, I don’t know any software engineering majors and am not qualified to really speak on this.

How did you choose between them?

Not rigorously. My decision was mostly based on the presence of other “engineers” in my life and a friend that studied CE. These were not good rationale for the decision, but I lucked out and had a good outcome anyway. I think I would have been fine either way, and naturally gravitated up or down the stack to the point I’m at now. Being CE did allow me to take some very cool classes in college like a very modern, practical compilers course using LLVM (unlike the more theory based compilers course taught in the CS school) (which had a direct impact on my ability to get a great job after) and a fun embedded systems class.

Memory is an abstraction

I was learning about the different types of RAM recently (e.g. SRAM and DRAM) and it occurred to me that “computer memory” is just an abstraction. This is obvious once you think about it but I think as a programmer, it’s very easy to not realize this. The idea of memory as a linear array of bits is an abstraction created and implemented by an electrical device.

Most programmers when they think of memory are thinking of virtual memory, which is a completely different abstraction. While it’s also a linear array of bits, the abstraction is created by the operating system and lives at a higher level.

One level below, the abstraction the operating system itself uses โ€” “physical memory” โ€” is the one I’m talking about, created by a a set of electrical devices connected to the CPU with wires (the memory bus).

I’m projecting without any basis, but I presume the reason so few programmers think of memory as an abstraction is because the abstraction is so strong. Nearly all of the time, it “just works” โ€” you write bits and read them out later.3 The abstraction can leak slightly during programming disciplines that require awareness of low level details like the memory hierarchy and cache coherence (i.e. lockfree) but this is a leak of the abstraction of the memory hierarchy. The core abstraction of physical memory stays in tact โ€” for example, programmers never need to be aware of the internal refresh mechanism of DRAM.4

Of course, you can go infinitely far with this โ€” it’s turtles all the way down.

Sometimes, you just need to be willing

Sometimes, you just need to be willing. No special skills or particular competence necessary โ€” simply just being willing to do something others can but won’t do.

I learned and have profited from this realization at work in the past year. A certain set of important tasks on my team are somewhat hands-on in nature and not compatible with remote work. Our colleague that usually does these left the team. I stepped up and filled this gap.

The work is not particularly difficult โ€” my teammates are smarter than me and could surely do it also. But I’m the only one that was willing and able to sacrifice remote work and commute every day. So I’ve been doing it.

Although it’s not the hardest, the work is nonetheless very important โ€” critical, even. So I’ve been getting a lot of credit, brownie points, and even a raise from doing it.

Not because I’m smart โ€” just willing.

Reflections on learning to write

For the last three years, I’ve invested into learning to write. The main reason: strong writing skill is generally a shared quality among all the greatest thinkers, leaders and generally wise people of history.

How has it gone?

Really well. It’s paying off in many ways, and I only feel more inspired to keep doing it. I find that it gets more fun then more you do โ€” the more ideas you have and the easier and faster it is to express them.

It’s paid off in my personal life with my offlinemark project. My writing (and general public creative efforts) has reached some unexpected places and put me in touch with some very interesting people. My most prized accomplishment is being cited in the Linux Kernel security mailing list.

It’s paid off in many ways at work. As a software engineer, I do a lot of writing at work, and I pride myself in having great written communication there. I write a lot of documentation, hold it up to a high standard, and people notice. I get points for this because most engineers don’t like writing docs, but I’ve trained myself to enjoy it.

Beyond these, modern life generally involves a good amount of written communication. I’ve found that putting in these reps has simply made this part of life a bit easier.


P.S. Something else I’ve observed is that I find myself having more ideas and being more aware of them. Whether they’re good or insightful is a different matter, but I’d like to believe that over time they’ll get there.