computer science



software engineering




coding style



distributed systems


system design











common misconceptions

performance engineering

project management

Travel deeply

It’s more than dozens of times I have heard or participated in a conversation where people would ask each other, “How many countries have you been to?” At some point it would sound like a competition. 20, 30, 40, “and this year I plan to do A and B and C”.

Yes, you have been to 30 countries in 5 years, but have you really “been” there? How many places do you really know and understand? How many of those amazing, life-changing moments do you actually retain, internalize and use to help yourself become a better human, a better citizen of this world?

Travel should be challenging. It should change the way you think and feel. It isn’t about checking the boxes or seeing the sights. It disappoints me to have to say: It’s also not about being seen at those sights. The obtuse misappropriation of the art of photography, to travel somewhere — with its own culture, nature, and context — and make yourself the primary object of your photos: Fremdscham is the only word I can muster.

Travel slowly, explore deeply

Go somewhere you don’t understand. Take the time, absorb what it offers. Learn something about the place. Learn something about yourself.

(Inspiration and quotes.)

Don't let perfect be the enemy of good

Perfect is the enemy of good. Shipping something something imperfect is usually better than shipping nothing at all. (There are exceptions, but they aren’t common.)

Most sufficiently advanced systems have to evolve to become good. Evolution requires exposure and experience in the real world, battle-tested behavior, and importantly, failures. The only path to this kind of evolution is to actually put something out there, even if it isn’t perfect. Especially if it isn’t perfect.

The elbow in the curve of time spent improving design and analysis comes earlier than you think. You should be spending less time designing, and more time learning from your failures, missteps, and the complex realities of your system in the wild. Your designs are wrong anyway. Natural selection is going to be a far more efficient process for showing you why and how your design is wrong than anything else.

Of note, an old essay by Richard P. Gabriel.

You must try, and then you must ask

When you become stuck on a problem, you must try for another ~15 minutes, and then you must ask. Document what you try. It becomes a guide that may lead you to the answer, and if not, it will certainly lead to a better question.

The temptation to immediately ask an expert is tantalizing — but resist! If you first try, then ask, you gain things: Trust, Knowledge, and Skill.

Trust, because the experts see that you’ve tried, and you have documents showing what you’ve tried. You’ll also earn trust from questions unasked — others will discover what you’ve solved without help.

Knowledge, because some of the time in that ~15 minute buffer, you will find the answer yourself. Knowledge gained by trial can often be stronger than knowledge from tutelage. Sometimes, you will even learn something that no one else knows. This is one of the greatest feelings. And frequently incredibly fruitful.

Skill, because you will learn how to better learn. You will learn other things that you weren’t trying to. The 15 minute buffer might get smaller and smaller until it’s only a matter of a few minutes.

After all, an expert earns their place by trying a lot. Any sufficiently advanced form of expertise should look similar to trying a lot — and failing a lot. The best experts become intimate with this feeling. They may even revel in it. Accept the discomfort, learn to embrace it, and good things follow.

You must try, and then you must ask. (inspiration)

Read the code and all else will follow

Sometimes it can feel like reading the code should be the last resort. That feeling is wrong. It is a dangerous feeling, bred from discomfort.

Reading the code isn’t always comfortable. It can feel like an arduous chore, especially if it isn’t a core habit of yours.

The code is truth. The only complete truth. If physicists had all the source code for the universe, how many experiments do you think they would run? My guess is zero.

Read the code and all else will follow. Do you wonder how something works? Read the code. Are you stuck on understanding an internal service? Read their code. Are you debugging how a coworkers’ library works? Read the code.

Always read the code.

Flow playlist

I long searched for the perfect playlist to listen to as I worked. I never found it. So I tried to create it.

Flow is my playlist for concentration, coding, problem solving, etc. As of Mar 2019, it has over 57 hours of music.

Its aim is to optimize for the mental state of Flow. Using nearly exclusively non-vocal tracks, the genres are primarily spacemusic and ambient.

Thoughts should motivate action

Thought is useful when it motivates for action and a hindrance when it substitutes for action.

Bill Raeder

Judgment over technique

The great benefit of computer sequencers is that they remove the issue of skill, and replace it with the issue of judgement.

Brian Eno

Collapse the distance between imagination and implementation by building tools.

Gordon Brander

Less rote practice; more imaginative delivery.

Runbooks are an admission of guilt

I have never written a runbook. And I refuse to ever do so.

Writing a runbook is a deliberate declaration of failure. It is the explicit process that recites a refusal to correct an error. An error doesn’t become a mistake until you refuse to correct it.

If your organization has runbooks, consider them as backlog tasks: automation, redesign, and architecture improvements. Do not add to their numbers. Failure begets runbooks; runbooks beget runbooks; and runbooks beget failure.

The fallacies of distributed computing

A good, simple writeup on the fallacies of distributed computing.

PDF Essay: Fallacies of Distributed Computing

Consistency models

A good index resource on consistency models, their guarentees, proofs, origins, etc.

Consistency Models

How to build a company

An incredible read on how to build a company from the ground up.

Founder to CEO

Nobody listens

Everything has been said before, but since nobody listens we have to keep going back and beginning all over again.

André Gide

Think big picture and fine detail

“It is an attitide that can be encapsulated in a simple but demanding rule: always think big picture and fine detail.”

Will Gompertz, Think Like an Artist

Interdisciplinary learning

I’m convinced that the best kind of learning is interdisciplinary. Fields of study have much to learn from each other. The most interesting learnings are those that transcend fields of study. The rest is just details.

Everyone belongs to a tribe

Everyone belongs to a tribe. Everyone underestimates the influence those tribes have on their thinking.

Acknowledge your tribes. Try to separate your thinking from your identity.

Keep your identity small

Keep Your Identity Small (2009) is an essay by Paul Graham which describes something I’ve intuitively practiced since my early twenties. But I’d never formalized the thought.

My set of justified true beliefs come not as an expression or extension of my identity, but from reasoned logic combined with a set of morals, ideal outcomes, and other justified true beliefs. I’ve internalized the idea that I shouldn’t let these beliefs constitute my identity.

A related idea is that of “Strong Opinons, Weakly Held”, a framework for thinking espoused by Palo Alto’s Institute for the Future. The idea is that opinions should be “weakly held” — be unattached to the idea, so that you do not irrationaly reject its refutation. The other side of this coin is that you must not let this lack of attachment dampen your rigor, passion, or strength in forming, understanding, and justifying your beliefs.

Linux performance toolkit

This talk by Brendan Gregg is a fantastic introduction to the tools available in linux for performance instrumentation, monitoring, and debugging.

More to come on which of these tools I use and documenting how I like to use them.

The true burden of masters

We are what they grow beyond. That is the true burden of all masters.

Master Yoda

Create shared success

It is not enough to create your own success; you must create a shared success. A talented engineer will build a taller boat to see further along the horizon. A great engineer will create a rising tide that lifts all boats.

A shared success is not limited in scope to your team — it transcends teams. Find ways to drive shared successes across your org and company. Find the common good in a solution — the positive incentivization scheme that drives collaboration towards a shared goal. Express that common good persuasively and collaborate to achieve a shared success.

Create shared context

Shape the understanding and thinking of those around you to a shared context. Tailor the message to the audience. Engineers, managers, product managers, directors: To each of these people, the message must be presented in a different light. For some, only some of the message is relevant. For others, it is a matter of making the message comprehensible. Without a shared context, you will inspire very few — and even fewer will create a shared success with you.

Taking children seriously

This essay corroborates a lot of my own views about how I would choose to raise my children. Whenever interacting with children, I prefer to treat them exactly as I do adults, respecting their ability to reason, learn, and comprehend.

As a kid, I resented being treated like a child. I didn’t like it if an adult would dumb down a concept or hand wave something away because it was assumed I wouldn’t be able to understand. I think if we treated kids more like adults, the adults of tomorrow would be smarter and stronger.

Waiting for the check

What is a deadlock?

A deadlock is kind of like when you’re at a resturaunt waiting to get the check, and your waiter is wating for you to ask for it. And you’re both wondering why it is taking so long.

You’re both waiters now.

The power and cost of abstraction

First you learn the value of abstraction, then you learn the cost of abstraction, then you’re ready to engineer.

Kent Beck

Design software with migration in mind

Always design your programs as a member of a whole family of programs, including those that are likely to succeed it.

Edsger W. Dijkstra

CS is not about computers

Computer science is no more about computers than astronomy is about telescopes.

Edsger Dijkstra

Functionality is an asset; code is a liability

Functionality is an asset; code is a liability.

Kirk Pepperdine, @kcpeppe


Perfecting oneself is as much unlearning as it is learning.

Edsger W. Dijkstra

The lurking suspicion of simplification

The lurking suspicion that something could be simplified is the world’s richest source of rewarding challenges.

Edsger W. Dijkstra


Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

See also: Refactoring: Improving the Design of Existing Code

Comments: a delicate matter

A delicate matter, requiring taste and judgement. I tend to err on the side of eliminating comments, for several reasons. First, if the code is clear, and uses good type names and variable names, it should explain itself. Second, comments aren’t checked by the compiler, so there is no guarantee they’re right, especially after the code is modified. A misleading comment can be very confusing. Third, the issue of typography: comments clutter code.

Rob Pike, Notes on Programming in C

Cargo cult programming

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose.


Phenomenal pas de deux

Tiling window managers

The i3 window manager is the best thing to happen to my desktop in a long time. Much like modal editing, it is a paradigm shift in how to interface with your computer. No floating windows. Everything is snapped. If you’re a vim/emacs user, you’ll like i3.

Documentation should be high-level

A few days ago, our team launched a new component. A week after launch, while dealing with some ops tickets, we discovered that the detailed, extensive wiki document for that component was already out-of-date.

This is a familiar story to any dev. Documentation is hard to keep accurate. The knee-jerk reaction is to assess that the miss here was that we allowed the documentation to become inaccurate. The knee-jerk reaction is wrong. It is not feasible to maintain documentation if that documentation is too specific.

The solution is to change the philosophical approach to documentation. For software systems of any reasonable complexity, the code is the only source of truth for its behavior and its descriptive reality. Documentation ought to answer the following questions, in basic non-technical english prose:

  1. Why did we create this component? (prescriptive statement)
  2. At a high-level, how does it solve its problem? (This answer should absolutely not map anywhere near 1:1 to its implementation. It should be at an extremely high-level.)
  3. Going no deeper than a file/class level view, describe in a paragraph the function of the most critical classes/files/modules in the code. This is as specific as it should get, and this serves as a guide for an engineer to dive into the code.

Again, documentation should never map 1:1 to anything more specific than a class. Anything more specific than that, and it effectively has to change whenever the code changes. If you’re changing the function of tons of classes and files, it is reasonable to expect that the documentation would necessarily have to change in kind.

Writing documentation at a high-level helps to minimize the potential that your documentation will become out-of-date and inaccurate. It is easier to understand, too. Which is kind of the point. If someone wants to know the objective truth exactly as it exists, the documentation is absolutely the wrong place for that. That’s what the code is for.

My dream house

A home is something personal, a space that can shape your habits, emotions, and thoughts. I do not see it as overly materialistic to dream of an ideal place to call home.

My wishlist

  • Eastern light (I wake best by natural light)
  • Western light (sunsets are romantic)
  • In Seattle, preferably Capitol Hill, Queen Anne, Montlake
  • Ceiling-to-floor windows, and plenty of them
  • Grand views of mountains and water
  • High ceilings
  • Open floor plan, without needless walls or partitioning elements
  • A modest and easily maintainable yard
  • A spacious, open kitchen that allows for entertaining while cooking
  • Relatively medium-to-small house — 3br, less than 2500ft²
  • Stone exterior
  • Sitting high above the road
  • Nearby or adjacent to green space
  • Minimalism over complicated or noisy designs
  • Some styles I like: Tudor, Mid-Century Modern, Gothic, Craftsman, Pacfic Lodge
  • Understated or modest from the exterior — I don’t want it to be showy

Examples of homes I like

Leadership: big L, little L

I recently attended an Ada Talk at work. (Here at AWS, Ada is a group whose motivation is to create a community to empower, grow, and develop our women engineers.) One of the panelists, Clare Liguori, spoke about Big L, Little l leadership.

Big L Leadership is official. It’s the managers, directors and executives of the world. Little l leadership is leading by example. It’s camaraderie, teamwork, and excellence of character. Engineers have a lot of opportunity for little l leadership. Take advantage of that. Be a little leader.

Worry about scaling later

While I worked at an early stage startup, I fought tooth and nail in design meetings to apply solid engineering principles to everything we did: scalability, extensibility, modularity, generalization, etc.

I was wrong.

I was attacking the problem from a different perspective, a perspective that would fare well in a large company with massive distributed systems — a company inherently optimizing for the long run. Startups, however, are not optimizing for the long run. They can afford to worry about that later. They need to solve for tomorrow.

This doesn’t mean you should throw your engineering principles away. They’re not inherently wrong; they are simply the wrong tool for the job, if you’re at a startup. You must realize that everything is a matter of compromise, and at a startup, you will be compromising more often than not.

Murali Krishnan, my manager at the time, got this right. I was often on the other side of the table, arguing for engineering excellence. I wasn’t yet wise enough to understand his side of the story. It was only later that I understood that startups are optimizing for a different variable.

As a budding engineer that wants to hone these areas of excellence, it can be a very hard pill to swallow, to intentionally set aside engineering best practices. Do your best to understand that you’re not optimizing for the long run. Not yet.

Don’t just take my word for it, though. An essay of Paul Graham’s inspired this post. An entirely worthwhile read.

Context switching an engineer

Every time you ask an engineer to postpone what he/she was working on and immediately work on some new task, you’ve done the equivalent of grabbing at least $500 from your company’s piggy bank and flushing it down the toilet. You’d better make sure that new task is worth it.

Any progress the engineer has made on the previous task, you can now kiss goodbye. You should consider that previous task as completely unbegun.

Context switching is incredibly expensive for engineers. It can take upwards of an hour for an engineer to build state on a problem. Building this state is a fixed cost of entry for the engineer to enter a state of flow that enables productivity. Breaking that flow and wasting all that state is expensive.

Conservative Googler manifesto

Yonatan’s response to the recently leaked conservative manifesto that was circulated in Google much mirrors my own thoughts on the matter. Google ought to come down hard on this guy.

Tolerance is not a moral precept. There comes a point where tolerance turns from convenience to complicity. Do the right thing.

A computer scientists view of life, the universe, and everything

This paper by Jurgen Schmidhuber is incredible. I’ll take some notes on it here in the future.

The FiveThirtyEight Riddler

If you like imaginative/challenging math/logic/CS problems, take a gander at FiveThirtyEight’s The Riddler.

FiveThirtyEight is Nate Silver’s website that does precise, academic, and statistical commentary on a variety of issues. Their The Riddler column features hard and interesting problems on a weekly cadence.

In the past, I have solved several, with at least one of my solutions being featured with a shout-out. My solution with code is on GitHub. This particular problem was a fun little geometry problem which I opted to solve via simulation and numerical geometry, though others found an elegant analytical solution.

Dancing the quicksort

This is pretty sweet. If you can geek out about this kind of stuff, ping me. We’d get along just fine.

Comments are a code smell

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.

Steve McConnell

Good architecture

If you think good architecture is expensive, try bad architecture.

Brian Foote & Joseph Yoder

The sound of sorting

This video is pretty cool. It gives a visual and auditory insight into sorting algorithms. I believe this offers a unique angle that bolsters our intuitive understanding of how different methods of sorting work.

I strongly prefer and seek out deeper, more intuitive understandings as opposed to shallow, rote ones. Take a look.

Avoid hard problems

A clever person solves a problem.
A wise person avoids it.

Albert Einstein

The rule of three

omne trium perfectum

— Latin for “everything that comes in threes is perfect.”

Kudos to a previous manager of mine, Murali Krishnan, whom I met while working at Transform for demonstrating true mastery over the rule of three and opening my eyes to its power.

The rule of three (of which there is so much written that it needs a disambiguation page) is an incredibly potent tool to communicate ideas, persuade others, and to tell stories.

  1. A threefold model lends explanatory power to difficult-to-explain topics, simplifying the conceptual model and providing and elegant framework to teach.
  2. Problems often cleanly subdivide into three sub-problems.
  3. The cadence and presentation of threes tend to be inherently agreeable to humans, augmenting credibility and persuasiveness.

See also: The Rule of Three, by Kevlin Henney

An error is not a mistake

“An error doesn’t become a mistake until you refuse to correct it.”

Orlando Aloysius Battista

Less is more

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

Antoine de Saint-Exupery

Almost is a word that means not

You will often hear someone say, X is almost Y. Almost in this context should be read as not. Almost is a graceful way to say that something desirable is not yet true.

It's worth building a tool for

If something is worth doing once, it’s worth building a tool to do it.

Abraham Lincoln