Thinking Like an Engineer

Anyone can make code do a new thing. An engineer makes it do the new thing without breaking the old things, without bloating the system, and without leaving a mess the next person has to untangle. That gap, between making a change and owning its consequences, is what this group is about.

This is the engineering counterpart to Product Sense. Product sense is judgment about what to build. This is judgment about how to build it: how to keep a system simple as it grows, how to be sure it holds up when reality gets weird, and how to make one change land in one place instead of scattering edits across the codebase. With AI writing most of the code, this judgment is the job. The machine types; you decide what’s correct, what’s simple, and what fits.

The Failure Mode This Group Exists to Kill#

Give an under-thought engineer a task, “add a discount code to checkout”, and watch what happens. It works in the demo. Then:

• The discount math got pasted into the cart page, the checkout page, the order-confirmation email, and the admin, four copies, and next month a tax change updates three of them.
• A code worth more than the cart total produces a negative charge, because nobody asked “what if the discount is bigger than the price?”
• To support one flat coupon, they built a configurable rules engine with percentage tiers, stacking, and schedules that nobody asked for and everybody now maintains.
• The change touched nine files across five modules, and the reviewer can’t tell which edits are the feature and which are collateral.

Every one of those is a different failure of engineering judgment: duplicated truth, an unhandled edge, speculative complexity, and a change with no locality. The code “works.” It is still bad engineering, and it will cost the team for months.

Now here is what good looks like on the exact same task:

• The price calculation gets one home, computeTotal; the discount is a single new line there, and it flows to the cart, checkout, email, and admin because they all call it.
• A code over 100% clamps to zero, never a negative charge, with a test that pins that decision.
• One flat coupon is a lookup, VALID_CODES[code], not an engine. Tiers get added the day a tier actually exists.
• The diff touches computeTotal plus its call sites. A reviewer sees exactly what the feature is.

Same feature, same afternoon. One leaves four copies of the truth, a negative-charge bug, and an engine nobody needs; the other leaves a system where the next pricing change is one line. Both pass the demo. This group exists to make the first outcome feel as wrong to you as it should, and the second feel like the only option. (The full worked version is the case study.)

It’s the same shape as the symptom-collector vs. product-thinker split, one level down. The coder reacts to the surface. The engineer reasons about the system.

Understand Before You Change#

What’s expected: Before you edit a line, you can say how the thing works now, where the code you’re about to touch is used, and what depends on it.

The single most common cause of bad changes is changing code you don’t understand yet. You see where the symptom appears, edit there, and move on, never asking whether that’s where the problem actually lives or what else runs through it. That’s how a one-line “fix” breaks three features nobody connected to it.

How to get there: before touching anything, trace it. Where does this data come from, where does it go, who else calls this function? Read the callers, not just the function. Find the one place the behavior is actually decided; often there is one, and when there isn’t, that missing home is usually the thing to create. It’s rarely the screen where you noticed the problem. Reproduce the current behavior before you change it, so you know your change did what you think and nothing else moved. Understanding first is not slower; it’s what makes the change small and safe instead of a guess you’ll debug later. This is the Discover instinct applied to code: understand the real problem before you reach for a fix.

The Three Questions#

Every change worth the name answers three questions before it ships. Each has a doc:

Underneath all three sits one technique that makes each of them easier: Pure Functions & Immutability, code that doesn’t mutate what it’s handed or reach out and touch the world. It’s the habit that makes logic simple to read, trivial to test at the edges, and safe to move in one piece.

Two more docs round out what it takes to be trusted with production. Think in Events is the design judgment of when a system should react to facts rather than run a chain of commands. And Prove It Works is the other half of the whole job: showing a change is correct, watching it behave in production, and knowing the moment it breaks. Writing good code gets you halfway; proving it works is the rest.

Then Case Study: A Change Done Well runs one real change, adding a discount code to the Storefront checkout, through all of it, badly and then well, so you can see the difference in the diff.

The Standard#

We measure engineers on the systems they leave behind, not the tickets they close. Code that works today but is duplicated, fragile at the edges, and over-built is a liability wearing the costume of progress, it will slow every future change, including yours. The bar is not “does it work.” The bar is: the next person to touch this, including you in six months, finds it obvious, safe to change, and no bigger than it needed to be.

Understand before you change. Keep it small. Handle what breaks it. Change it in one place. That’s the whole job.

Next: Keep It Simple