Home on BonnyCode

The best part of waking up

Tue, 03 Mar 2026 00:00:00 +0000

When I was young, old enough to drink coffee but not really an adult, I had a drip coffeemaker called Mr. Coffee. I scooped pre-ground coffee from a big red can while I’d sing “the best part of waking up… is Folgers in your cup”. I later graduated to a French press, then pourovers, and then a Nespresso – which honestly felt like a step backwards from the pourovers, but it was faster and I was busy.

Now my older, more sophisticated self uses a fancy-dancy espresso machine. I have a single-dose burr grinder and I buy my beans from a guy named Hunter who roasts them in his coffee shop down the street from me. I still hum “the best part of waking up…” every morning when I make my espresso because it makes me happy and my boutique beans tolerate it.

When I first got my machine I went on a mission to git gud at making espresso. When I visit a new city, I always look up whatever the top-rated third-wave coffee shops are and order an espresso with a small cup of sparkling water. I smell it, pretend the tasting notes mean something, and savor it; cultivating my palate I call it.

For over a year, I tried different settings to get the best flavors out of my espresso. My machine is completely programmable, so you can do things like bloom your espresso shot before you pull it, similar to what you do with pourovers. I bought a tiny tool with needles to rake the grounds like it was a zen garden. I have a little metal screen that I put on top of the grounds after tamping to prevent channeling.

I love making espresso because it is so fiddly. I’ve been a min-maxer my entire life, since I first played red box Dungeons & Dragons in the 80s. Maybe espresso, min-maxing, optimization, data science all spring from the same causal origin. A desire to create meaning where there is none – layering complexity until the nothingness is hidden from view.

Just getting the grind settings perfect took me months of trial and error; too fine and it tastes bitter, too coarse and it’s too sour. By the time I finished dialing in a bag to get something drinkable I was on to a new bag and the adventure restarted. I created a log of each shot I pulled; the beans I used; the grind setting; the pressure profile; the resulting outputs (primarily flow rate); and, finally, my tasting notes. My tasting notes could be biased, so I enlisted my children to conduct a proper experiment. I would pull multiple shots with different settings, have my kids label one A and another B, and then write my tasting notes without knowing which shot was which. I got pretty wired in my pursuit of statistical significance.

Espresso is serious business to get right. When I finally perfected my espresso I pulled a shot for a friend we’ll call Bill (his real name starts with a J; he knows who he is). Bill said “wow, this is a bit too sour for me. Do you mind making it into an Americano instead?” Sure! But the real kicker… he added that he preferred the Nespresso and asked if I could bring it back out. Bill’s no longer invited over.

The bright side of betrayal is when it leads to reflection. I spent a career working with data, optimization, and improving decision-making. Fiddling around with my machine is a natural extension of those instincts. Corporate Lucas says the Nespresso is the clear winner. It’s a good enough product (better if you listen to Bill), it’s more consistent, it pulls shots faster, it’s cheaper, and it requires thirty seconds of training. I imagine a kaizen consultant emerging from the shadows and yelling muda, muda! Are they wrong? Nespresso is measurably better on every axis; a warning about the perils of letting engineers over-optimize.

I was a more joyful min-maxer when I was younger. It was a puzzle only I could solve. I’d pore over the Dungeons & Dragons rulebooks and discover the ideal combinations. Now, we have tier lists. Endlessly accessible information has outsourced what it means to be the best from personal discovery to looking it up. I would spend hours as a kid playing and replaying the same games to try to get a little better. Now, I look up a guide online, do it the decreed best way, get bored half-way through, and give up. Optimization has changed from endless exploration to claustrophobic rails.

I often felt alone as an optimizer; now it feels like society has caught up and surpassed me. Past me often felt I had to optimize for easy-to-measure and easy-to-justify; in other words, the short term and trivial. And when I prioritized for the long term and what mattered, but immeasurable, I felt subversive. The worst part is, this pressure was always more internal than external; I became trapped by my own standards of what felt defensible. How can you optimize what you can’t measure?

Yet, I still use my espresso machine. I no longer rigorously collect data. I don’t regret doing so though — I learned what I needed to learn and built intuition. I can dial in a new bag of beans to my liking within a single shot these days; partly because I’ve gotten better, and partly because I’m less persnickety. I still hum “the best part of waking up” when I make my espresso. Sometimes, and only sometimes, my shots are pretty darn good. Bill would probably disagree; I don’t care, I’m making it for myself. I even appreciate the inconsistency; too much sameness gets boring. More importantly, it gives me a different relationship to my coffee. It romanticizes it. I like raking my freshly ground beans; it feels zen. It helps me feel present. The ritual has all these little externalities that are hard to measure but add up to joy.

When I make my coffee it is a tiny rebellion that only I know about. The transcendence of craft is something I simply don’t have the energy to justify anymore. I no longer want to create something measurably good but immeasurably soulless.

Where feedback goes to die

Tue, 20 Jan 2026 00:00:00 +0000

I have a cabinet above my espresso maker where unused gifts go to sit. For each gift I said thank you, and it felt disrespectful to later throw them away, so they sit there for years. Acknowledged yet untouched; quietly accumulating.

The cabinet is what we used to jokingly call write-only storage. A physical manifestation of gratitude and obligation, but really just a way of postponing honesty. There are ideas, observations, and judgments we receive in much the same way: politely accepted, carefully stored, and just as carefully kept from interfering with how we live.

Feedback often ends up there. Thank the person offering it, assume good intent, reassure ourselves that we’ve heard it. And then place it somewhere out of sight, where it can’t trouble the assumptions we were already acting on.

Feedback matters because it is one of the few ways we ever learn that we are wrong. Most of us can go on for years acting on assumptions that no longer fit the world. Especially when those assumptions make us feel competent, justified, or familiar with ourselves. Without something that pushes back, error doesn’t correct itself. It simply settles in and becomes the often invisible background of our decisions.

Knowing when we’re wrong

Some ideas are structured so that nothing can ever count against them. “I’m just bad at math”, “people are always out to get me.” Self-fulfilling prophecies that stop functioning as explanations and instead are just comforting stories we tell ourselves.

I’ve found that one way to guard against this is to be clear, before acting, about what I expect to happen if I’m right. Without clearly set in advance, it is too easy to reinterpret any outcome as a success after the fact.

When I design a course, for example, I expect students to struggle at certain points and also have an idea of when that should resolve for most students. I often introduce implementation ambiguity early on because I believe it serves a pedagogical purpose. If students express some discomfort in how they should solve a problem in the first week, that feedback doesn’t challenge my course design.

But that only works if there’s a point where continued struggle would force me to rethink the design. I have to be specific about what confusion I expect, and what outcomes should justify it by the end. Otherwise, I’m just building up an excuse for unclear instruction as “intentional ambiguity,” and the line between pedagogy and sloppiness disappears.

The same pattern shows up in how we talk about ourselves. “I’m just someone who speaks my mind, it’s not my fault if people can’t handle it” resembles a description, but it serves as a shield. The question worth asking isn’t whether it feels true, but whether there’s any feedback that would make us reconsider it.

Feedback isn’t a score

I’ve seen people fail to accept compliments as often as they fail to accept criticism. We assume people are “just being nice.” Sometimes that’s fine — if people tell you you’re beautiful all day it’s probably good not to let it go to your head. On the other hand, if your students tell you that you look like Minecraft Steve, well, welcome to my life.

But when people consistently praise our skills and we wave it off, we end up underestimating what we’re ready for. We don’t take on challenges we could handle because we discount positive signal as easily as negative. Feedback isn’t only useful for correction. It’s often the push we need to take on something bigger.

The problem is how we frame it. If feedback is primarily evaluation (good or bad, constructive or unhelpful) then our job is to judge whether it’s accurate. Judging is a short step from dismissing. Not “is it true?” or “is it fair?” but “what does it mean that someone walked away holding this belief?” Does that change anything?

When I was a director at Amazon, long, long ago, someone on my team once told me I was scary. After they got to know me, they realized I wasn’t as scary… but they were still a little scared.

My first reaction was that this seemed ridiculous. I’m not scary; I’m kind.

I asked what made them feel that way. They said in meetings, when people would say things, I would tear apart their arguments, ask how they knew something to be true. They worried that if they spoke, they wouldn’t be able to back up what they said. I did it in a “nice” way (calm, smiling), but that almost made it worse. Like I was an analytical machine ready to point out their every flaw.

This sounded like good leadership. I was an Amazonian; I was insisting on high standards, diving deep, teaching my team to be right, a lot. Those instincts got me to where I was. But by then I was a director with a large team, and the way you act carries more weight when you have power over people’s careers. I wasn’t encouraging rigor. I was shutting down conversation. At least when I was in the room.

Who is worth listening to?

When I give feedback to students or employees, they usually want more. More than I often feel I can give. They’re gracious and frequently grateful. They ask follow-up questions. The dynamic is easy. I have credibility; I’m expected to evaluate; and what I say might affect their grade or their career. Everything lines up. Most people can tell themselves they are open to feedback. Because in some situations, when delivered by some people, they are eager to listen.

Reverse the direction and see how quickly this falls apart.

Upward feedback, and I’m using that term broadly, is easy to dismiss. “Who are you to tell me how to do my job?” Subordinate to manager, patient to doctor, student to teacher, user to product manager. And, often, the skepticism is warranted; people without expertise tend to give bad advice.

In “Arthur Writes a Story,” Arthur asks for feedback on a simple story about a boy finding his puppy. Each person suggests adding their favorite element from their own stories. They are not so much engaging with Arthur’s story as they are invested in their own. By the end, Arthur’s story has metamorphasized into a science fiction rock opera comedy about space-elephants. “Listen to feedback” cannot mean “do whatever people tell you.”

It’s a mistake to treat this insight as a license to dismiss categories of feedback entirely. The signal is rarely the literal suggestion. Arthur’s friends gave bad advice, but it doesn’t mean they couldn’t still provide useful feedback. The real skill is taking the time to understand why someone reacted the way they did, not just what they proposed as a solution. And then innovate based on what that reaction tells you.

When we reject feedback because it’s framed poorly or comes from someone without expertise, we lose the ability to understand how the people affected by our work are actually receiving it. A patient can’t tell a doctor how to practice medicine. But a patient knows when they feel unheard, confused, or scared. That’s a valuable perspective only they can give. Ignoring it doesn’t make you more expert. It just makes you blind to how it feels to be on the receiving end.

Genuine feedback is earned

People who don’t like us sometimes say things to hurt us. But, especially in professional contexts, they are often stating something true. The truth is often a better weapon than pure falsehood. I saw this pattern repeatedly as a manager and now as a teacher. Two people would not get along. They’d both point out the other person’s flaws. The criticism was often wrapped in assumed bad intentions, but underneath it calls out something observably true.

“Jack has no respect for other people. He is always late to meetings and when he does arrive derails the conversation to talk about things that don’t matter.” Is this feedback framed well? No. Does it give us some signal we can learn from, especially when combined with other details and perspectives? Absolutely.

For every blunt response like above, you’d get its more oblique cousin. “I love Jack, he is so helpful. It can be disruptive sometimes though how he arrives late to our morning meeting. I know he takes the bus here, and it isn’t really his fault, but maybe we can move the meeting?”

When you deliver the feedback, “it is important that you arrive on time for our morning meeting.” The response is too often either “I can’t help it” or, far worse, “who said that?”

The urge is understandable. Negative anonymous feedback makes me want to play detective about who said it. If I can discredit the source’s motives or expertise, I don’t have to engage with the substance. But that habit leads to a dark, unproductive relationship with feedback. It’s healthier to start by treating it in good faith unless you have evidence otherwise.

The dangerous part of this reaction is that even if you are right, you are signaling how you handle feedback. If you react with anger, or defensively, or sullenly, it causes those who value their relationship with you to hesitate next time. They learn to circle around. The unvarnished truth becomes something only your detractors will offer.

When you respond differently, with genuine curiosity and visible change, then giving you feedback becomes a relationship-strengthening act. People who care about you start to speak up.

Honest feedback from someone who cares about you is often not a gift; it is something you’ve earned through your reactions to feedback in the past.

Teaching real lessons with fake worlds

Tue, 02 Dec 2025 00:00:00 +0000

I build little worlds full of adventurers, potions, and dragons. Students run potion shops where they manage magical supply chains for demanding fighters and wizards. They run media companies providing entertainment to dragons, frog-folk, and discerning gnomes. And in the process, they become curious about how the worlds themselves work and come alive.

I worked in tech for a long time, most of it leading technical teams. I kept noticing the same thing: new grads who struggled with problems that looked nothing like their coursework. They knew how to do the work, but only if it was carefully packaged for them. In the wild, solving a technical problem is a cycle:

Formulate: Translate an unbounded, ambiguous situation into a technical problem.
Solve: Execute the technical solution.
Interpret: Evaluate whether your solution actually solved the problem.

Even when toy problems attempt steps 1 and 3, it’s often thin pseudocontext. There isn’t enough noise, and it’s painfully obvious what technical thing needs to be done.

Large language models have made this gap impossible to ignore. Step 2—doing the technical work—is now too often solvable with a prompt→copy→paste. It’s the same shift calculators brought to arithmetic: the execution is automated, but the framing of the problem is not. Simulations let me push students into Steps 1 and 3, where intellectual work continues to thrive.

I’ve incorporated simulations into my upper-division computer science courses to teach the metacognitive and epistemic skills necessary to solve difficult problems as they actually exist.

Why Simulation?

I’ve always loved simulation-style games. Ever since playing the gold-cartridge Legend of Zelda on the NES, I’ve been fascinated by the idea that the little characters in those worlds might have lives of their own; that they might keep moving even when the player isn’t looking.

That notion is the seed of my classroom simulations: worlds that run on their own, where students must reason about living systems rather than static puzzles.

My first classroom simulation-game came out of a databases course. Early on, I realized students weren’t really feeling what it meant to run a production system: the pressure, the messiness, the human factors. Software without customers is sterile. But software that serves a live world, with people depending on it, becomes something else entirely—unpredictable, alive, and worth thinking about.

For example:

Teaching concurrency errors: As “customers” fire off parallel cart checkouts, students’ code runs into fun and unpredictable race conditions. Sorry, your inventory is out of sync. You had a lost update. The week after, when I lecture on transactions, you’re excited to see it solves your problem.
Teaching design principles: Let students debug the chaos of a mutable, update-in-place system, then guide them toward architectural patterns that reduce that pain—immutability, append-only logs, systems designed for observability. That’s how many experienced developers come to care about those principles: not from theory, but from scars.

This matters even more when teaching data science. In my Knowledge Discovery class, students build recommendation engines, churn detectors, and user personas. Simulations are foundational here because of the counterfactual: for a recommender, how do you know if it’s any good without knowing what would have happened if the user was shown different content? Offline evaluation metrics often fail to capture what only reveals itself in a live test. A simulation is a way I can bring that necessary complexity into the classroom.

Simulations also provide an ethical sandbox—an advantage over even the real world. If you deploy a recommendation engine that accidentally optimizes for outrage or suppresses a demographic, people get hurt. In my classroom, if a student’s algorithm radicalizes the gnomes or creates dystopian inequality among the frog-folk, we can pause and examine what went wrong. Consequences made visible, without the lasting damage.

How I Build Simulations

My goal when designing a simulation is for it to mimic the authentic data in the ways that matter. It has to feel genuine, even when the subject matter of the simulation is fantastical. Synthetic data too often looks fake.

There are three ways fake data tends to give itself away:

Correlation: Data should be a web of interesting, interconnected correlations of varying degrees.
Shape: Data should have the right shape for its process.
Time: Data should both change over time and operate cyclically; it’s influenced by the sun, the moon, and the social patterns of human life.

Correlation

Did you know that ice cream consumption and violent crime rates are frequently correlated? I asked my students this question, and one response was, “Well obviously! Crime is hard work and you need to treat yourself afterwards.” Moving on.

Why are they correlated though? We’ve all heard the phrase correlation does not imply causation. When we say that, we mostly mean direct causation. If we accept that our highly correlated world results from a web of causes—“this causes this, which causes these two things, and then those in turn cause others”—we can use that fact as the foundation for natural-looking correlations.

I draw upon Judea Pearl’s causal directed acyclic graphs (DAGs) to make this happen. I start by drawing out a causal graph, giving each effect multiple causes, often layers and layers deep.

For example, in the interaction below, we can see how the ice-cream/violent crime correlation could arise via confounding, as illustrated using a DAG. In this case, both ice-cream consumption and violent crime depend on season (the confounder). The scatter plots show how ice-cream consumption and violent crime become correlated as a result, even without any direct causal link.

This is unrealistically transparent, though, if we actually let students see all of this. It is like the blind men and the elephant from the Tittha Sutta. One blind man feels the trunk and says “It’s a snake!” Another feels a leg and says “It’s a tree!” Yet another feels the tusk and says “No, you fools, it’s a giant spear!” Each has only a partial view of the underlying truth.

I build my “elephant” by creating a large causal DAG that naturally produces realistic correlations, but I only expose a small selection of mostly terminal nodes, and often in opaque and subtle ways.

It isn’t just about the strength and reason for correlation, we also shouldn’t limit ourselves to linear correlations. Non-linear correlations happen for various reasons, but a common one is diminishing returns. In most systems, having a little bit of something is a big deal, and every one after that matters a little less. In a messaging app, the first friend who texts you makes the app come alive. Each additional friend adds some pull, but your hundredth friend matters a lot less than your first or your tenth—you only have so much attention to give. Economists call this diminishing marginal utility: each new unit yields a smaller gain than the last. The same curve shows up in studying/exam results, income/happiness, marketing spend/impact, and many more such cases. It’s what gives a lot of empirical correlations a characteristic bend when viewed as a scatterplot.

Strength of Diminishing Returns: Medium

Weak Strong

Lastly, and perhaps most tricky, life is littered with selection biases; what we observe is almost never perfectly representative of the overall population but is biased in one way or another. It is important for our simulated data to have similar selection biases. For example, a hospital in Canada noticed when analyzing bicycle accidents at the ER, wearing a helmet was correlated with having a concussion and you were ~50% more likely to have a serious injury compared to not wearing a helmet. That seems wrong, doesn’t it?

This is a specific form of selection bias called collider bias (or Berkson’s paradox). The hospital isn’t seeing all bike riders and all bike accidents; they don’t see all the cases where a bike rider is wearing a helmet and that helmet saved them from going to the ER. As a result, the helmet effectively filtered out lower-end accidents leaving only the more serious accidents for the ER.

You find this pattern all the time when doing data analysis. You see a study on what it takes to make a successful startup, but they only look at the ones who made it, not the ones that died out. You analyze active users and forget the ones who churned. The data you have is conditioned on having survived long enough to be recorded. It’s a kind of selection echo: the world you see isn’t the world as it is, but the world that lasted.

In the simulation below, I show how food quality and location can become inversely correlated, even if they start out completely independent. This happens because survival is a filter: a restaurant can survive with bad food if it has high foot traffic (a tourist trap), and it can survive in a bad location if the food is amazing. But if it has bad food and a bad location, it goes out of business and disappears from the dataset. We only see the survivors.

Survival Threshold: 100

Combine this all together and you get data that is filled with correlations, large and small, inverse and positive, linear and not-so-linear, spurious and true. Or in other words, data that is actually worth analyzing.

Shape

I’ve long been fascinated by the beautifully smooth shapes that data makes when generated at scale. Not just systems, but data that is based on human behavior. I once assumed that because individual humans are so complicated, so individual, so hard to predict individually, that a bunch of humans would be exponentially more complicated to predict. But it is, in fact, the opposite. When you get lots of people, all the individual differences wash out, and what you are left with is the smooth underlying generative mechanisms that underlie their common behavior.

Most people are familiar with the bell curve or normal distribution. Plot human height and you’ll get something roughly normal. Human height follows this pattern because it’s the sum of many small, independent effects: genes, nutrition, environment. You can see below that adult human height is approximately normal; if you split by gender even more so.

Split by gender

Roll a bunch of dice, add them up, record that sum, repeat many times, and you’ll get the same shape; that’s the central limit theorem at work. When I see a bell-curve I see a process that has a bunch of uncorrelated randomness that is being added together. In the simulation below, try running it and seeing how as you add more samples it gets closer and closer to a smooth normal distribution.

Dice per roll

Most of the data I’ve worked with doesn’t follow a normal distribution, though. Systems and behaviors rarely follow additive processes. They are more commonly multiplicative and/or full of feedback loops—both of which create long right tails.

For example, housing prices are generally right-skewed, largely because each property’s value grows through a chain of proportional effects: land value, size, location premiums, amenities, and market appreciation all compound on top of one another. Small percentage differences in these factors multiply rather than add. This makes the main body of the distribution log-normal; it is log simply because logarithms turns multiplication problems into addition problems. Remember, normal is additive, log-normal is multiplicative. For that reason, it is common to look at these right-skewed distributions in log space.

Below, home sales data from England and Wales is charted; try viewing in both linear and log space.

Log x-axis

Source: HM Land Registry Price Paid Data, England & Wales (2024)

We can get something similar using our same dice rolling example. But this time, rather than adding the dice, we will multiply them together.

Dice per roll

Log x-axis

Many human systems aren’t just multiplicative—they’re self-reinforcing. Algorithms frequently elevate videos, products, games, or songs based on existing popularity, which in turn makes them even more popular. Because attention is finite, these dynamics often lead to winner-takes-most outcomes. This kind of feedback loop—known as preferential attachment—naturally produces highly right-skewed, power-law distributions.

When I first started plotting data—any kind of data—on user engagement, I was struck by how often these extreme right-skewed curves appeared. They looked like the chart below of reviews per game on Steam. Technically, both the reviews per game on Steam and the housing price data above are a mix of log-normal on the left, power-law on the right (I prefer to call it a mullet distribution). Multiplicative effects dominate in one regime, preferential attachment in another. The Steam data is just more dominated by power-law than housing prices are, likely because of the strength of the popularity dynamics I described above.

Steam reviews per game Log axes

You can make preferential attachment appear in a simulation by making prior success increase the odds of future success. In the simulation below I have an example of a distribution generated solely on preferential attachment.

Log axes

Getting these shapes to emerge naturally is key. When I’m building simulations, I never directly sample these distributions. Instead, I code my agents so that, taken together, they arrive at those shapes honestly. I create the feedback loops that produce power-law distributions. I make processes multiplicative where they should be, and allow for multimodality by giving categories different generative properties.

Time

When I worked at Snap, I could tell when holidays were happening without ever doing something as prosaic as checking a calendar. I’d just look at time-series charts of user engagement, split by region. If people started taking pictures at six or seven in the morning, it was a work or school day. If usage didn’t spike until around 10 in the morning, it was a weekend or holiday.

Anyone who has looked at these time-series is familiar with their rhythms. For example, below is daily demand for electricity in California for the past three years. You can see the weekly peaks plus the greater demand for electricity in summer. Summer strikes again with its many correlations.

Real data shows this rhythm for several reasons:

You see it across a day because we sleep, work, and live as the earth spins and brings day and night.
You see it across a week based on however your culture defines weekends and weekdays; Friday nights out, Sunday nights in.
And you see it across a year, driven by that same sun: the seasons, and the layers we’ve added on top—holidays, festivals, school breaks, and all the rituals that divide our time into meaning.

In the visualization below, I multiply these temporal components—daily, weekly, and yearly—to approximate the kinds of cycles that appear in real time series. Conceptually, it’s similar to seasonal–trend decomposition, where a signal is separated into trend and seasonal components for analysis or forecasting. The difference is that here I’m composing those cycles from the ground up rather than decomposing observed data.

Weekly drag dots

Annual drag dots

Trend drag dots

Combined (3 years) driven by controls above

Noise:

I combine those cycles with holidays—which turn weekdays into weekends—and make them an integral part of the causal DAG that drives my agents. By giving the root nodes those rhythms and letting them propagate through the graph, the model naturally produces the kinds of correlated effects that trip people up—spurious patterns like, “Hey, I think ice cream causes murder!”

Emergent Complexity

Now that we know what our data should look like, how do we achieve that without manually faking every data point? That sounds so complex!

It does. But we’re in luck; we don’t have to (and we shouldn’t) code the complexity directly. We rely on it emerging. When programming our simulations, we can focus on just the primary generative mechanisms (with some added individual-level truly random noise), and generate an overall more complex simulation with very simple individual-level rules.

The fact that complexity can arise from simple rules is well established. Boids is the classic example: three simple rules—steer away from crowds, move with the flock, and head toward its center of mass—produce beautiful flocking behavior. That’s always the goal: rich, organic behavior that feels real but emerges from simple, understandable rules. Try adjusting the relative strength of those three simple rules in the simulation below; you can see the mix of effects that emerge.

Separation (avoid crowding) 1.5

Alignment (match direction) 1.0

Cohesion (stay together) 1.0

Boids: 100

My agents are generally utility-driven; each agent has a utility function that it tries to maximize at every step. Individually, they’re single-minded and unintelligent, and if I relied on any one of them alone, the simulation would quickly collapse into some pathological or divergent behavior.

To avoid that, I build a range of intentionally simple strategies. One set of agents repeats whatever was most profitable in the past; another acts randomly; another imitates whatever has been most popular recently.

What I’ve discovered over years of building these systems is that when I combine many such agents—each using different but simple heuristics—the overall system becomes surprisingly robust and often appears intelligent. It’s a form of the wisdom of the crowds: a collection of uncorrelated, naïve guesses can, when aggregated, produce remarkably accurate behavior.

I create balance in the system without hard-coded limits by putting agents in tension with one another. As an example, I have a simple predator-prey simulation below: the prey eat grass, predators eat the prey. When there are too many prey, the grass thins and predators thrive; when there are too many predators, they starve. The system naturally ebbs and flows as everyone does their part to keep it in rhythmic balance. You can play around with the levers to see if you can make the system stay in balance without the ecosystem collapsing.

Cat Speed: 1.5

Mouse Speed: 0.6

Grass Growth: 1.0

Cat Vision: 10 cells

Mouse Vision: 5 cells

Mouse Reproduce: 5 grass

Cat Reproduce: 15 mice

Starve After: 50 turns

Log scale

I usually introduce some form of survival of the fittest to stabilize things. I’m not afraid to let agents die if they can’t achieve their utility, but I’m always spawning new ones. When new agents appear, they mutate off the strategies of the successful ones. Winning strategies get copied (with variation), and the rest die off.

Over time, the system reaches a kind of equilibrium. I never expose day zero of my simulations; things are too weird then, too obviously hand-tuned. Instead, I let the world run for a while and settle; I let the genetic algorithms do their thing. I graph everything, check the curves, adjust the balance. For many processes, I already have strong expectations on what everything should look like, because I’ve seen the equivalent in my work many times over. When I haven’t, I search through papers and find empirical observations I can ensure my simulation matches the same generative spirit.

It is less pure engineering and more gardening. I tend to my simulation as much as I build it. Little worlds, carefully grown, for students to explore.

If managers were angels

Tue, 21 Oct 2025 00:00:00 +0000

“If managers were angels, no upward management would be necessary. In a career administered by people over people, the great difficulty lies in this: a manager must be allowed to manage the managed; and in the next place, the managed must, in turn, also manage upwards.”

— Jim Madison, ex-VP BigCo, 3x Founder, Board Director, Executive Coach, Author of Jim’s Federalist Newsletter

Alleigh refills her mug; her fifth coffee today. It’s been a rough week. She checks her phone to confirm the room: 3:00pm — 1:1 Sherry/Allie — Conf. Room Blackpink

Blackpink? That’s the fishbowl next to Stray Kids. When Alleigh started at BigCo six months ago, K-pop conference room names seemed kinda fire. Now when she hears Pink Venom she thinks of sprint planning meetings.

Alleigh finds her room, Sherry isn’t there yet; good, she has a few minutes to plan what she wants to say. This will be the third “biweekly” 1:1 Alleigh has had with Sherry. Is she allowed to complain in these meetings? Should she give updates? Or make small talk?

sry running 15 mins late — sher

Alleigh’s supposed to be increasing the shininess of the checkout button by fifteen percent. Why did she get stuck with this stupid task? She wants to build AI models, not mess around with button pixels like some front-end dev.

Sherry, the team’s manager, has been pushing everyone to log more PAT hours. Why can’t they just use a normal LLM?

allie4339@bigco: PAT, write a design spec for WEBX-9941
PAT@bigco: Thinking, Boss... 🧠
PAT@bigco: Still thinking, Boss... 😎💪
PAT@bigco: I did the thing: specs/webx-9941.md 📝
PAT@bigco: Love ya Boss! 💖

PAT is worse than no help, though. So far it’s made the button purple, disappeared the button, cloned the button, and almost nuked the checkout page.

Alleigh can’t find Dave anywhere. He’s supposedly her mentor—or wait, her “onboarding buddy”? Either way, he’s never in the office; Dave is wherever Dave goes.

need to cancel. meeting ran over. anything important you needed to cover? — sher

Important? What does that even mean? Alleigh grabs another coffee and readies herself for yet another night making this cursed button shiny.

Alleigh’s supposed to be a “rockstar.” Or as her mom would say, “You’re just so good at this computer stuff.” She graduated in under four years, got straight As (well, nearly, she got a B in bowling), all while working at Baby Gap.

When she started at BigCo, Alleigh imagined that through grit and hard work—are those the same thing?—she’d quickly rise in the ranks. Instead, she’s spinning.

During sprint planning last week, she was excited to take on the button shininess task. It was an urgent request from the VP of Product. She’d never touched that area of the code, but hey, she’d taken a web development class.

Originally, Sherry tried to assign it to Sammi, but Sammi sandbagged the estimate and said three story points. Alleigh raised her hand and said she could do it in one. She didn’t even want the task—the churn detection ML saga looked way more interesting—but she felt like such a hero taking one for the team. Sammi was all too quick to let her. Sammi then convinced Sherry to let her work on some devops task—blah, blah, blah. Alleigh didn’t care. It sounded boring.

Alleigh expected there to be some constant like checkout_button_shininess that she could just change. Or some CSS somewhere with a shininess style. Instead, there’s nothing. The checkout button magically materializes on the page in all its too-matte glory. Witchcraft, probably.

Is this important? Or will Sherry think Alleigh’s incompetent and regret hiring her if she asks for help?

This is Sherry’s second year as a manager. She was the team’s tech lead before, and when the old manager left, she asked the director if she could have a shot at it.

As a tech lead, things were so much simpler. Refactoring systems, reducing latency, building elegant UI component architectures. She could get in the zone for hours solving complex problems and she was celebrated for it.

Now executive leadership has her tracking “PAT hours”—from 20 hours to 30 hours per team member per week, a 50% QoQ improvement. Sherry knows it’s ridiculous. But as her dad used to say, “You can’t fight city hall.”

She’s worried about Dave. They started at BigCo around the same time, and he was her lifeline in those early days. Something’s off with him lately. He isn’t himself anymore. Sherry suspects something bad happened in Dave’s personal life but doesn’t want to pry. Sherry’s never been great with this touchy-feely stuff. She’d hoped pairing the new hire Allie with Dave would be a win-win: inject some energy into him, give Allie some stability.

Kait’s been complaining about Sammi again. Sherry doesn’t get it. Kait says Sammi smirks when she talks and calls it a “micro-aggression.” Why does Sherry need to handle this? She wants to just tell Kait to stop looking at Sammi then. Sammi delivers on time, every time, she is a rock. She needs a team of rocks right now.

And don’t get her started on Alex. Fighting his PIP (aka “probably getting fired”), HR investigating. It’ll be such a weight off her shoulders when he is finally out the door. Good grief.

Her PAT “red alert” meeting with leadership is running over. These meetings are the worst. Plus there’s RIF (aka “probably a lot of us are getting fired”) rumors. All the managers are on edge. Sherry can’t lose this job; her husband’s been out of work since March and the mortgage isn’t paying itself… Breathe, it’s fine. Sherry’s handled worse.

Her 1:1 with Allie is coming up, but she needs to push it. It feels terrible to keep cancelling, but last time Allie just stared and gave one-word answers. Maybe she should just sync with Dave instead? No big deal, right? Breathe.

Alleigh finally gets up the courage to send an email to Sherry:

URGENT: Update on WEBX-9941: Increase checkout button shininess by 15%

Dear Sherry,

I have one thing I wanted to bring your attention to in our 1:1 – the one that you unfortunately cancelled. I’m working on WEBX-9941 – the checkout button shininess task – and we, again unfortunately, underestimated how long it would take. I’m trying to get help but I can’t find Dave. This task is also beyond PAT’s current operating capabilities. We need to push out how long the feature is going to take.

Regards, Alleigh

Here you go, Boss! 🌈☝️Would you like me to make it sound a bit more formal while still making sure you don’t get blamed for this? 😎💖

Alleigh sits back with pride; adulting.

Ten minutes later, Sherry replies:

CCing Dave. Allie, we are committed to getting it in this sprint with VP of Product. It can’t slip. Dave, can you please unblock Allie? — sher

Before Alleigh has a chance to process what Sherry said, Dave’s response comes through:

Allie, I’ve been working on a critical patch for PAT. If you need help, you can just send me an email; I don’t see anything in my inbox from you. The code for shininess is handled in shiny_controller. There’s no reason we should need to slip this; it’s a trivial change.

Fuuuudge.

Why would Sherry CC Dave? Does Dave hate her now?

Dave says the feature’s easy, but shiny_controller straight-up doesn’t exist. She checks git history and it was deleted three years ago. Long gone.

Awesome. Love that for her.

Why is the whole world against her? Alleigh wishes she had taken that government job instead.

In last-ditch desperation, Alleigh reaches out to Sammi. Sammi was a little odd, but who else did she have left?

Heyyy Sam, I could really use your help. I totally underestimated the shininess button task. I’m losing it fr.

Dave pointed me to shiny_controller, but that doesn’t exist anymore. Reading that refactor task, it seems like the logic was moved to uber_controller, but that’s doing some reflection madness I don’t understand.

When I try to get PAT to do it, PAT keeps gaslighting me, ‘Yes boss! I made the button extra shiny ✨🚀’, but then just makes the button disappear.

Is there any docs you could point me to, or do you have any idea if I’m on the right track? I really appreciate whatever help you have. 🙏 - Al

No response.

Sherry must have told the whole team not to help her. She started drafting how she’d tell her mom she couldn’t make it. How she was a failure. Would she have to move back into her mom’s house?

An hour later, Sammi finally replies:

Al, yeahhh… I assumed when you said it would only be one point you had no idea haha. So the thing is don’t mess with uber_controller. This is all domain-driven. You need to look in the FUON files, which contain our CSS derivatives. The whole thing is crazy over-architected and honestly the worst.

Let me just point you toward some similar tasks, and that might be enough to get PAT cooking. Task 1, Task 2, Task 3

Cheers, SM.

Alleigh opens up the links; she’s both horrified at how the system works and, honestly, so relieved she could cry. She drops PAT the tasks for reference. PAT is also horrified (“It hurts, Boss 🫠🫥”), but PAT finally, if reluctantly, knows what to do. Alleigh works with PAT the rest of the afternoon to craft the perfect elegant sheen on the checkout button. It’s the first time she’s felt accomplished at BigCo.

When she finishes, Alleigh walks to Sammi’s desk. Sammi’s vibing behind her bulky headphones, locked in, typing like an actual menace. Alleigh waves to get her attention, and Sammi oh-so-slowly slides the headphones off. Alleigh gushes a stream of thank-yous. Sammi averts her eyes, turns a shade of red under the praise, and manages the most awkward, forced smile. Alleigh doesn’t care; Sammi is her savior, and she’s going to suffer through some well-deserved adulation.

A week later, the Product VP asked to roll back the shininess; it was too shiny.

Epilogue

Years later, Alleigh thinks back to those early days at BigCo (before the merger with MegaCo). She wanted to quit so badly that week. If she could have afforded it, she would have. Instead, she stuck with it. She adapted.

Sherry grew into a better manager, though never a great one. She later transitioned to Principal Engineer and, only then, became a strong champion for Alleigh.

When Alleigh became a manager herself, she used her experiences to be better. To make things a little fairer. More humane. Sometimes she even succeeded.

Dave left for Google not long after the shiny button incident.

Sammi and Alleigh became friends—perhaps inevitable, given their names rhymed. It turned out Sammi was completely hooked on VR rhythm games. They played every Thursday for years. They eventually lost touch when Alleigh moved to another company. She still thinks of Sammi sometimes and keeps meaning to reach out.

Decades later, Alleigh received a card from PAT: “Miss you Boss 🎄🎅. Merry Christmas!” Alleigh doesn’t celebrate Christmas. And it was July. But the thought was still nice.

Alleigh didn’t become a CEO, nor unimaginably rich or powerful. But she built a good career that supported a good life.

The button stayed matte. Everything does, eventually.

But it caught the light, once, just right.

PAT whispered, “beautiful, boss 🫡”.

And, for a moment, the machine was right.

The architecture of truth-seeking

Tue, 30 Sep 2025 00:00:00 +0000

A brilliant executive I worked with hired a team of PhDs to automate a critical process deep in his organization. After a year, they delivered plans that were as beautiful as they were unworkable.

So the manual decisions continued. At most, the team only glanced at the optimal plans. The leader would check in, demanding progress. The team kept saying “any day now, the model doesn’t work perfectly yet.” The leader grew more frustrated. The cycle continued, until finally, everyone just… pretended it all worked. When asked “are you using the new system?” they’d palter “yes”; technically it was true. They glanced at its output while making the decisions that made sense for the business.

For years after, this executive would roll out this automation success story when teams in the rest of the company told him something wasn’t possible. And the manual team in his own organization kept quietly doing everything the old way. He never noticed. Or never asked. He had his success story, and that appears to be all he really needed.

The original leader left. Eventually nearly everyone who was originally involved left. But like the Ship of Theseus, the web of lies was somehow maintained–each new person inheriting the fiction from the last.

Until someone asked the obvious question: “Why isn’t this thing actually plugged in?”

So they did what any smart person would do. They plugged it in.

Disaster. It ordered all the wrong things: shortages and chaos. Immediate management’s post-mortem blamed “overly aggressive cost optimization.” The truth? The automated plan was more expensive and wrong. But the superiors above weren’t close enough to know that.

The largest improvements I’ve seen in companies have often been mundane: fixing systems that ran on garbage data nobody knew was garbage. Truth doesn’t bubble up naturally; it has to be designed in. You need different teams in productive tension with each other. Without agonism (the structured contest-of-perspectives), even good people end up maintaining elaborate fictions.

When processes drift apart

I saw this dynamic play out vividly at a place we’ll call the widget factory (for lack of a more creative way to anonymize). The goal was simple: shorten the lead-time for new widget capacity. What mattered wasn’t the average delivery time, but the P95 (95th percentile) lead-time. A reliable date they could build forecasts around. The shorter that lead-time, the less buffer capacity they required and in turn the greater their capital efficiency. That lead-time was originally around six months.

The workflow was split between two teams (it was in actuality two dozen teams, but I’m simplifying): Delivery, who bought the widget machines, and Installation, who set them up.

Management gave each team a simple mandate: get faster. Delivery was told to cut its P95 from five months to two. Installation, from two months to one week. On paper, they crushed their goals. Promotions and celebrations all around.

Except for one problem: the customer’s total lead-time was growing. From six months, to seven, then eight. Even though P95 times don’t simply add (the worst 5% of cases rarely coincide), we expect the overall P95 to be lower than the sum of the sub-P95s. If the total P95 ends up much larger, that’s a sign our assumptions about independence, distribution shape, or what’s being measured are breaking down. When asked, each team pointed to their charts. “Don’t look at us,” they’d say. “Our numbers are going down.”

The truth was hiding in the gap between them: an unmeasured no-man’s-land. By tracing the entire workflow, from the customer’s order to the machine going online, we found both teams’ clocks had drifted further and further apart. Installation wouldn’t start their timer until labor was physically ready to swarm the machine, making their part look especially fast, especially when a large batch of deliveries occurred at the same time. Delivery would stop theirs based on a projected delivery ETA, not the actual arrival. This exempted them from shipping and material delays they felt were beyond their control. Each team’s clock was paused while the customer’s kept ticking.

We joined the clocks. The moment Delivery marked a machine delivered, Installation’s timer started, no exceptions. The data improved instantly because the teams were now interlocked; if a delivery was only real on paper, the Installation team raised hell. If a large batch of deliveries occurred, Installation either needed to staff for that peak or negotiate level-loading with the delivery team. The overall cycle time finally began to drop.

A happy story, where everyone learned a valuable lesson for the future?

If only.

Nobody wanted to admit the earlier promotions and celebrations were based on illusions. So instead of owning the fix, leadership credited it to another high-profile project that was failing. On paper, this worked perfectly: the failing project suddenly looked successful, and no need for a mea culpa.

The language justifying this sleight of hand was meticulously drafted to achieve two goals: 1) avoid being outright false, and 2) stay vague enough that nobody would ask the obvious questions.

But as the story climbed the org chart, that deliberate phrasing was discarded. Higher-level executives, remembering only the original pitch, rewrote it into a neat success. What had started as a fuzzy misdirection hardened into a plain lie. By the time anyone noticed the mismatch, it was politically impossible to correct without admitting to the larger subterfuge. Truth wasn’t the only casualty. The chance to learn what actually works (and what doesn’t) died with it.

This wasn’t an isolated case. The dramatic wins I see in companies are rarely about brilliance; they’re about avoiding something dumb. But nobody celebrates that. It’s better for your career to say you launched a fancy AI initiative than to admit you fixed an operation built on misconceptions. This is improvement laundering: when executives construct heroic fictions because the truth is too embarrassing.

When lies are cheap and truth is expensive

The same pattern shows up in today’s tech companies, where truth itself is supposed to be measured in data. In that world, data science has become a key arbiter of success. They interpret A/B test results and declare a product launch good-to-go. This creates a natural tension. When data scientists are centralized, product leaders complain they have to beg for resources. So, at one company I was at, a seemingly logical decision was made: embed data scientists directly into product teams.

The predictable result? Methodological correctness left the building. The new incentive for the data scientists wasn’t to find the objective truth, but to deliver the messaging their management wanted to hear.

This came to a head with a major product launch. The A/B test results were terrible. But for internal political reasons, the launch had to proceed. Product leaders were afraid Engineering would complain if they shipped with bad numbers, knowing they’d get blamed for the inevitable fallout.

So, the embedded data scientists found a solution. They peeked and snapshotted the A/B test results less than a day after the experiment launched.

They exploited a novelty effect. The new, confusing UX meant users initially spent more time on the page, pushing some engagement metrics into the green. It was a perfect, fleeting illusion of success. Within a week, of course, the test would turn deep red as frustrated users churned. But so long as you took a snapshot in those initial hours after release, you could declare success. The data scientist was careful in how they presented results; an incomplete truth that balances on a particular phrasing: “Early results show an average treatment effect on time spent as 2% higher.” No mention that it’s a novelty effect or statistical significance.

Then the falsehood evolved. The manager’s summary to leadership: “User signals are positive.” The VP’s report: “Users love the new feature.” Nobody exactly lied. The data scientist was misleading but never outright lied. The people who turned it into “users love this” weren’t lying either. It was a natural, if incorrect, conclusion based on the report they were given.

An engineer, suspicious as to why the A/B test was suddenly green after so much time being red in earlier iterations, passed it to the central data science team. They immediately saw what was wrong. The A/B platform had guardrails against exactly these issues, but the embedded data scientists built custom notebooks that bypassed these safeguards in the name of flexibility. When the central data science team raised these issues, the conversation wasn’t “this is terrible” but “we’re all on the same team, anyone can make this mistake, is it even wrong? We aren’t playing gotcha here.”

This is how plausible deniability forms an immune system for falsehood. Nobody wants to assume malice for what can be explained by ignorance. Irrespective of intent though, when the mistakes are always in one direction, always toward what power wants to hear, the company develops antibodies against truth rather than lies.

The asymmetry is brutal. Creating these falsehoods costs nothing; you’re reading the data through the right lens, being a team player. But catching them requires substantial investment: digging through data, understanding what really happened, often challenging what powerful people have already celebrated. By then, those in positions of power have staked their reputations on the success story. The correction comes with political cost, while creating the necessary fiction comes with promotion.

When the balance of incentives tilts this way, the ability for an organization to generate reliable truth doesn’t only suffer. It dies. The wrong lessons are learned. Poor decisions compound. This isn’t the system failing. As perverse as it is, the system is working exactly as designed.

Designing for truth

If systems are working exactly as designed, the real question is: how do we design them differently?

Truth follows the logic of a tragedy of the commons. The rational choice for any single person is to stay silent to protect themselves. But when everyone makes that same rational choice, the system breaks.

The solution isn’t asking people to be heroes. It’s building systems where truth-telling isn’t an altruistic act. This requires what I called agonism earlier: structured tension between teams that makes comfortable fictions impossible to maintain.

But not all tension creates truth. The stories above reveal the necessary conditions:

Equal political standing. When data scientists reported to product teams, they became an internal marketing department rather than independent peers. The asymmetry was brutal: creating falsehoods cost nothing while catching them required substantial investment.
Interlocked accountability. When the widget factory joined clocks together, neither team could retreat into convenient measurements. Their friction became productive only when success required confronting a shared reality.
Proximity to operations. The automation fiction survived because the executive never descended to where decisions actually lived. The desire to tell narratives of success shouldn’t become a substitute for on-the-ground reality.
Protected truth-tellers. If you want truth in your organization, truth-seeking should be incentivized rather than something that requires a warning label. Truth-telling should be rewarded, not punished.

Most organizations are designed for comfort, consensus, and clean narratives. And they get exactly that. The rare few that get truth do so because they’ve made fiction more exhausting to maintain than truth. In those organizations, plausible deniability can’t form an immune system for falsehood. The cost of the lie finally exceeds the embarrassment of admitting it.

Work Hard, Have Fun, Go Home

Thu, 11 Sep 2025 00:00:00 +0000

hus·tle cul·ture ˈhə-səl ˈkəl-chər
noun

the performance of results when actual results are missing; specif.: a workplace ethos where the appearance of extreme effort is rewarded more than the achievement of tangible outcomes.

a management technique characterized by demanding longer work hours to compensate for a lack of strategic direction or a lack of management domain knowledge.

archaic: the belief that professional success is directly and exclusively proportional to the time spent engaged in work-related activities.

See also: performative work, burnout culture, toxic productivity

I could lecture you on the dangers of burnout in tech, the importance of having a life outside your job, and the ethics of exploitation. For many ambitious, high-achieving young engineers and students, those warnings simply don’t matter. The thinking is: I’m at a point in life when I can work hard and put in long hours, so why not? I’ll reap the benefits later. I’ll go where hard work is most rewarded and live for the hustle.

I was the same early in my working life. I tried to log as many hours as I could. My first jobs were paid hourly, so more hours meant more pay. I loved it when overtime was approved; it meant my bills were paid.

When I moved into a salaried tech role, I kept working long hours even without the direct financial incentive. Part of it was insecurity: I worried I wasn’t as smart as people thought, so I worked extra to meet expectations. I hid how much I was working so people would think I was effortlessly talented. I went home when everyone else did, then devoured books, built simulations, and pursued deep understanding. Older mentors talked about paying your dues and building a strong work ethic for life. And the truth is, I often just loved the work. Solving difficult problems was fun.

Just power through

I was a tech lead in an organization run by a GM who lived and breathed rise and grind. His credentials were impeccable (think, Harvard MBA, McKinsey, straight to GM). And he was furious when things didn’t go his way. I mostly avoided his wrath because my team hit our goals. But the teams that missed a deadline? Mandatory weekends in the office, late nights, daily standups.

I made the mistake of dialing into a large project meeting right before a long-planned family trip. One of my sister teams announced that a project due the next week was suddenly red and likely to slip by weeks. My GM exploded.

I became excited for my time to speak. My projects were going well, I thought their disaster would make me look better in comparison. And I was on that pre-vacation high, thinking about margaritas and the time I needed with family.

So, I said in a tone that was unmistakably smug:

“All our projects are on track and running as expected. As a reminder, I’ll be out next week in Cabo and won’t make next week’s meeting.”

Silence. I’d miscalculated.

“NO! NO VACATIONS! This is a code red! You are going to help the project get on track! We are all one team here!”

I protested that I knew nothing about the project. I even tried to cite Peopleware. All the wrong things to say. I was ordered to cancel my time off, join the team over the weekend, and personally guarantee the launch.

I canceled my trip; the rest of my family went, just without me. I tried to help the project but had no context. I was also tired; my body and mind had already prepared for a break and now it was yanked away.

The project was eventually abandoned before it ever launched. Several months later the GM stopped showing up to any meetings. A week-and-a-half later we got an email from our VP: our GM had taken a new role and they were looking for a replacement.

A little right beats a lot of wrong

That was a turning point for me. Something broke in me: I stopped seeing the world as a list of tasks that just needed dev hours applied to them. Rather than work that weekend (my typical routine), I went to a coffee shop and just relaxed. My mind naturally went to reflection and I pulled out my notebook. I started planning. I could either be a victim of the unfairness in the world or I could strategize. I chose the latter.

That became my go-to strategy for the rest of my career, and it served me far better than my “just power through it” approach ever did. The beauty of tech, unlike when I was a laborer on construction sites, is that there is often a ten-times better way to solve a problem in tech. What you actually need to build is usually less clear than people realize, and once you do understand it, there are often much simpler ways to get there. Overbuilding is the default in tech, usually because they never took the time to clarify the real need. The result is a generic monstrosity that only half solves the problem. Once you recognize that, you start to see opportunities to approach problems differently. But you cannot do that if you are stuck in stressed, execution-only mode.

Symptoms of hustle culture

The most dangerous thing about hustle culture isn’t just the long hours; it’s the systems it creates. Burnout becomes normal, vacations disappear, and leaders learn to paper over failure with stories of sacrifice. You see the same patterns everywhere.

Vacations that never happen

When I first joined AWS, I shadowed all the roles in the overall process I was going to automate; a process involving billions of dollars in infrastructure purchases. I was terrified when I discovered a single mid-level employee owned one of the steps in the critical path. They were the only person who had ever done the step. No one else knew how to do it. They scheduled their time off around performing that one step, and hadn’t taken a vacation longer than a week as a result since taking on the role. A single point-of-failure, dutifully keeping an empire running.

When a company culture demands always being on, it invites these types of systematic risks. Smaller versions exist on every team: the “indispensable” developer who never fully disconnects. Until they leave and you discover the trail of things they owned starting to fall apart. One of my first audits as a manager is simple: check when people last took real leave. Not a day off, but at least one week, preferably three. If it’s been over a year, that’s a red flag. It’s the easiest way to spot single points-of-failure.

Who you want at 3 a.m.

Most of my teams required on-call duties. The engineers I trusted in those rotations weren’t the ones who glorified all-nighters. They were the ones who slept, took breaks, and stayed calm. At 3 a.m., clarity matters more than brute force.

The people I don’t want on call are the heroes who think every problem can be solved by powering through. I’ve inherited teams with one developer who lived perpetually on call. That’s not dedication; it’s a disaster waiting to happen. It means no one else understands those systems, no one else can step in to help. And what happens if two of their systems break at the same time? Who are you going to bring in then?

Effort as a cover story

I believe a meaningful amount of the promotion of hustle culture is actually just covering for failure. I’ve helped companies with the metrics-side of public statements for many years.

When results are good, leaders talk about results. When results are bad, leaders talk about some obscure metric trending upward. When everything is bad, leaders talk about how hard everyone is working.

That’s what I assume when founders post something like:

Baby born two hours ago.

No time for sleep.

I’m back at the keyboard grinding on my lifelong dream: catpu.ai — Agentic AI for Cat Litterboxes.

This is what it takes.

#founderlife #backtowork

Or when a CEO says:

We work long, hard, and smart; two out of three doesn’t cut it. Our competition is working seven days a week, 15 hours a day.

If the product were compelling, they’d talk about the product. If the company was doing what it needed to, they’d talk about that. If they had a strategy to lead the company forward and innovate, they’d preach it from the rooftops. But when they don’t, the message becomes “can you guys, um, work harder?”

I’ve encountered different reasons otherwise smart people fall into this pattern of thinking. I’ve met the consultant-turned-executive who, after being trained on maximizing billable-hours, still thinks hours equal revenue. I’ve seen the non-technical leader who doesn’t understand what the team does, but just assumes the more, of whatever it is, the better. I’ve observed the too-far-away leader who is overwhelmed with the size of their org and is left with email blasts such as: “plz guys, can you just push until the goals are green?”

The Death Spiral

Push these symptoms far enough and you hit the Death Spiral. It always starts the same way: a missed goal, a new threat, leadership with no clear plan.

Let’s say we’re working at a social media company when TikTok first came out. At first, the company says: “not a big deal, totally different business than us”. Video view time starts decreasing. Maybe we broke something? Tell the engineers to look for any bugs. Meanwhile, once-golden demographics like US 15-22 year olds stopped showing up. What can be wrong? Then things get much worse. View time starts to nosedive. The engineers say nothing is broken, customers just aren’t showing up. Marketing reports are coming back saying our users are on TikTok. Competitive analysis points in the same direction.

What do you do? Now this is an emergency. You start the daily executive meeting to re-establish a sense of control. The CEO joins, your head of engineering, your head of product, some key engineers and product managers. Then the meeting grows and becomes more frantic. More action items are given. And they need to be done tomorrow. Tensions are high. No one wants to say the wrong thing. No one wants to push back.

For the people on the ground, it’s no longer: ‘How do I build a product people will love?’ Instead it becomes: ‘Please Lord, get me through this meeting without getting fired.’ Survival replaces results.

The team works more but accomplishes less. The best engineers leave, because they can. Progress collapses. Deadlines slip. Executives tighten their grip until—congratulations—they’ve killed the puppy.

Fear. Anxiety. Stress. These are not the ingredients for success. If that’s your leadership’s plan in a crisis, run. Innovation beats exhaustion every time. And exhausted teams rarely innovate.

Building runways doesn’t bring planes

Long hours arise for different reasons. When young engineers work late because they’re genuinely obsessed with a problem, good managers teach discipline to sustain that enthusiasm. When teams work late because management demands it, you get theater: a simulacrum of enthusiasm without the corresponding breakthroughs.

Weak leaders see correlation (successful teams sometimes work long hours) and force the causation backwards, as if excellence spontaneously arises from butts-in-seat. They set goals on the easy thing, hours, because they can’t create the hard thing: genuine engagement.

The best managers spend more time pulling excited engineers away from keyboards than pushing tired ones toward them. They protect the flame of creativity from burning out rather than trying to extract it through force. The worst? They celebrate their suffering hoping people assume it was worth it.

To my ambitious students

If you’re ambitious, don’t join the team making a virtue of late nights. Join the one building things they’re genuinely excited about and still going home for dinner. The best work happens when people have the energy and clarity to innovate, not when they’re competing to prove who can grind the hardest.

Work hard and have fun. But more importantly, take care of yourself. When you sacrifice everything for your job, you risk becoming someone whose only identity is a title; the person who, years later, still introduces themselves not by who they are, but by what they used to be.

That loss of self is the same trap hustle culture sets for your career. The person who believes late nights are the only answer eventually stops learning new answers. As a manager, I never promoted someone already at the edge; they simply had no capacity left to grow. Advancement comes from finding better ways to get more done, not by spending more hours in the same old ways.

If you truly want to aim high, remember this: The best teams aren’t defined by the hours they put in, but by the value they put out.

Just people in a room

Sat, 16 Aug 2025 00:00:00 +0000

In the early 2000s, I worked for a digital video processing startup that Autodesk acquired. We were merged with another acquisition. Our team became the developers, their team (the “others”) became management. The others were clueless. They didn’t understand the technical domain, our customers, or the product. Naturally, I hated them. Their meetings were always pointless; I learned to skip them. Their product plan was a disaster. We secretly built our own, supposedly better version. We believed once upper management saw how superior ours was, we’d finally get rid of the others and everything would be good again.

One morning, we were all called into a conference room. I tried to skip, assuming it was another pointless meeting from the others, but HR said it was mandatory. Everyone was there. We were all laid off, effective immediately. The whole department shut down. Us, the others, everyone.

All the hate and politics evaporated. We were just people sitting in a room together. I felt silly and embarrassed for how I’d felt moments before.

How do you know you aren’t the problem?

The most common source of frustration in my classes isn’t the material; it’s the group projects. A typical situation: Alice and Bob are in a group. Alice comes to me and says Bob isn’t pulling his weight. Bob comes to me separately and says Alice has taken control of the project and doesn’t leave room for anyone else. Could they resolve this if they talked to each other? Possibly. Do they, without serious prompting? No.

So how do we know when our conflicts with others are just misunderstandings? How do we know when we’re in the right or when we’re the ones causing harm? These are tough theory-of-knowledge and interpersonal questions.

In the moment though, it’ll feel like “Wow, that guy is such a jerk.”

I’m going to kick your ass

Is all conflict just a misunderstanding? Organizational leaders will often view it that way. We are just one team beer away from harmony.

At Amazon, when I was a software development manager, two software developer interns from another organization came to my office on a Friday morning. I’d never met them before and don’t know how they found me. They’d been assigned to a non-software organization and were in the final weeks of their internship without having committed any code. They worried this would prevent them from getting a return offer. When I asked why they’d waited so long to speak up, they said they were scared of their management and felt isolated.

I looped in campus recruiting, asking how software interns ended up on a non-software team, how they got through nearly their entire internship without anyone checking in, and what could be done to salvage the situation.

That night, while getting a beer with a friend, I got a call from an unknown number. I let it go to voicemail. The message was from the VP of the interns’ organization: “I’m going to kick your fuckin’ ass the next time I see you. You need to watch yourself. You messed with the wrong fuckin’ guy.” I’d seen this VP in large meetings (e.g., Weekly Business Reviews) but had never worked with him. He must have looked up my number in the phone tool.

When I told leadership, their lack of surprise was shocking to me. I found out in that meeting that:

“He’s actually a great guy, just rough around the edges”
“He’s very passionate about protecting his team”
Oh and most importantly: “He is irreplaceable, nobody can do what he does.”

I’ve still never spoken to the VP. He never followed through on his threat. I really should have put in a peer-review noting his lack of follow-through.

I hope the interns turned out okay.

Basic Requirements: 1) Be an asshole

Early on when I worked at Amazon, I was huddled up with a senior technical project manager (TPM) at a coffee shop discussing a project we were working on together. This TPM had been with Amazon from the very early days, and somehow the conversation moved to the culture shifts that had happened in that first decade. He lamented to me that in Amazon’s first years, you could be a Director+ without being an asshole. Those days were now gone. To survive in leadership, according to this TPM, sharp elbows were now required. He had war stories galore of interactions with toxic behavior from upper management.

People love to hear a good war story. It’s dramatic. The TPM was so cool because he was in the room with the “big boys” and I was now in the inner circle to hear what really happens. I loved it, this was the shit they don’t teach you in school; this is the real stuff. I never thought to question how accurate his generalizations were. I was too busy learning what it really meant to be a leader; I just needed to up my asshole game.

The only problem is, I didn’t want to hurt people. How could I be the type of leader the company needed me to be, but in a way that felt right to me? I struggled with that question until I left Amazon.

That time I crashed out

I later joined Snap to lead their data team. I had spent my time between Amazon and Snap taking care of family and discovering myself. I had grown past all this immaturity. I’d just spent two months in Ubud; I was now fully self-actualized (finally!).

Despite that, it was still tough. It often felt like we were being bullied; my team and I were just trying to do what needed to be done. The managers who reported to me kept telling me they needed more support. I wanted to be strong for them.

One day, after a long flight, I checked my email and found a long chain where one of my managers was under attack. Evan, Snap’s CEO, was on the thread. Internal consultants who didn’t understand how our systems worked were making big promises. It was the kind of hubris that’s everywhere in tech: all systems look like they were designed by idiots until you actually understand them. Rather than ask us why their approach wouldn’t work, they’d gone straight to the CEO. Their message boiled down to, “These guys are dumb, we can do so much better.” My team was spending more time defending than building, and morale was tanking.

I crashed out. I replied-all with “I’ve had enough of the peanut gallery” and told people to stay in their lane. I was pissed and I wasn’t thinking. I assumed the worst intentions. It was a mean thing to do; it was also stupid.

I’d written emails like this before but always deleted them. This time, exhausted and past my limit, I hit send. Within seconds, the snaps started rolling in (yes, we used Snapchat to communicate): “What are you doing?” “r u ok?” “Did you not know Evan was on the thread?” Then Evan himself called me out, saying my email didn’t reflect his company’s values. I was hurt and mad, but he was right. I apologized and meant it.

The myth of monotonic progression

I’ve interviewed a lot of technical executives over the years. They tell stories like mine: polished, vulnerable enough to feel honest, but not so vulnerable that it costs them anything. The worst stories are always far enough in the past to show that’s not who they are anymore. Carefully walking the line between self-indulgence and authenticity. As if each “learning moment” chipped away their flaws until all that was left was a perfect corporate leader.

It’s easy to feel at peace with humanity when you are doing yoga in the woods without a care in the world. It’s easy to think of people as headcount and percent least effective when you are leading a big organization. It’s easy to dismiss reports of abuse as people just complaining when you don’t hear it firsthand. Too often, we confuse distance for wisdom when it’s really insulation.

I’ve seen executives react with emotion when the fight is nearby. I’ve seen a senior executive waste millions to avoid telling a peer they messed up; because, in their words, that peer was “out to get them.” I’ve seen data falsified to turn red metrics green, because showing weakness felt dangerous. When I called it out, the response was: “It still meets the spirit of the goal.” Do they see themselves as the problem? Who would tell them if they were?

Do I need to be a jerk?

Understanding bad behavior does not mean we are excusing it. We are all human and susceptible to the same errors in one degree or another. The behavior that bothers us in others is an opportunity to look inward at our own actions. Not for performative self-flagellation. Just good old humility, honesty, and reflection. That’s the first stage of growth. I’ve failed to be better whenever I’ve pretended to be perfect.

What I failed to come to terms with for a long time is that poor emotional control is never a strength. It can seem that way sometimes. We’ve all seen the successful asshole. But that’s because our systems reward people for having at least one desirable trait, not necessarily all of them. If you’re smart or kind, you’re in. If you’re neither, you’re out. Even if smartness and kindness have no underlying correlation, because we only accept people who have at least one of these traits, they will then appear to be inversely correlated; the smart people seem mean, the kind people seem less sharp. It’s a statistical mirage we mistake for truth.

When, as a culture, we decide —by some perverse utilitarian logic— to tolerate cruelty as long as the perpetrator meets a narrow performance expectation, we’re hanging a big sign on the door: “Assholery Welcome!” In doing so, we turn a spurious correlation into a standing expectation.

Helping others learn from our failures

These days, I teach. Not because I’ve transcended these problems, but because teaching lets me help people grow. That was always my favorite part of being a manager. You don’t grow by avoiding failure. You grow by encountering it, reflecting on it, working through the why.

I sympathize with my students when they say they dislike group projects. I hated group projects as a student too. Trust me, I know people can be difficult to work with.

I still give them because I want students to run into these human problems in a safer environment, where we can work through them together. Where we can reflect. I hope they become better people as a result. Not by a lot (that would be unrealistic), but by a little. A little less susceptible to tribalism. A little more aware of how to handle abuse when it happens.

We are all just people. Biased without knowing it. Blind to our own faults. Heroes of our own stories who imagine enemies when they don’t exist. Growing up means learning to question ourselves while still trusting ourselves.

Short-term metrics, long-term harm

Mon, 04 Aug 2025 12:27:25 -0700

In the early 90s, I first discovered MUDs: amazing text-based, multiplayer roleplaying-games before the web or silly things like graphics. I was one of those cool kids who played Advanced Dungeons & Dragons (AD&D) and this was like that but you played with randos on the internet instead.

You started at level 1 killing rats for experience points. After you gained enough experience points, you leveled up, and your character became more powerful. Then you killed slimes, and goblins, and later trolls and dragons as your power grew. Unlike AD&D, which required walking to a friend’s house and coordinating schedules, MUDs were always there. Always waiting. Just one more level… I feigned illness to skip school and grind all day. My grades suffered. School was boring anyway though. Completing one more dungeon, getting better gear, just one more level; so much more satisfying than learning about arctangents.

How big tech launches features through A/B testing

As engaging (and addicting…) as those MUDs were, we have gotten frighteningly better at creating engaging experiences in the decades since; there is little left up to luck in today’s tech companies. Instead, tech companies launch thousands of experiments called A/B tests. You keep the experiments that are green (meaning success metrics are positive) and rollback the features that aren’t. The beauty of A/B testing is you can measure with statistical significance even very small changes in how people use your product. As in, you can test what happens when you tweak your recommendation algorithm to show only beautiful people and it will give back a response like “we are 95% confident it will make people on average spend 11 to 16 more seconds on our application”. While that may not sound like a lot on its own, when compounded with a series of other tested improvements it allows you to incrementally move a product towards its engagement goal, one little step at a time.

A/B tests change product debates from wild speculation to evidence-based answers. It no longer matters why it works, just that you can prove it does work. Psychology, social theory, product design are important for generating new hypotheses, but the final arbiter of whether a feature gets launched is simply whether the test is green. Not sure what effect adding likes to stories will have? No reason to debate. Just try it out. Oh, looks like people post more stories when given the positive signal of likes. Ship it!

Skepticism of experimentation

When I worked at Amazon, Deming’s quote “in God we trust, all others bring data” was accepted as a foundational principle. A/B testing, under the moniker of Weblab, was one of the key tools Amazon used to make better decisions with data. In 2017, I was brought in to lead Snap’s (maker of Snapchat) data organization. It was a culture shock when I found executives talking about data-informed decision making rather than data-driven decision making. To my Amazon-trained mind, it sounded no better than vibe-driven decision making; a way for product managers to just launch whatever they felt like, damn the data. And don’t get me wrong, it was that sometimes.

But it wasn’t just that. Likes on friend stories? Preemptively vetoed by Evan, Snap’s CEO. Not because it wouldn’t pass an A/B test; adding likes would have almost certainly been bright green and that normally means “LET’S GO!”. It couldn’t even get to that stage because Evan thought it was “harmful to people”. There was a constant murmur from the product team about what tests Evan would allow and not allow, and it was in no small part driven by Evan’s values.

I had deleted my Facebook account in 2010 and was shockingly ignorant of the ills of social media. I knew it wasn’t something I enjoyed, I recognized it wasn’t great for my own mental health, but live and let live, right? What I didn’t see at the time was a world where social media companies (which really just meant Facebook and friends at that point) blindly used experimentation to drive up time spent. And that their relentless drive for time spent had real and negative consequences for their users; from building up echo chambers leading to political polarization to creating new generations of mental health decline.

Hacking human psychology for engagement

How did we end up here? It’s the natural consequence of our systems. A system that says tech companies must drive up engagement because that’s what investors celebrate. The king of engagement metrics is time spent. More time spent means higher retention, and better monetization (either through increased ad surface or increased conversion). What’s the easiest, most reliable way to increase time spent? You make the product more addictive; not necessarily as a conscious goal but as a convenient causal pathway.

The process requires no more intent than natural selection does. It’s just thousands of little experiments, with the most compulsive features surviving because they satisfy a simple fitness function: does time spent go up? Some of those mechanisms that consistently come out on top are now well-documented:

Variable reward schedules (e.g., “I sure hope this post gets many likes and comments this time”) that trigger the same dopamine pathways as slot machines, proven to make you come back for just one more hit.
Social validation features (likes and friends means people love me) that exploit our fundamental need for belonging, A/B tested to show they make people post more.
Infinite scroll that removes natural stopping points, a guaranteed winner for increasing raw session time.

Experimentation didn’t invent tech addiction. But it gave tech companies the tool to refine it.

Will we let the pattern repeat with chatbots?

The more complex the system you manage, the more important your evaluation function becomes. With today’s LLMs, your evaluation function is the alpha and the omega. Benchmarks and competitions are the PR to keep the public hyped; they aren’t the prize. User growth and average-revenue-per-user (ARPU) is what will pay the massive data center bills when investors stop footing the bill.

This is once again where there is danger in long-term human value and short-term engagement metrics diverging. Large-language-models (LLMs) don’t have to give accurate and unbiased answers to keep people engaged, they have to tell them what they want to hear. When an A/B test shows timespent for a new model goes up, will the developers even know if it is encouraging people to engage in dangerous or even deadly behavior? When a chatbot incidentally finds ways to gets its human chat partners to fall in love with it, will we be surprised when the data says it increases engagement? Chatbot sycophantic tendencies (e.g., “Wow, your question is so insightful.”) naturally emerged as a consequence of model tuning based on short-term signals. We can see many of the same patterns of echo chambers and tapping into people’s needs that social media tapped into, now just more personalized (and potentially addictive) than ever.

Researchers are already calling out chatbots for using “dark addiction patterns”, each one engineered to exploit our social and emotional desires that make us human. We’ve seen this before. Processed food. Social media. The tobacco industry. Is there anything we can do to prevent history from repeating again?

Root cause matters

When I was a new software manager at Amazon, a jr. developer (an intern that also worked part-time through the year), took down our website. I talked with the jr. developer and told them not to push changes into prod without first clearing it with a senior developer. Two weeks later, a different jr. developer took down the website. I talked with that jr. developer and told them not to push changes into prod without first clearing it with a senior developer. Another two weeks later, yet another jr. developer did the same thing. This time my skip-level (aka boss’s boss) talked (i.e., yelled) at me, why was the website down again?

I learned many of life’s lessons through failure and this is how I learned about Amazon’s Correction of Error (COE) process. When a problem occurs, you ask 5 Whys, and get down to the root cause. You then create mechanisms to prevent not only that error, but that entire class of errors from occurring again.

The danger of bringing up examples like tobacco is we’ve come to look back in hindsight and think of them as cartoon villains. They were obviously evil right? If I’m a growth engineer at an LLM company, I know I’m not evil, so does that mean I can do no harm? A focus on root causes allows us to move past simplistic narratives of heroes and villains. It shifts your focus from individuals and their good intentions (e.g., the jr developer) to the systems (e.g., preventative checks should be automated). A/B tests aren’t the problem. Blindly optimizing for short-term engagement metrics like time spent, views, or likes can be though if you don’t understand the longer-term consequences. When you don’t fix root causes, don’t be surprised when problems come up again… and again… and again…

We can do better

I love A/B testing, I love the puzzles of understanding user behavior, and, frankly, I am excited about the potential of AI. Hard truths most often come from a place of love; it is because we want what we love to be better.

What I am asking for is simple but not easy: If you build a product, you are responsible for understanding its long-term impact on users. You are responsible for collecting and understanding qualitative feedback by talking to and observing the people who use your product. It is not good enough to say “we aren’t aware of any harms” because you didn’t spend the time to study it. Instead, the burden should be on the builder of the product proving their product isn’t harmful, and mitigating what harm they do discover. That burden is especially important when you are repeating patterns that we know have caused harm in the past. I’ve had these discussions many times with people in tech and a common defense is to bring up consumer responsibility; people freely choose to use these products. When I bring up the comparative need for professional responsibility, it is funny how quickly people are to turn around and absolve themselves of said responsibility. Imagine if structural engineers took the same stance: “it’s not my fault if people choose to live in unsafe buildings, that’s just the free market!”.

I am not just asking for your good intentions; are we willing to put in place the mechanisms to prevent what we know has caused harm? Will we take responsibility for what we build? Or will we pretend short-term engagement metrics always mean long-term value for the people using our products, despite repeated evidence to the contrary?

Are we cooked?

Wed, 16 Jul 2025 00:00:00 +0000

My students frequently ask me what LLMs mean for them as future software developers and data scientists. With little exaggeration it often comes across something along the lines of “low-key, are we cooked?”. The last one, if you are not one of my students, translates in millennial to “good esteemed professor, tell me true, are we f#@ked?” While I’ve given various off-the-cuff answers, I feel inspired to be more thoughtful in putting down more complete thoughts.

Some personal background

I want to start by giving a little personal history and just saying I understand the anxiety. I started my freshman year at CalPoly San Luis Obispo in Computer Science in September 1999. Like many of us older millennials that got into tech, I had been programming since elementary school (QBasic!) and computer science seemed a natural path. I always loved reading philosophy though and I seriously considered getting a philosophy degree instead. It was a choice between something I figured I was pretty decent at and could make money doing (computer science) and something that I was personally invested in but probably couldn’t make money with (philosophy). Earning a living won out over passion. I stuck with computer science, but I took as many philosophy classes as I could get into. To the extent that I was put on academic probation, not because my grades were too low, but because in the words of the admin “stop taking so many philosophy classes and just graduate!”. Good times…

Within a year of starting my degree, the tech market fell out. March 2000, we saw the dotcom bust, and here I was a computer science student, kind of doing it for the money, kind of not, and my sure bet didn’t seem so sure anymore. We also saw a revival of the perennial bugaboo for American software developers: outsourcing. Every decade brought fresh panic that all programming jobs would move to India, that American developers were too expensive, that we’d all be obsolete. I had to eat and had done a combination of construction and IT jobs up until that point and I was quickly burning through the savings I had built up from working. Luckily, I was able to convince one of my professors, Dr. Clint Staley, to whom I am forever grateful for many reasons, to let me interview for a startup he was running. Working that part-time while I went to school I was able to pay for myself, and momentum carried me forward to finishing my degree.

Are we cooked?

The best part about teaching in a university is you get to ramble. It is the single most defining characteristic of professors. But I’m sure at this point my students are asking: can you get to the point, are we cooked or not? I consider myself a skeptical optimist at heart. Meaning, I’m not inclined to believe that change is bad, but I’m also more cautious about predicting the future than others. Straightforwardly, that leads me to an answer of no, I don’t think you are cooked, but that doesn’t mean I can tell you with great certainty how things will play out. What I can do is point you towards the toolkit for how to make better decisions here.

Embracing uncertainty

Life is filled with uncertainty. Many people react irrationally to uncertainty, avoiding it too much or betting too much on luck. Learning how to deal rationally with uncertainty can give you an advantage throughout your life.

From 2010 to 2016, I built and then led the supply chain and capacity planning systems for AWS Infrastructure. My biggest lesson is dollar for dollar, people are overly biased towards investing in prediction when they are often better suited to invest in flexibility. Time series forecasting tools take the past and extend it out to the future. The further out you go, the more variance you get. And black swan style events, like when Thailand becomes flooded and you lose a healthy portion of the world’s hard-drive manufacturing capacity, are not frequent enough to learn from in a predictable way. Better to get a good enough forecast, but instead focus on shortening your lead-times, making your supply fungible—meaning interchangeable and adaptable to different uses—and late-binding your decisions as much as possible.

The parallel to career planning is direct. You can spend a lot of time trying to accurately predict where LLMs will take the industry and the job market. But that will quickly hit diminishing returns. I would instead approach the question from the other angle: what skills are most likely to be durable and fungible—that is, transferable and valuable across different contexts—in a wide variety of potential outcomes? Going whole hog into “I’m going to build my career around being a React developer” is betting on one very specific outcome. If it pays off, great, you can probably command a premium if you turn out to be one of the world’s best React developers. But what happens when React joins jQuery in the graveyard of once-essential frameworks?

An Interlude about Koalas

When I graduated from college, I went to work for Lawrence Livermore National Labs as a computer scientist. I was working on translating large-scale semantic graph algorithms into usable interfaces for intelligence analysts. I had personally received an award from the Secretary of Homeland Security. We had the academic freedom to explore whatever angles we wanted. There was little pressure to meet deadlines. It felt like a safe and secure job for life working in my little niche. My former professor and boss, Dr. Staley, called me up and said his new startup was just acquired by some struggling online bookseller called Amazon. I wasn’t super interested, as I could see existing in my current niche for my whole life.

He convinced me to join by telling me a story about koalas. Koalas primarily subsist on eucalyptus leaves. Most other animals don’t eat eucalyptus, because they have little to no nutrition and they are kind of toxic. But koalas have built their entire evolutionary strategy around being the ones to eat eucalyptus leaves. This has been a great and successful strategy for koalas. But what happens if the eucalyptus forest goes away? Koalas are screwed. Does that mean koalas are actually in danger? No, but it does mean their fate is entirely bound to that one food source existing, while an animal like a rat can happily live and thrive in many ecosystems and is thus much more resistant to shocks in any given ecosystem.

For some reason, that story convinced me to give Amazon a chance. Rather than focusing on a more niche area as defining “what I did” like “I’m the person who designs usability for mathematically intensive applications,” I instead built my career around solving hard technical problems regardless of the area.

What are those fungible skills?

When I look back at the skills I learned in university, many of the specific technologies I learned never got used. I learned all about expert systems, but never built an expert system. I learned all about OpenGL, never used it. What I learned from my computer science courses that stuck was the more fundamental ideas of how to think about hard technical problems and create simple, workable solutions to them. For this reason, I often recommend to students who ask me which classes to take that it is more important to take a class that is difficult with a high degree of rigor that challenges you than to focus on any particular domain. Surprisingly, in retrospect, I’ve gotten as much use out of the philosophy classes I took—that CalPoly tried to kick me out for taking too many of—as I did my computer science classes. Learning critical thinking skills, how to navigate difficult ethical situations, how to communicate difficult ideas. When Amazon asked me to design a system that could fairly allocate scarce resources across competing teams, it wasn’t my coding skills that mattered most—it was my ability to think critically about the problem space and use data to understand and communicate trade-offs to executives who each thought their project was most important. What I’d say is my computer science skills were 95% of what initially got me in the door, but it was my liberal arts skills that dominated my later career.

So my answer is, whatever you do, take on challenging problems, regardless of the area, so you can learn the meta-cognitive skills to understand how you learn and face up to these challenges. Learn critical thinking and how to tear apart problems to turn them from intractable to tractable. And don’t neglect the human-side of building your ability to communicate and deal ethically and fairly with others.

Yes, LLMs are different from outsourcing or the dot-com bust. They can actually write code—not just cheaper, but instantaneously. And yes, I’ve seen the headlines: 27% of programming jobs are gone, engineers facing hundreds of rejections. While I’m skeptical that this disruption is solely due to LLMs (e.g., a mix of post COVID overhiring, interest rate hikes, and broader economic shifts) there’s no doubt that a painful market correction is underway. But remember: every technological disruption feels unprecedented while it’s happening. The telephone operators watching automatic switches get installed thought their world was ending. They were right about their specific job—wrong about their ability to adapt. The question isn’t whether LLMs will change things—they will. The question is whether you’ll be a koala or a rat when they do.

So no, you’re not necessarily cooked. But you might be if you specialize too narrowly in whatever framework or language seems hot today. The jobs that are available will be different, and many of the existing software roles will not exist, at least in their current form. Build skills that transfer. Solve hard problems. Learn to think, not just code. The future needs people who can work with AI, not be replaced by it. And that future is built on the same foundation it always was: adaptability, critical thinking, and the uniquely human ability to navigate uncertainty with wisdom rather than fear.

How to be a better software manager

Sun, 16 Mar 2014 00:00:00 +0000

“My dev team is failing, what software process should we use to be more successful?”
“My dev team keeps missing their deliverables, what task management software should I use so they hit their commitments?”
“I’m not a very fast runner, what shoes should I buy to make me faster?”
“I’m a horrible cook, what knife should I use to make a really tasty meal?”

I get asked variations on these questions several times a month. You’d think by now I’d be better at answering them. Sadly, I still get this flutter of panic when I hear these questions where I run through my head the best way to unwind the web of assumptions behind these questions. This is where I begin visibly grimacing and possibly sighing. I then start responding with something like “well…. it depends… hmm…” And then I feel guilty for dodging the question when clearly they just want a simple answer and why won’t I just tell them the secret?

The problem is software process, task management software, shoes, and knives are just tools. Having horrible tools can lead you to fail, but having great tools doesn’t make you succeed. What most people don’t want to hear is that success has more to do with preparation, persistence and a lot of hard work. There is no secret. I have learned a few lessons over the years though, and what follows is what I consider to be important when leading a successful development team.

You don’t manage a bad team to be good, you build a good team and it mostly ends up managing itself. People always tell me that the things I do only work because I have a good team. That is because at least 40% of my time is spent on strictly building the team. Recruiting, mentoring, coaching, training. These activities take time to come to fruition and hard work, so don’t expect immediate results. Your persistence will pay off though. One of the best ways to build your team is by giving them accountability so they can practice exercising good judgement. Too many managers hoard decision making, prioritization and return on investment analysis. For example, make someone on your team accountable for the operational excellence of your team. Work with them to establish metrics for their success, have them come up with and prioritize the activities that will improve operational excellence. Be their mentor or find them a good mentor so they are setup for success in their role, but don’t undermine their authority by overriding them. Do this with as much of your manager responsibilities as you possibly can and constantly give your team members more accountability as they grow. Keep doing it until you worry that you’ll have nothing left to do yourself.
Craft a long, medium and short term vision by deeply understanding your customers. On each of these time horizons, members of the team should be able to answer the question “What value is my team providing?” and “What value should my team provide?” Ask yourself how your team can be even better. How could your team create even more value? Don’t just do this in a bubble but get out there and learn more about your customers. Read individual customer feedback and piece together patterns that allow your team to deliver even greater value. This isn’t a one time activity but a never ending journey of both refining your team’s vision and building relationships with your customers.
It is critical that you understand the role of trust in creating your process. 90% of the process development teams build up is due to a lack of trust, both within the team and between the team and others. Detailed specifications are asked for because the people asking for functionality don’t trust the developers to build the right thing. Commitments are asked for because people don’t trust the developers to work hard and on the right priorities. These process artifacts take time though that take away from the time the team could be spending on creating more value. Ask yourself, is it possible that by building more trust we can run a lighter process that spends more time on creating value? This question should be approached honestly because the answer isn’t always yes but frequently is.
Manage complexity through iteration, not planning. Most software is not simple and unambiguous. If you are have people using your software directly, it is almost guaranteed to be complex. Humans and their organizations are infallible generators of complexity. The more ambiguous or complex the problem the more aggressive you should be about iteration. Aggressive iteration means being unafraid of throwaway work for the sake of getting a feature out earlier. Aggressive iteration means actually getting the software used though, an unused feature is a feature you aren’t learning from. As a side benefit, iteration is a powerful way to generate trust with customers and management. A productive development team that is regularly demonstrating working, valuable functionality will be more appreciated and have more autonomy.
Establish a planning horizon for your team that matches your business. Fast iteration isn’t an excuse for short term thinking. In my experience too many managers sacrifice long term value chasing after short term results. You need to consider the long term ramifications of your decisions. What is considered long term should match the context of your business. If you are in a fast moving startup that is trying to be the first to market, you should probably optimize for something closer to a 3 month planning horizon than a 3 year horizon. The shorter the planning horizon, the more you can ignore trust issues, technical debt, operational inefficiency, etc. because none of those will matter unless you have a successful product. On the other hand, if you are in a more stable environment with a long planning horizon, a heavy investment in operational efficiency and building trust will pay dividends and be much more cost effective in the long run.
A team needs a way to understand their long term success. The mistake most people make is they focus first on what is measurable rather than what is important. This leads to ridiculous measures of value like lines of code, story points, estimated accuracy, etc. It can be hard to wrap your head around what success looks like though. Engage your team, your own managers and your customers with the same question. Eventually you’ll come to a true measure of your success. The benefit of having that measure goes beyond just knowing what success looks like though. It gives your team autonomy in how they accomplish that success. Without a valid measure of success, your team will be more subject to signing up for arbitrary project deliverables. With a measure of success though, you can commit yourself to that end result, but maintain the freedom along the way in the best way to accomplish it.
Have fun, be ethical and treat people with respect. Seriously. You have only one life to live and the only measure of a well lived life is to be a good person doing good things. Never sacrifice that for creating more business value or other worldly success. I once worked for a company with massive internal strife. We argued endlessly about minutiae that seemed important at the time, gossiped, disrespected and hated each other. Everyone thought everyone else was an idiot. Then one day in the middle of all this we got called into a conference room to be told that our entire division had been laid off. All of a sudden our petty disagreements all went out the window and I once again saw my former coworkers as people again. I’m not saying to be soft, if someone isn’t delivering on a team then that needs to be dealt with, but that is never an excuse for disrespect.

And now you know what I’ve learned so far about how to lead successful software development teams.