Category Archives: Career

How to be a more effective professional engineer

These are tips I’ve been applying in my professional life as an individual contributor on a software development team.

Better awareness of time

This is a foundational practice which concretely helps me with better standup reports, team retros, and stress management (see below).

I have two time tracking systems, coarse and granular.

The coarse system is designed to help me see at a high level what I’ve been up to over the last days/week/months.

The granular system is designed to provide insights about how much time I’m spending on specific types of work. It also gives me more mindfulness about how much time I actually have to do work.

Concretely, the coarse system is a spreadsheet. Every row is a week. Every workday gets three columns: Morning, Early Afternoon, Later Afternoon. These correspond to natural chunks of time for me, and may differ for you. I fill in roughly what I did during each of these 2-3 hour buckets. The massive benefit of a spreadsheet is how information-dense it is — you can easily view months at a time like this.

Concretely, the granular system is Toggl Track. I don’t use the automatic app-based tracking, and manually track the time. Although this is the “granular” system, it’s still somewhat coarse grained to make the tracking overhead manageable. For me, the main categories are:

  • Main Dev Work (i.e. The primary work I do as part of my dev team)
  • Pair Programming
  • Code Review
  • Meetings
  • Personal Dev Maintenance (i.e. Maintenance of my dev environment)
  • Meta/Reflection (i.e. Time for weekly reviews, GTD, etc)
  • Admin
  • Misc

Better standup reports

I used to give unfocused and rambly stand-up reports. To improve this, I started taking 1-2 minutes before standup to prepare my report.

I use a standard framework for structuring my report.

  • Did: What I did since yesterday’s report
  • Doing: What I’m doing today
  • Blocked: What I’m blocked on, waiting for, or struggling with (that I could use help from colleagues with)

To help remember what I did (even if it was just yesterday), I rely on my coarse time tracking.

Better team retros

To remember what happend in the last sprint (two weeks), I use my coarse time tracking system. I also keep a virtual notebook with retro thoughts as they come up throughout the sprint.

Better capacity planning

I fill in vacation, holidays, conferences, and other absences in my coarse time tracking system. Since the coarse system is so zoomed-out, it’s very easy to anticipate absences coming up and give my team warning about them. This is especially helpful when the team is doing planning work, so we can adjust work expectations based on capacity.

Better use of small blocks of time

Sometimes I finish a major effort, and have only 20 minutes either before a meeting, lunch, or the end of the day. I used to just start on whatever was top of mind for me, which is often large Main Dev Work — features, stories, or bugs that require longer periods of focus time.

Choosing this type of work for a short time block isn’t always a good choice, since there’s not enough time to properly get into the topic.

To help this, I

  1. Stay grounded in my calendar through the day, and keep an awareness of upcoming meetings, end of the day, etc
  2. Maintain lists of things I could do, so I have awareness beyond what happens to be most top of mind

There are certainly smaller tasks of various types that I could do in 20 minutes (admin, dev env maintenance). Much of better time management is choosing tasks that are appropriate for the given time available.

Better focused work

Again, this is time related. I noticed that if I didn’t get a solid focus session in the morning, the next earliest time to start one might be as late as 4/4:30p due to meetings. But by that point, I’m kind of tired and have less time to ask for help or pair if necessary since colleagues start to sign off.

I started really prioritizing my morning flow, and trying as hard as possible to ensure that I can have at least 2.5-3 hours of solid work time in the morning when I’m more fresh.

Better resuming of work

I used to leave my digital workspace a mess when I signed off, with browser tabs, terminal tabs, and IDE windows everywhere. This could help preserve some context, but often just created a mess to start my day. I started doing a daily sign off ritual where I clean up all these tabs, and create a clean workspace for the next day, ideally even with the right tabs and IDE windows open for my next morning flow.

Better ending of work

I used to often overwork, especially when working from home. Now, I explicitly plant an event in my calendar for the last 15 minutes of the work day to wrap up and do my sign off rituals. I also adopted a mindset of being extra aware of time passing throughout the day, and having my calendar simply open on a side monitor.

This mindfulness helps me anticipate the fast-approaching end of the day and helps me not blow past it and overwork.

Better expectations around work

After I finished one task, I used to simply start on whatever was next, regardless of how much time I had left in a day, or how large the task was. (I already mentioned this above). The implicit work model is that as long as I’m at work, I simply grind through the work. This isn’t necessarily the healthiest mindset because you’re never really “done”. The day simply ends, often in the middle of a task.

I adjusted my expectations to be more realistic about energy management. I now focus on making one impactful piece of progress per day, ideally during my morning flow session, ideally on a high impact/importance/leverage task. If I’ve done that by the end of the day, I can take pride in a solid day’s work and sign off guilt-free.

How to level up your life

Every time I’ve leveled up my life, it’s been because of the people I surrounded myself with, who helped pull me in the direction I wanted to go.

I’ve done this four times in the worlds of:

  • Heavy metal music
  • Electronic music
  • Cybersecurity
  • Audio software

And I’m currently doing it to learn operating systems development.

By the time I was 16, I had released two heavy metal albums on the internet. A large reason why this happened was because I surrounded myself online with a community of people who really cared about this.

In these communities, it was completely normal to be recording your own instrumental heavy metal music, and releasing it every 6-12 months.

Imagine a real-life party for this kind of person. You walk in the room, and if you’re not personally making and releasing your own instrumental heavy metal music online, you’re going to be a bit of the odd one out.

You’re doing to do one of two things. Either, you’ll leave the room, because it’s not the room for you… Or, if you choose to keep hanging out with these people, you’ll probably start making some music.

Working at Ableton has probably been the best example of this in my life. It was one of the hardest rooms to get into, but the learning on the other side has been incredible.

I’ve been able to work with masters of the craft, who have been doing this for 20+ years. And because I’m on the same team as them, they’re incentivized to pull me up to the level I need to be at to work alongside them.

The point is: You need to find alignment between:

  • the things you care about, your passions, what you want
  • the spaces, rooms, and people you’re surrounding yourself with
  • and the natural direction those rooms are going to pull you in.

Tips for networking

I’m not a pro, but here’s what I’ve learned along the way:


Randomly add value to peoples’ lives that you want to keep in touch with.

This looks like:

  • Meet interesting people
  • Learn what they care about
  • What out for related things you see
  • Send them their way

These “things” can be serious, like useful tools, apps, or news — or can be silly, like memes.


Simply check in once in a while.


  • People want to help you, but you need to put in the work too
  • Craft good, compelling, detailed requests for help. As opposed to lazy asks.
  • If someone does something nice for you — like making an intro — always follow up with them and let them know how things went.

What I learned in my 20s

I had the privilege of speaking to my friend Andre’s high school class this week about my career and path to it. I didn’t have time for all the advice I’d give, so I’m putting it here:


It’s ok to not be able to answer “So where do you see yourself in 5 years?”.

That’s a hard question, and it’s ok to not immediately know the answers to hard questions.

In my experience, most of my life was in a state of not really knowing this, with one major exception: When I realized in 2017-2018 that I really wanted to work for Ableton in Germany. Then it became startingly clear where I wanted to be, and approximately what I needed to do.

My advice would be to simply start taking actions while being observant of yourself, and your strengths, interests, and natural inclinations. At what things do you naturally work harder than other people? What things seem like play to you, but work to others? Those are hints at areas you can excel and become world class.

Eventually after enough action (and reflection), you might have an insight about something you deeply want to make happen. And then suddenly it becomes clear.

“As you start to walk on the way, the way appears.” – Rumi


It might seem like life is a race, from start to finish, where checkpoints are things like: university, job, marriage, children. When you “graduate high school” (i.e. become an adult), the gun goes off. Everyone starts running and the first one to make it through, wins.

In my experience, the “race” is actually a custom trail for every single person. When you “graduate high school” (i.e. become an adult), the gun goes off and everyone starts running in different directions. Another person’s progress towards their endpoint has little to no relevance on your progress towards yours.

The only competition is to know yourself as fully as possible, and act with maximum authenticity towards that truth.


A simple strategy towards achieving success and fulfillment is looking for:

  1. A “vertical”: An industry which you have particular interest (e.g. music, fashion, film, journalism, activism, sports, …)
  2. A “horizontal”: A skill which you have interest in and aptitude for (e.g. technology, writing, art, photography, communication, …)

And then work at the intersection of the two. Basically every vertical needs every horizontal. Every industry needs programmers, communicators, creatives, etc.

This strategy is not foolproof, but can be a good approximate path for those without one. And it worked well for me!


Seek like-minded peers. The first time this happened to me blew my mind — I went to the National Guitar Workshop in 2010 and met a bunch of other teenagers that were interested in writing original metal compositions and recording them on computers. This was a life-changing experience and gave me friendship, motivation, and a sense of community.

Then in college, I went to NU Hacks and the same thing happened. I found a great network of aspiring hackers, and we became great friends and learned together.

In both cases, all these people are now doing amazing things in the world in their field. And these relationships have turned into the kind of life-long friendships that are one of the best things in life.


Greatness is built iteratively, over a long period of time.


Don’t be afraid to exploit your unfair advantages.

What is mastery?

To use an analogy from cooking:

Mastery is when the chef not only knows how to make oatmeal the “right” way, but is able to answer if you ask “What happens if we use half the water? Twice as much butter? No butter at all? 4x the milk?”. Because they’ve tried all these things before.

A master understands where the canonical solution fits in the greater design space of all solutions, and the tradeoffs involved. They can explain, in depth, what happens if you “do it wrong”, and can provide examples of instances where you might want to.

A master understands when the laws of gravity actually break. 1

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.

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.

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.

Learning on your own pales compared to spending time with experts

This has become crystal clear to me at my current job. As much as I’ve had success teaching myself things about computers, nothing, nothing, beats spending time with experts and learning from them.

I had never truly experienced this before and was shocked at how much I was able to learn, in such little time — about C++, git, Linux, and more.

It can be a significant price to pay, but nothing beats literally becoming an employee at a company with experts in a field you care about and joining their team. This is ideal from a learning perspective because as a team member, the experts become invested in your growth and are incentivized to transfer knowledge to you. You just need to be ready to receive it.

Once you’ve tasted this, this truth is also bittersweet. You can only work at so many places. If you have many interests, you now have to live with the fact that for most areas, your learning will be stunted relative to what it could be.


My deep gratitude to the experts in my life: STK, DIR, CSK, MKL, RYB, MZA — thank you.

Why you feel stupider than ever, despite being smarter than ever

I’m 10 years into my tech career and yet I constantly feel so, so stupid.

It’s entirely self-originating; not because others are mean to me. (Ok maybe partly also because I’m lucky to be around smart people).

Why do I feel this way, despite mountains of evidence to the contrary — that I’m not stupid, and know a thing or two about what I’m talking about? Is my self esteem really that bad?

I think it’s also because I’ve been learning so much. The more I learn, I more I realize I don’t know. And I posit that the weight of a known unknown feels disproportionately bad to the relief of converting it to known known.

So, the equation looks like:

All Knowns = Known Knowns + Known Unknowns

Perception Of Intelligence = Known Knowns / All Knowns

(Smaller = Less Intelligence = More Stupid)

This makes sense to me. I think I accumulate known unknowns at 10x the rate of known knowns — it takes so much more energy to learn something, than to learn merely of the existence of something.