Jordan McQueen

Jordan McQueen

Search for truth

Everything is a trade-off

To not bury the lede: Everything is a trade-off, so making a decision is about understanding which parameters you want to optimize, and their relative weights. This decision process can be easy, but sometimes it is exceptionally hard. Sometimes, a disagreement on the correct solution is actually a subtle disagreement on the relative weights allocated to each parameter. Framing these decisions as optimization problems can be a useful method for driving alignment or achieving consensus. At the very least, it can drive a mutual understanding of why the parties disagree.

For fun, let's model making a decision as some psuedo-code:

/// An outcome is something you decide to do, and it has Consequences.
struct Outcome {
    name: String,
    consequences: Vec<Consequence>

/// For our simple model, a Consequence can only be one of three things.
enum Consequence {
    /// How long until we get the outcome -- i.e. Wall clock time.
    TimeToComplete(magnitude: int64),

    /// How much "effort" will it be, in engineer-hours (or person-hours)?
    Effort(magnitude: int64),

    /// An Outcome will have certain Effects, for example if you decide to mow
    /// your lawn, an Effect might be Effect("House looks better", 30). For
    /// simplicity, we're doing this in a loosey-goosey Stringly-typed way, but
    /// it gets the idea across. The int64 is the magnitude of the Effect. Each
    /// Effect should abide by a contract about how to interpret its magnitude.
    Effect(name: String, magnitude: int64)

/// A function that decides between Outcomes, given some weights
fn decide(Vec<Outcome> outcomes, HashMap<Consequence, f64> weights) {
    // The decision's Outcome, and how well it scored. Higher is better.
    let mut decision: Option<(Outcome, f64)> = None;

    // Find the best outcome, by summing the magnitude of each outcome's
    // consequence's magnitude, weighted by the weights parameter.
    for outcome in outcomes {
        let score = outcome
            .map(|c| c.magnitude * weights[c])

        // If the outcome we're currently evaluating looks better than any of
        // the previous ones, then it becomes our defacto candidate decision.
        if decision.is_none() || decision.1 < score {
            decision = Some(outcome, score);

    return decision

Let me tell a story of an engineer's journey, with three chapters: Junior, Mid-level, and Senior.


A junior may have some preferences or ideas, but until you've seen how something fails, you don't have well-founded justified beliefs on how to best do things. Even more problematically, you might not be very good at enumerating the possible outcomes.

I want to be very clear: there is a difference between keeping a beginner's mind and being inexperienced. A beginner's mind can bring salient fresh perspectives on a problem. Inexperienced juniors may have a beginner's mind, but not expertise. If you couple expertise with a beginner's mind, that's where the real gains come into play.


A mid-level engineer has started to see how things can fail, and begins to develop strong opinions on how things ought to be. These engineers should be reasonably decent at enumerating the possible outcomes, but they may inevitably miss some important possibilities. A mid-level engineer develops heuristics like Gang of Four patterns are best practices, or everything should be immutable, or good code means no duplicated logic.

The thinking patterns often held by mid-level engineers work in 90+% of cases. They're good enough, for most things. But they break down. Best practice is an oxymoron. A practice is only the best if it's always the best, and nothing is best for every case. Absolutes like "everything should be X" are useful as an approximate default case, but they don't hold true in all cases. Nuance is everywhere, and second- or third-order consequences matter.

A good example of second- and third-order consequential thinking presents itself in the question of code deduplication. Many of us grew up learning how terrible duplicated code is. But did anyone ever teach us how bad deduplication can be? Deduplication is normally achieved by introducing abstraction. This is where the question of Consequence.magnitude comes into play. Ceteris paribus, that code duplication is to be avoided. But all things are not equal. The cost of a wrong abstraction is in fact orders of magnitude worse than duplicated code. Then, we can model this as follows: do we allow some duplication, or do we risk the wrong abstraction? Generally, you should allow duplication until that duplication becomes an actual problem. By that time, you should have sufficient experience in the problem space that the likelihood of choosing a bad abstraction is sufficiently low. Some present this idea as the rule of three. I propose to go even further, the rule of pain: duplicate until it hurts, then refactor. The reason is simple: duplication pain grows mostly linearly, but pain from the wrong abstraction is unbounded and grows in super-linear ways.


A senior understands that everything is a trade-off. Even things that seem obviously correct are in fact a trade-off — it's just that your weights are so skewed that it doesn't seem like a trade-off to you.

Things a senior might think:

  • "Code duplication isn't ideal, but avoiding it could be even worse."
  • "I may know a better solution, but the juice wouldn't be worth the squeeze."
  • "Many things can be modeled in terms of risk, and that viewpoint can be useful."
  • "Immutability is a good default, but mutability has a place when performance is important."
  • "Design patterns are mostly cargo-culting, and should be carefully evaluated."
  • "'Premature optimization is the root of all evil' is the root of all evil."
  • "Performance always matters, the only question is: To what magnitude?" (c.f. Would you browse Facebook if it took a year to load the homepage?)

Things a senior might think about:

  • Tying engineering back to the business need. e.g., "Our quality of engineering is of the utmost importance, our $50B business depends on our infrastructure platform running smoothly", vs. "We're a startup, we simply need to deliver results quickly, before running out of runway."
  • There are better options we could pursue, but the differences are too minute to be worth arguing.
  • How to communicate and drive a discussion from a trade-off perspective, and clearly enumerate the consequences of each outcome.