Speed Limits, Programming, and Finding Direction

Published: Feb 22 2022

One of the most common sentiments that I get from people who've worked closely with me, especially recently, is that I'm a quick programmer. While I generally disagree with this, I do think it's true in a very select few cases, and I think it's worth unpacking a little further in a blog post. By doing so, I think there emerges an opportunity to write about some of my overarching philosophies and practices, both for writing software, and maybe even for life in general.

To start, I want to clarify that I don't think I'm an above average programmer, nor do I think I'm incredibly speedy overall. However, I do understand why some people may think that I am either of those two things.

First off, the majority of my work (especially these days) is within codebases which I've designed from the ground up. If you ask, I could probably tell you in excruciating detail how every bit of that code is structured, works with each other, and overall, is implemented. This sort of recall is only possible in smaller programs (e.g., sub-10k lines of code), and has already started (and will continue) to degrade over time.

Secondly, for the majority of the time while I'm actively programming, I'm not really thinking, moreso reciting. Thinking through implementation details in advance (perhaps on a walk, in the shower, etc.) can seriously improve both the quality and speed of a programmers work. This reminds me about a fun anecdote from the algorithmic trading world, where firms constantly fire their hot path (cancelling events near-microseconds before completion) to keep their CPU caches hot. It's a lot easier to respond to a real-time market event when you've had thousands (if not millions) of fake trial runs just moments before.

Bringing this back to the main point, I think the reason why I'm able to (at least appear) as a relatively quick programmer is because, especially recently, an absolute ridiculous percentage of my brain cycles (even when I'm not working) are about work. While I can't say that I think this is an overall very healthy practice, what I can say is that I'm incredibly happy doing what I do. I'm basically living my high-school self's dream; I get paid to work full-time on the stuff I'd be doing on weekends and evenings anyway.

I've been relatively lucky as I've have had more chances than most to explore different directions, and to really narrow down what I care about and what I want to work towards. In my case, it's largely human-computer symbiosis and the idea of enabling humans and machines to work together in new ways. First, and to be clear, this is a very privileged statement; very few people have the sort of freedom or flexibility to make this choice, and I'm very grateful to be one of those lucky few. Secondly, I think it's important to escape any sort of elitism here (especially prevalent in tech), different philosophies, principles, and directions should be celebrated and learned from, not looked down upon. You don't have to start a business-facing software company to be successful.

I'm a big believer in this concept of "there is no speed limit", which I believe was first introduced and/or publicized by a music instructor named Kimo Williams (source). This mindset of creating opportunities, rather than waiting or abiding by (artificial) speed limits, in my opinion, is a huge advantage for an individual (especially a programmer or a founder) to have. While others are blocked on frankly, stupid bullshit, a "don't wait" type of programmer will either continue to make forward progress in another area, or perhaps even rethink the problem and question the block to figure out ways to get around it and keep moving forward. This type of attitude compounds, especially as momentum and inertia come into play (don't let anything get in the way of this).

Frankly, I'm not really sure how to end this. I wrote this blog post originally to clarify my thoughts on this whole idea of a "quick programmer", and specifically, how to respond when someone calls me one. My initial attitude towards it was negative, largely stemming from too many pairing sessions and hackathons where my team/partner likely felt uncomfortable and unable to keep up with the speeds at which I was churning out code. Throughout writing this post, I think my overall attitude changed, I started to warm up to the idea, seeing it more as an advantage rather than something I need to work on or be ashamed of. If anything, I probably need to go faster.