Growing Your Engineering Craft

Engineering craft is designing the smallest thing that solves the real problem and building it well: boring tech, readable output, AI directed to produce it. It is not cleverness and not future-proofing. Holding a system simple as it grows is one of the hardest things in engineering and the clearest sign of someone who understands what they are doing.

This page is how you move yourself up one rung on it. It is a mirror, not a scorecard: find the row just above where you sit, and put your reps there. The craft itself is the whole Engineering Craft group; this is the path through it.

Where you are now#

Find the line that matches the code you actually shipped last month.

What moves you up#

Craft climbs on one instinct getting stronger: remove, don’t add. The junior move is to write more; the senior move is to need less.

• Build for the problem you have, not the one you imagine. Asked for one flat discount code, you build a rules engine “because we will probably need it.” Usually you never do, and the machinery becomes a tax on every future change. Name the second real case that exists today, or do not build for it. See Keep It Simple.
• Choose boring. A new library or pattern is a cost every teammate pays learning it. The tool already in the codebase usually solves the problem with none of that tax. Reserve novelty for where it earns its keep, and say why when you spend it.
• Readable beats clever. Code is read far more often than written, by someone tired and debugging something else. If it needs you to narrate it, it is not finished, the same way a design that needs a tooltip is not finished.
• Own what the AI wrote. An AI-assisted codebase makes this matter more, not less. You direct, review, and vouch for the output; code you cannot read plainly is code you cannot own. See the whiteboard defense.

The habits that keep you stuck#

Complexity feels like progress while you are writing it. That is the trap, and everyone falls into it. Catch yourself here:

Bad: a configurable applyDiscounts(cart, { rules, strategy, schedule, stackable }), 200 lines, handling tiers and stacking and currencies, with one flat coupon in production and half the paths untested because no feature uses them.

Good: applyCode(cart, code) that looks up a percentage and returns the rounded total, six lines, and you add tiers the day a tier actually exists.

The tells that your craft is adding when it should be removing:

• Speculative flexibility: config, plugins, and options for cases nobody has asked for.
• Novelty with no justification: a new pattern where the existing one would have done.
• The clever one-liner that saves three lines and costs every reader a minute.
• A green checkmark on the happy path only, with the edges left as a hope. See Cover the Edge Cases.

The reps that level it up#

Move a rung by reaching for the next row’s restraint before it feels comfortable, then close the gap in review:

• Deliver the same outcome with half the parts. Take something you built and rewrite it smaller. If 200 lines could be 50, the 50 is the finished version, not a lesser one.
• Before you introduce anything new, find what is already here. Grep the codebase and the shared components first. The third parser and the second gesture handler are future rework you are signing up for.
• Write the code so a new teammate reads it without you in the room, then actually have one read it. If they need narration, keep going.
• Review someone else’s output for correctness, not style. Reviewing is where you learn to see the edges and the simpler approach faster than building does.

The one question#

Before you call a change done, ask: could this be smaller, and could someone who has never seen it tell me what it does?

If it could be smaller, it is not finished. If it needs narration, you do not own it yet.

Related: Thinking Like an Engineer, Keep It Simple, Cover the Edge Cases, One Change, One Place, Prove It Works, Using AI