Category Archives: _Micropost ๐Ÿช

Distance between application programming and standard library programming

This is a rough, potentially half-baked thought:

This might an interesting metric to compare programming languages: distance between application programming and standard library programming.

In general, standard library programming is more difficult than average application programming for any programming language. Or at the very least “different” in some way — language features used, programming style required, etc. That difference might vary depending on the language.

Mainly, I’m thinking about C++, where standard library programming requires expertise in C++ template meta-programming (TMP) (i.e. to implement std::variant), which is effectively an entirely different programming language, existing in the C++ type system. While many application developers may also be competent in TMP, there are many that aren’t (including myself). It’s possible to be a very productive C++ programmer, and STL user, without being an expert at implementing generic libraries using TMP.

Given this, my impression that C++ has a relatively high distance between application programming and stdlib programming.

Python of course also has some distance here. I’m not qualified to speak on it, but I can imagine it also involved more obscure language feature that do not occur often in normal app development. I would guess that this distance is less than C++.

Lastly, C is an interesting language to consider because it offers such a spartan feature set that there aren’t particularly that many more language features available to be used. (I’m probably wrong here and there are obscure things I’m not aware of, including symbol versioning for compatibility). But in general, my assumption would be that C has a some limited distance, given it’s restrained feature set.

Ultimately, this metric is probably impossible to quantify and may have limited value, but is something I find intriguing anyway if it were to exist.

“What could go wrong” considered harmful

The retort “What could go wrong” is one of my big pet peeves.

It’s often used in response to a failure of a complex system or operation. Sometimes the system had clearly poor design, making it warranted. But more often these comments reek of hindsight bias and carry an arrogance โ€” as if the speaker could have easily avoided the failure if they were the one in charge.

It’s possible to construct that kind of retort for almost anything if you try hard enough:

  • “Flying massive metal tubes around in the sky filled with hundreds of people, what could go wrong?”
  • “Cementing metal wires into the mouths of children, what could go wrong?”
  • “Shooting lasers into peoples’ eyes, what would go wrong?”

But if you did so, you’d actually be wrong a lot โ€” because there are many complex systems that function correctly for most users, most of the time. They function because many people have poured blood, sweat, and human ingenuity into them to make them reliable. And it’s often not intuitive that they can work.

Even if sometimes people are truly negligent and deserve it, I don’t find the phrase of net benefit to the culture. I consider it harmful because it ups the consequences of failure โ€” a necessity for innovation โ€” in exchange for cheap virtue signaling from bystanders who often have no experience in the domain.

So rather than assuming incompetence, let’s all be a bit more charitable. The world is complex and less intuitive than it looks.

WIP: Reflections on audience building

Here are a few reflections after building two separate online audiences with 1000+ followers (comfort and offlinemark).

Audiences require active maintenance .

  • If you don’t actively maintain the audience by regularly posting content, the actual effective audience size declines over time (despite the concrete number staying the same) as audience members become inactive on the platform.

They grow in fits in bursts.

  • In my experience, the audience growth was not linear, but occurred in fits and bursts of about a hundred followers for major events or releases. Sometimes things just pop off. For offlinemark there were a few major events that got me several hundreds of followers each time. Plus, these tweets sometimes get retweeted and have second lives on the internet, getting me a bunch of new followers for free.
    • Demand paging blog post
    • /proc/self/mem blog post
    • Git tweet about referencing commits by commit message
    • Thread about forking being unsafe in real-time contexts due to page faults
    • A few other tweets.

Audiences grow within some specific context where you’ve established reputation, and do not engage with content that’s outside that context.

  • offlinemark is within the technical context and other kinds of content like about my music or other thinking is not engaged with nearly as much.

Releasing content to a large audience can be very distracting.

  • It’s extremely difficult to have content being going viral and not be glued to your notifications.
  • What if you’re wrong in a major way? What if you’re getting cancelled somehow for something you said?
  • At the very least, it’s an incredible amount of dopamine and affirmation that takes immense self control to not bask in.

Goal: Become a pro systems programmer

That’s a personal goal of mine. I’m not sure why, but I think it comes from spending a long time in computer security and feeling unsatisfied with just breaking “low level” software โ€” I want to be able to build it too.

But what does “pro” mean? What does “systems programmer” even mean?

Here’s what comes to mind:

Little skillSome skillPractical experience with
Fluent in a systems programming language. Able to write idiomatic code.x
Understanding of modern systems programming concepts โ€” e.g. smart pointers.x
Understanding of operating system and hardware/software interfacex
Competent with C/C++ build concepts โ€” e.g. headers, source, compilation, linkingx
Able to engage professionally in open sourcex
Competent with git โ€” e.g. can rebase, rewrite history and prepare perfect patch series (no stray newlines, commits build on each other, etc)x
Understanding of multithreaded programming and concurrency. Able to write idiomatic multithreaded code.x
Skilled with development tools โ€” e.g. debuggerx
Competent with performance profilingx
Understanding of how to model data with a static type system โ€” e.g. static vs dynamic dispatch, polymorphism, OOP concepts, reference vs value semantics.x
Understanding of I/O programming, esp. async I/O.x
Understanding of different OS platforms โ€” e.g Linux, Windows, macOSx
Experience with a variety of architecturesx


  • Become highly skilled in C++ template meta-programming


  • 2014 โ€” First professional Linux kernel experience (internship)
  • 2016 โ€” Landed a job working on symbolic execution engine (Trail of Bits)
  • 2019 โ€” First professional C++ work (Trail of Bits / osquery)
  • 2019 โ€” Landed commit in lldb
  • 2020 โ€” Landed commit in Linux kernel
  • 2021 โ€” Landed a full time C++ job (Ableton)
  • 2021 โ€” Built significant git competence (Ableton)
  • 2023 โ€” Built significant Linux kernel & hardware / software interface knowledge at work (Ableton)
  • 2023 โ€” Built knowledge of data modeling with static type system (Ableton)

Smartphone anxiety

Why do I have such anxiety when my phone isn’t on me, which prompts me to periodically tap my pocket to check on it?

A few key properties of phones:

  • Will cause significant pain and expense, in both time and money if lost
  • Small
  • Carried around everywhere

Beyond keys and wallets, there are not many other objects that can inflict so much pain & expense on one’s life if lost, while simultaneously being small and carried everywhere, which increases the chance of losing it. Thus producing a natural reaction to check if it’s there, and anxiety if not found. And furthermore, unlike keys and wallets, phones actively provide dopamine.

AI Predictions

  • In the future, we will see an industry of AI coaches. Some of these will compete and take business away from existing human coaches (e.g. a writing coach) but much of it will fill gaps that are simply unfilled right now. Think coaching for areas that could be helpful for people, but are too niche to go out and find a coach for. Human coaches will not totally go away because the flood of AI into society reinforce in people the desire to speak to “real humans”. We see this today with customer support and how people simple just want to get on a phone with a “real person” to can help them.
  • Just like how smartphones eventually became ubiquitous, personal AI assistants living on your phone or $BIG_TECH account will become the norm. Signing up for a Google account will initialize an AI assistant that will get to know you as you start to use GMail, GCal, etc. When you buy an Android phone, it will be there as soon as you log in.
  • Apps will come with AI assistants built into them similar to how we have chatbots in the lower right hand corner of websites.
  • Things will really start to get interesting once AIs can spend money for you. Think a monthly budget you give to your AI for buying groceries, household supplies, and more. Maybe it asks you before it triggers a buy, maybe it doesn’t.

The nice part about working for big companies

The nice part about working for big companies is that you can be a part of massive product launches that makes real waves and get massive press coverage… and you didn’t even have to be there for the decades of work that led to it. You can join at the end for the “fun parts”.

This week we launched Push 3 at Ableton. I was only barely involved, but I was still able to participate in the excitement of releasing our new product to an audience that has been hungrily waiting for it for years.

This is not something you get when working for yourself, or for most startups. Or at least not without 100x the effort.

It’s also not a guarantee at large companies, but if you choose your company and team right, it’s a significant positive that counterbalances many of the negatives of a large company.

Experiment: Categories for my posts

I’m trying something new. I added WordPress tags for higher level categories of content that cut across the typical tags:

  • Deep Dive: Longer, more detailed posts that require significant research. Very expensive to produce.
  • Tech: Normal technical blog post. More polished than Lab Notes, less researched than Deep Dive.
  • Lab Notes: Rough notes, typically technical, usually bullet points about some topic.
  • Essay: Nonfiction writing, usually nontechnical.
  • Micropost: Tiny, short thought.

I hope that by categorizing things this way and acknowledging that this blog is a collection of different art forms (that appear similar because they’re all writing), I’ll be more comfortable publishing publicly. For a while I was scared to publish because I don’t have as much time for deep dives as before, which is what people seemed to really like, but acknowledging these different categories and specifically calling out a shorter, rougher, less polished piece as such takes the pressure off of publishing it.

3 years of Timestamps

It’s been three years since I launched, and a little less than three years since I stopped working on it.

Since March 25th, 2020, here are the stats:

  • 4465 uploads
  • $437 revenue earned

This works out to about 4 uploads per day, which for me, is a great success.

Rough recap:

  • Feb 2020: I was taking my gap year and wanted to code again. I had the idea to work on a little tool for exporting locators from Ableton Live sets. I thought it would be fun to just quickly make it into a web app, and ship it. I ended up hyperfocusing on the problem space and making it super high accuracy (handling tempo automation). I also made it work for FL Studio which was difficult but a fun challenge.
  • March: I launch the web app ( at the time) and start trying to get users. I was extremely difficult. I posted on subreddits for DJing, Ableton, FL Studio, and Rekordbox.

Learnings and mistakes:

  • I wasted a ton of time porting to Google Cloud in an attempt to make the site run for free. It was an utter failure and I ended up porting back to Heroku.
  • I spent a ton of time DM’ing music producers that were performing at “e-fests” which were popular at the time (due to Covid-19, which was in full swing at the time). This was doomed to failure โ€” none of them would find value in this niche product.
  • Ironically, the customer and user that got the most use out of it reached out to me, not the other way around. The CEO of a company that makes a high volume of DJ mixes for hotels and restaurants DM’d me on LinkedIn asking to set up a call. He found me via SEO/Google search and was able to find me on LinkedIn because I had been bold enough to put myself as “CEO,” on my LinkedIn profile. Lesson: Be bold!
  • If I really wanted to do this in a time and capital efficient way, I should have put in way more customer research before building this whole product (including super advanced features like hyper accurate tempo automation support). I didn’t care about this though because I was on my gap year, and was first and foremost doing it because it was a fun programming challenge.
  • I wasted a ton of time hand coding HTML and modifying a free HTML theme I found online. I eventually rewrote the whole site in Bootstrap which took a bunch of time. The breaking point was when I was trying to make a pricing page with different subscription options. It was going terribly with my hand-hacking of the HTML page, and Bootstrap included great looking UI components for this already. Learning Bootstrap was probably a good investment.
  • If I were to do it again: I would use no-code WAY more. I would try to avoid hand-coding any HTML if at all possible, and just do the minimal amount of code to have an API server running for doing the actual processing.
  • I put up a donation button. In 3 years, I’ve had 3 donors, for a total of $25 in donations.
  • I eventually learned that the majority of DJs don’t care about time accurate records for their DJ mixes. A small subset of them do โ€” those that operate in the radio DJ world where they have licensing or reporting requirements. One DJ said they were required to submit timestamps so a radio show could show the track title on their web ui or something like that. But I was later surprised to see the site continuing to get traffic. Clearly there are some people out there that care. I haven’t bothered to figure out who they are or why. The site continues to be free, with no accounts necessary.

Smart things that I did right:

  • I had a lot of requests to support of DJ software like Traktor. I ignored them which was a great move โ€” it would have taken a lot more time and wouldn’t have moved the needle on the proejct.
  • I negotiated a good rate initially for the commercial customer’s subscription โ€” $40 a month! I then did a questionable move and lowered it significantly to $15 or a so per month when I made it free. The deal was that I would make the site free, but the customer would pay to help me break even on it. I later lowered it even more for them when I switched to ($~20) which is a much cheaper domain then ($80). It was a good move to move domains โ€” that domain was a risky liability โ€” if the customer ever left, I would have been stuck with an expensive, vanity domain for no real reason. I wasn’t going to become the next “” anytime soon.
  • SEO is the main driver, and continues to be until this day. I dominate the results for “ableton timestamps” etc. Posting on reddit and the Ableton forum were good calls.
  • I experimented with different monetization strategies. Pay per use was an interesting experiment and I made a small amount of money.

If I were to actually try to start a business again, I would do a lot of things different:

  • Be much more deliberate about picking the market and kind of customer to server
  • If you want to make money, make something that helps people that already make (and spend) money make even more money (the fact that they already make and spend it powerful and important)
  • Pick a product idea that isn’t totally novel so that it’s not so hard to sell it or introduce. It’s great to be able to say “I’m like X, but different because of A and B and specifically designed for C”

WIP: “Interesting” is in the eye of the beholder

I posit that in many software projects there is a small core of the “most interesting” work, surrounded by a larger core of “support engineering”. The “support engineering” is in service of the “most interesting” core in order to make it usable and a good product.

For example:

  • Compilers: Core optimizations vs cli arg parsing
  • Kernels: Core context switching vs some module that prints out the config the kernel was built with
  • Audio software: Core engine, data model, or file format work vs UI work on the settings menu
  • ChatGPT: Core machine learning vs front end web dev to implement the chat web UI

But the funny thing is that “interesting” is in the eye of the beholder. For every person that thinks X is the “most interesting”, perhaps most technical part of the project, there will be a different person that is totally uninterested in X and is delighted to let someone else handle this for them. This very well may be because X is too technical, too in the weeds.

The generalizes to work and society as a whole โ€” people gravitate towards work that suits their interests. The areas they don’t find interesting are hopefully filled by others who are naturally wired differently. This does happen in real life but of course plays out less cleanly.