Category Archives: Career

Do you need to learn how to implement a red-black tree?

How to not feel dumb around “smart” programmers

When going to programming meetups, conferences, or starting a new job, it can be extremely easy to feel dumb around other engineers there. Sometimes these engineers truly are geniuses, but many times they’re not as “smart” as your immediate imposter syndrome is leading you to believe.

My advice, especially for beginners, is to remember that these people are probably talking about a domain they are extremely familiar with, and have spent probably 1000x the time with than you. You probably have stumbled upon to a topic that they are specifically knowledgeable about, which gives the impression that they’re ultra smart (and you’re ultra dumb, for not knowing anything about it).

The key is to remember that this impressive depth of knowledge is likely limited in breadth. If you were talking about your domain, you’d might know a lot more than them.

It’s also easy to feel dumb when watching a conference talk. My trick here is to remember that the reason this person can speak so confidently about such a technical topic is because, again, they’ve spent 1000x more time on it than you have. They’re had their face pressed directly against this problem for a long time, which is why they know all this and can talk about it.

This comes from my experience:

  • Entering the programming world (feeling dumb at hacker club in college)
  • Enter the infosec world (feeling dumb at infosec conferences)
  • Going to conferences not directly in my expertise (i.e. the LLVM Dev Mtg)
  • Entering the audio programming world (feeling dumb at audio conferences)
  • Feeling dumb in many, many conference talks

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)

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.

Remote onboarding

The biggest challenge when onboarding remotely was getting a feel for the culture. Without this, you have to play it safe and act conservatively (i.e. maximally professionally), however it can be draining to always be so buttoned-up.

The two things that helped me feel more comfortable were:

1. Seeing “micro unprofessionalisms” during zoom calls.

One colleague had a large drawing of “No Face” from Spirited Away on his wall.

Another’s cat jumped onto the desk, and then a baby ran into the room.

Another just had a mess in the background.

All of these show humanity and personality. They let the new team member know that the tone is relaxed and that there’s no need to stress over behaving perfectly “professionally”.

2. Getting hints from coworkers about work norms.

I have a coworker that’s brutally productive. But one day he said, “I’m going to be out for a few hours this afternoon to get my trombone fixed.”

It’s easy to overlook such a remark if you’re been on the team a while. But for a new joiner, even small comments like this provide valuable insight into what is and isn’t acceptable on their new team.

To make your new team member’s remote onboarding experience more comfortable, be intentional about showing humanity — visibly display things that are unique to you (and un-blur your background). Also, remember that your team’s culture exists, must be learned, and can be proactively communicated.

My audio development journey

Wrote a thread about it: