Every other chapter is a craft. This one is the through-line that makes the craft pay off: a handful of plain habits, a few questions and one ratio, that keep a project pointed at the need and keep the work readable for whoever picks it up next.
For a stretch of years I ran small projects alone: eighteen of them, back to back, each one a board that had never been powered on and a customer who needed it to do something specific by a date. Sports glasses. A sonobuoy. An energy detector. A tunnel broadcast system. A file system on a memory part nobody had written one for. The projects had nothing in common except that they shipped in days or weeks, and the large programs I watched from a distance shipped, when they shipped, in years.
That gap bothered me enough to go looking for its cause, and the cause was never talent. The small projects had one person holding the whole problem, which meant every line written had to answer to the need in front of it. The large ones had process, layers, and reasons, and somewhere in all of that the need got lost. The principles below are what I wrote down when I tried to carry the small-project discipline into the large-project world. They are domain-agnostic on purpose: they apply to a satellite ground station and to a weekend script in equal measure, because each one is about the relationship between the work and the need it serves.
A short, shared vocabulary for the part of engineering the tools never teach: how to keep a project honest. Each principle is something you can say in a review, hand to a newer engineer, or hold yourself to on a quiet afternoon. Read them in order the first time; after that, reach for whichever one fits the day.
The principles are the discipline of one focused engineer, written down so a whole team can use it.
The most useful sentence in engineering is a question, and it is almost embarrassingly simple: what are you actually trying to do? Asked early and asked kindly, it gives everyone in the room the same target. A clear answer protects more schedule than any framework or tool ever has, because it heads off the most expensive outcome in all of engineering: building the wrong thing beautifully.
It works precisely because it is gentle. It assumes good faith, invites the asker to think out loud, and turns a vague request into something a team can aim at. When you offer that question to a teammate, you are handing over a clearer version of the goal than the one that walked in the door. The question is for this spec, this customer, this job. It is never for a hypothetical future, which has a way of answering on its own behalf.
Low signal
Build the thing that was asked for
Take the request at face value and start coding the literal ask. Quick off the line, and three weeks in, it turns out the ask was a guess at the real need.
vs
High signal
Build the thing that is needed
Spend five minutes on “what are you actually trying to do?” first. The real need surfaces, and the build aims at it from the very first line.
Before the first line of code, write one sentence: “This exists so that…” If the sentence is hard to finish, that is the work for today, and it is cheaper to do now than at integration.
Nobody has ever missed a deadline because the goal was too clearly stated.
Name the need first. Everything good downstream, the requirements, the design, the tests, follows from a need stated plainly.
Borrow a term from the radios. Signal is the code that accomplishes the actual need. Noise is everything else: code that serves a pattern for its own sake, formats data nobody asked to see, or exists to satisfy a convention rather than a customer. Software SNR is the share of a codebase that is signal, written as a percentage with all the code as the denominator. A healthy target is 90 to 95 percent.
A waveform application landed on my desk two years into its life. It had more than two hundred source files, a macro layer that made the call graph untraceable, and a defect nobody could root-cause. It had been written mostly by one remote engineer, cleverly, and it had only ever been tested on laptops. The team had been adding to it for months, and every addition made it harder to see where the samples actually went.
I spent the first week reading and measuring instead of fixing, then wrote test code that exercised the real hardware. The replacement that came out of that analysis was three files: simple functions, top-down flow, the data path visible on one screen. It took three weeks. Two junior engineers who had told me they could not figure out how to contribute to the old code were contributing to the new one by the second week.
The lesson. The two hundred files were never the point; the point was that the signal had become impossible to find. Three files did the job because the job was three files big.
200+source files, two years in
became
3files, three weeks later
2junior engineers who could finally contribute
The fastest way to feel the ratio is to write the same need twice. The job, both times, is one sentence: is the recent average temperature over the limit?
Strong signal: nearly every line does the job
over_limit.cpp, C++SNR 94%
+// Need: is the recent average temperature over the limit?+boolrecent_avg_over(conststd::vector<float>& samples,+float limit_c) {+float sum = 0.0f;+for (float s : samples) sum += s;+return sum / samples.size() > limit_c;}
Read it once and you know what it does. The need, the inputs, the math, the answer. Nothing here exists to satisfy a pattern.
Strong signalSNR 94%
signal, does the job
Weak signal: the same job, hunting for the one line that matters
temperature_strategy.cpp, C++SNR about 14%
.// Same need, wrapped in ceremony the customer never asked for..structReadingContext { std::vector<float> samples; };.structStrategyConfig { float limit_c; floatLimit() const; };.classITemperatureEvaluationStrategy {.public:.virtual ~ITemperatureEvaluationStrategy() = default;.virtualboolEvaluate(constReadingContext&) const = 0;.};.classAverageThresholdStrategy : publicITemperatureEvaluationStrategy {.boolEvaluate(constReadingContext& ctx) constoverride {+float sum = 0.0f;+for (float s : ctx.samples) sum += s;+return sum / ctx.samples.size() > cfg_.Limit();. }.private: StrategyConfig cfg_;.};.classStrategyFactory { // + a registry, a builder, 30 lines of wiring.staticstd::unique_ptr<ITemperatureEvaluationStrategy> Create(constStrategyConfig&);.};
Three lines do the job. The rest is a pattern wearing the costume of engineering. Both files ship the same answer; only one of them is kind to the next reader.
Weak signalSNR about 14%
signal
noise, scaffolding the need never asked for
Same need, same answer. The difference is how much a reader has to wade through to find the three lines that matter. The number is a conversation starter, not a grade.
The real gift of the term is that it converts a matter of taste into a matter of measurement. Instead of “I would have written this differently,” a reviewer can ask, “what is the SNR of this change?” Now the discussion is about counting, together: which lines are load-bearing and which are along for the ride. That is a conversation everyone at the table can win.
The most common noise I meet is the abstraction layer that exists only to convert one data format into another, feeding a second layer that converts it back. Each file is a link in a chain, and the chain does nothing a function call could not. When you find yourself tracing a value through six files to learn that it is unchanged, you have found the noise.
Nobody has ever been paged at two in the morning because a function was too easy to read.
Signal is the code that does the job. Aim for ninety-plus, and whoever inherits the file inherits something worth keeping.
The most valuable question in a design review costs nothing to ask: what is missing today, and what has to be true to bridge the gap? Generating that question is critical thinking, and it falls straight out of the willingness to look at the whole problem rather than the corner of it in front of you. A CPU and an FPGA on one board, a customer who wants runtime control; therefore something has to carry runtime commands from one to the other. Where is it? You can ask that without knowing the words for the answer.
Knowing how to bridge the gap, the register block, the protocol, the bring-up sequence, is where deep experience earns its keep. These are two distinct muscles, and the encouraging part is that the first one is free. Anyone willing to own the problem out to its real edge can generate the question on day one, with no breadth of prior solutions required.
The what
Asking the question
Pure critical thinking. Reason from the need, look at the whole system, and notice what has to exist for it to work. Costs only the willingness to lift your eyes to the edge of the problem.
The how
Answering it well
Where breadth shines. The named techniques, the heritage, the right interface. Experience makes the answer precise and turns a good question into a shipped bridge.
A word used a lot here: shape
Shape is the structure of a thing, its parts and how they relate, before any specific values are filled in. The shape of a problem is what kind of problem it is and what has to be true to solve it. The shape of a system is its pieces and the boundaries between them. Naming the shape is the breadth view: you can draw it on a whiteboard, and a room can agree on it, long before anyone picks a number, an address, or an algorithm.
Here is what the breadth view looks like on paper. Picture a board with an operator console, a flight computer, and a sensor FPGA. Before anyone opens a datasheet, you can already name what has to cross each boundary and which way it flows. That is the what: the system seen whole.
Four named interfaces, drawn before a single address or bit field is chosen. This is breadth: the whole system, the boundaries, the direction of flow.
Write that down as an Interface Design Description, an IDD, and at this altitude it stays deliberately about the what. A row says a message goes from A to B and why. It does not yet say at what address, in what byte order, or how fast. Keeping values out on purpose is the discipline: it lets the whole team agree on the shape of the system in an afternoon, long before anyone commits to the hard parts.
No addresses, no bit fields, no data rates, no electrical levels. That is all the how, and it is real work that has to happen, later, and completely. Principle 1.7 picks up exactly this interface and shows what it takes to hand it off well.
This is the expectation at the principal level and above: know how to ask. The separation is also a kindness to a newer engineer, because it means he or she can be useful without having seen every solution. Reasoning from the need is available to everyone from the first day; the breadth to phrase the answer arrives with the years.
Low signal
My part is the datapath
Draw the boundary at the edge of your own block. The math is proven, the box is closed, and the question of how the rest of the system talks to it never gets asked.
vs
High signal
My part is the system edge
Lift your eyes to the whole board and ask what has to cross each boundary. The missing interface shows up early, while it is still cheap to add.
Asking the right question is critical thinking and costs nothing. Answering it well is where breadth earns its keep.
People often arrive with a solution wearing the clothes of a requirement. “We need Kubernetes” is a proposed answer; the need underneath is usually closer to “we want deployment and scaling to take care of themselves.” “We need a caching layer” often means “reads have to stay fast as traffic grows.” Translating the ask gently back to the need is one of the highest-leverage things an engineer can do, because the moment the real need is on the table, simpler paths to it tend to appear on their own.
When a very specific technical question shows up, “how do I read byte 47 of this packet?”, zoom out and ask what the goal is. Often the goal (“get the timestamp”) has a cleaner route than the one the asker had already committed to. Asking the wider question is a favor, not a correction.
A contract I worked under named, in the contract itself, the internal tool the team was to use to accelerate development. The tool was good. The sentence was still a solution written where a need belonged, because the need was “deliver on this date” and only a handful of people in the whole company knew how to run the tool. The sentence had been a selling point in the proposal. On the program it became a constraint nobody could trade against.
The lesson. A solution written into a requirement removes the freedom to meet the requirement some other way, and the freedom is the thing you will want most on the day the schedule gets tight.
Low signal
Build the solution as stated
“We need Kubernetes” becomes the requirement, and the team builds Kubernetes. The need underneath is never examined, so a simpler path is never found.
vs
High signal
Name the need behind it
Translate it to “deployment and scaling take care of themselves,” and the real options open up, often simpler than the one first named.
A requirement names the need. A solution is one way to meet it. Keep the two apart, and simpler answers keep showing up.
A project moves fastest when everyone begins from the same picture. The artifact that creates that picture is the product requirements document, the PRD. Think of it as the baseline: a shared, written statement of what the team is building and why, parked somewhere the whole team and the customer can see it. It is principle 1.1 and principle 1.4, what are you trying to do and name the need, written down once, for everyone at the same time.
PRD: what the baseline captures
Goals
What success looks like, in plain language a customer would recognize.
Business objectives
Why this is worth doing, and why now.
Strategic fit
How it serves the larger plan and the products around it.
User stories
Who needs what, and to what end: the work seen from the person using it.
UX and interactions
How a person meets the system: the touch points and the flow between them.
Open questions
What is still unknown, named honestly so it can be answered out loud.
Scope
What is in, and, just as usefully, what is out for now.
Here is the freeing part: a PRD is a starting point rather than a finished design, and it does not have to answer every question. Its job is smaller and far more powerful than that. It gets people thinking and communicating quickly, from a common starting point, and it turns a hallway full of quiet, differing assumptions into one page everyone has read. Open questions are a feature of a good baseline: they show the team exactly where to point its attention next.
Before any of that structure, the very first thing to write is the project summary, and it is the most useful page in the whole PRD. It is short, a page or two, told in plain English through the eyes of the customer and the engineers who will live with the result. It describes rather than specifies. It answers the plain questions a customer actually has: what do I get for my money, how do I use it, how is it installed, and how do the results reach me. It states, in one clear direction, how the team intends to build it. Then it asks the only question that matters this early: you good with it?
It is deliberately incomplete. It wanders into the physics where the physics matters, and into the internals when the customer cares about them or when a task smells hard enough to deserve a closer look. It carries a diagram or two, cheap ones, sketched, never the kind that costs a week of simulation time. The one exception is worth stating plainly: if a gut feel says the project may push against a physical limit and you do not yet know how to handle it, that is exactly the moment to stop and resolve the fundamentals first, a quick pass through the power, mass, link, and timing budgets, before promising anything you cannot deliver.
Then it goes around the room, to the customer and the few engineers who need to know, and back and forth until everyone is happy. As the team grows, it is the document a new engineer reads first. Because it is plain and short and written from the reader’s point of view, it does something a spec never does: it surfaces requirements and easy-to-miss details on its own, and it cures the blank-page paralysis that stalls so many starts. When a request for information lands on the desk, a little cleanup turns this same summary into the response.
Here is what one looks like, early and unpolished, for a device a customer wants built to catch illegal deforestation in time to do something about it. This is the project the rest of the guide keeps returning to.
Project summary: catching the cut in time
Draft v0.1, customer and leads
What you get is early warning. When illegal logging starts inside the preserve, you learn about it within minutes, roughly where it is happening and how sure we are, while there is still time to send someone. The deliverable is two parts: a set of low-cost sensor nodes spread across the area, and a small base station at your post that turns what they hear into an alert you can act on. The value is in blanketing the area for less than the cost of an hour of helicopter patrol, more than in any single node.
How you would use it
Day to day, you do nothing; the system watches. When a node is confident it is hearing a chainsaw or a logging truck, the alert reaches you the way you prefer: a text to the on-call phone, an email to the team, and a flag dropped on a simple map on the base-station computer showing which part of the preserve lit up. That is all you need to act on it.
How it is deployed
Each node is a small, rugged unit fixed to a tree, switched on and logged at its location once. It runs for a season on a battery and is cheap enough to leave or collect at the end: no wiring, no tower of its own, no field maintenance. You scatter enough of them to cover the ways a crew would get in. Each node decides on its own whether a sound is real before it says anything, which is what keeps you from chasing phantom chainsaws; one node gives a rough area, and several hearing the same event narrow it to a spot worth driving to.
Getting the alert out of the forest
The harder question is how a node deep in the trees reaches your base station with no cell coverage. The obvious first answer is a single long-range radio from each node straight to the post, so I ran the link budget for it, and over these distances, under wet canopy, it does not quite close. It is close, though, and that points the way. The direction I would build to is a mesh: nodes pass the tiny alert from one to the next until it reaches a gateway placed high, on an existing tower or a clear ridge, and the gateway forwards it to your station. If a far corner stays out of reach, one repeater covers it. A lower radio band that punches through foliage better is the alternative I am holding in reserve, but mesh-to-a-high-gateway is the plan.
A cheap sketch rather than a deliverable: the alert hops node to node to a high gateway, then to the base station and out to you.
The part I will not promise yet
One thing is uncertain: whether a node can listen all season and keep enough power to relay, on a battery cheap enough to call disposable. That is a real energy question, and right now I do not know the answer; the honest thing is to say so. Rather than quote a date I would have to walk back, I would propose a three-month, cost-plus research phase: build a handful of real nodes, measure power draw and canopy range in the field, and try the levers: how often we listen, that lower band, a small solar top-up. At the end you get a clear yes-or-no and a firm direction, having spent research money instead of a full build on a guess. This is a hard problem; that is why it landed on your desk, and then on mine. If it were easy, it would need no engineering.
Here is the direction. You good with it? The questions it raises, how far the radio reaches under canopy, how long a node lasts against how often it listens, how tightly we can place an event, how low we can drive false alarms, are the first requirements, already found, before a dollar goes toward building the wrong thing.
The link budget got run on the spot and pointed straight at the mesh design, and the one question physics could not answer cheaply became a funded research phase instead of a guess. That is what the power and link budgets are for: turning a nervous gut feel into a number, or into an honest “not yet, let us go find out.”
Low signal
We all basically know the plan
Skip the written baseline and start building. Each person carries a slightly different private picture, and the differences only surface once the pieces collide.
vs
High signal
We all read the same page
Write the one-page baseline first. The picture is shared, the open questions are visible, and the collisions happen on paper, where they cost nothing.
A PRD is the starting line. Its gift is that everyone steps off from the same place.
With the baseline set, there is a natural pull to build the whole thing before showing anyone. The stronger move is to lay the work out as a plan you can point to, and then deliver it in slices. The feature matrix is that plan on one page: each feature, how much it matters, which release it belongs to, and the need it traces back to. It keeps the build honest against the PRD, the customer’s expectations, and the game plan all at once.
Feature
Priority
Release
Traces to
Status
Live telemetry view
Must
v0
Goal: operator sees the system is alive
Done
Set sample rate
Must
v0
User story: tune the capture
In progress
Arm / safe control
Must
v1
Safety requirement
Planned
Health heartbeat
Should
v1
Reliability objective
Planned
Recorded export
Could
v2
Stretch goal
Planned
Then sequence it. Pick a first slice that puts something a person can see and touch in front of the customer, even while most of the matrix is still ahead of you. A working sliver lights a customer up in a way no status report can match. Seeing beats hearing.
v0: first thing the customer sees
Watch it live
Telemetry on the screen, sample rate adjustable. Rough edges everywhere, and the customer is already leaning in.
v1: operate it
Drive it safely
Arm and safe controls, a health heartbeat. Now it is a system someone can run with confidence.
v2: live with it
Keep the record
Recorded sessions, longer runs, the stretch goals. The parts that matter once the core is trusted.
Showing something early is generous, and it quietly de-risks the whole program. It surfaces a misunderstanding while it is still cheap to fix, and it builds a kind of trust that compounds with every slice. The customer stops buying a promise and starts watching progress.
That first slice has a name worth using carefully: the prototype. A prototype is the build that meets the functional requirements and little else. It may run on an evaluation board instead of the real hardware, the enclosure may be cardboard, the screen may be ugly, but it does the thing well enough for the customer to see it work and react to it. The goal is to get one into the customer’s hands fast: somewhere between the first week and the first month, depending on how hard the project is. A prototype someone can poke at in week three beats a flawless plan read in month three.
Keep the prototype distinct from the MVP. The minimum viable product is the smallest version that delivers real value to a real user in the field. The prototype comes earlier and aims lower: it only has to prove the function and earn the conversation. One is for learning whether the idea works at all; the other is for shipping the first useful version. Build the prototype to learn fast, then grow it toward the MVP once the shape is confirmed. Start here has the four flavors of work laid out side by side, and the expensive mistake of confusing them.
Low signal
Reappear when it is done
Go quiet for three months and return with a finished build. The customer’s first look is also the first chance to learn it is slightly wrong.
vs
High signal
Show a slice early
Put a rough, working v0 in front of the customer fast. Course corrections arrive while they are still small, and trust grows with every slice.
Plan the whole; build a slice; show it early. A thing the customer can see outweighs a promise of the thing.
Now return to that interface from principle 1.3. Building the FPGA logic is one half of the work. Telling the next engineer how to work with it is the other half, and it carries equal weight. The software on the CPU has to know the registers, the power-on sequence, and the timing, or the bridge that looked finished is only half built. This is where the IDD grows up: the what from principle 1.3 gains its how.
Offset
Register
Access
Reset
Purpose
0x00
CTRL
R/W
0x00
enable, reset, mode select
0x04
STATUS
R
0x01
ready, armed, error flags
0x08
SAMPLE_RATE
R/W
0x0A
samples per second
0x0C
DATA
R
0x00
latest telemetry sample
0x10
HEALTH
R
0x00
heartbeat counter, fault code
And the part a register map alone never tells you: the order to do things in. A power-on sequence turns a table of addresses into a part that actually comes up.
Apply power and wait for STATUS.ready to read 1.
Write SAMPLE_RATE with the configured value.
Set CTRL.enable to begin sampling.
Read DATA on each new sample, by polling or by interrupt.
Read HEALTH on the heartbeat interval and act on any fault code.
None of this is busywork, because every line of it traces back to something a person asked for. That tracing is what keeps depth honest: the how stays tethered to the what, the UX, and the requirements.
SAMPLE_RATEtraces toOperator’s “set sample rate” (IF-01) and the user story “tune the capture.”
STATUS.readytraces toThe UX “operator sees the system is alive” and the health heartbeat (IF-04).
DATAtraces toTelemetry (IF-03) and the goal “watch it live.”
CTRL.enabletraces toThe arm / safe control (IF-01) and the safety requirement.
Then prove the boundary holds, on its own, before another team builds on top of it. Test it two ways:
Functional
Does it behave per the contract?
Each register reads and writes as the IDD says. The power-on sequence brings the part up every time. Tested at the boundary, against the written interface, in isolation.
Non-functional
Does it hold up under real conditions?
Timing and throughput meet the need. A bad write is rejected gracefully; a dropped sample is handled. The boundary stays trustworthy when the day gets messy.
I once inherited an interface where a request could be rejected for a dozen different reasons, and the rejection came back as a single integer. The mapping from defect to reason was many-to-one and nowhere written down: an invalid channel, as far as anyone could tell, fell under “general critical failure.” Every test case for that interface started with a half-hour of archaeology to learn what number to expect, and every new engineer repeated the archaeology.
The lesson. The interface worked. It had simply never been handed off. An unfinished handoff is a tax paid by every person who touches the boundary after you, forever, and it is always larger than the afternoon it would have taken to finish.
A tested, documented interface is a gift to the team. It lets whoever integrates next move fast and trust the boundary completely. The alternative is quieter and costlier: an untested, undocumented interface hands your unfinished work to the next engineer as an unspoken transfer of ownership. He or she inherits the parts you left undone without ever agreeing to.
Low signal
It works on my bench
Hand over the logic and let the registers speak for themselves. The next team inherits an undocumented, untested boundary as an unspoken transfer of ownership.
vs
High signal
Hand over a boundary others can trust
Ship the register map, the power-on sequence, and the isolation tests alongside it. The integrating team moves fast, and ownership stays where it belongs.
Build the thing, then finish the handoff: the registers, the sequence, the tests. A boundary others can trust is the most generous thing you can leave behind.
“At scale” is usually a phantom: a future that may arrive on a schedule nobody can name, quietly spending today’s budget on a load that has yet to show up. The grounded move is to build well for the real, present need, and to add flexibility the moment it is wanted. That timing keeps the SNR high and the design honest, and it leaves room to grow in the direction the work actually grows.
I have watched a fifty-thousand-dollar program turn into a fifty-million-dollar program on the strength of one sentence: “we should build it to handle whatever comes next.” Nobody could say what would come next. The hardware got horsepower for a load that never arrived, the software got layers for features never requested, and the schedule got the years that both of those cost. The need that started the whole thing could have been met for the original fifty thousand, and then met again, for another fifty thousand, when the second need actually showed up with a shape and a name.
The lesson. Two small builds, each for a real need, beat one enormous build for an imagined one, and they still beat it after you add the upgrade the enormous build will need anyway.
$50kwhat the need in front of them cost
became
$50Mwhat “whatever comes next” cost
2 x $50kwhat two real needs, met in turn, would have cost
Extensibility is a fine thing to add when someone truly asks for it. Adding it on spec, before the need is real, is how a clean idea picks up the weight it was supposed to avoid. Trust that the need, when it arrives, will tell you its shape more clearly than a guess ever could. The same discipline applies in the small: on one project, newcomers objected to copying a buffer because copying is slow, and they had been burned by it before. The requirements for that tool made the copy harmless, and the version built to avoid it was much harder to read for a benefit nobody could measure.
Low signal
Build it for “at scale”
Engineer for a future load nobody has named yet. The generality nobody asked for arrives right on schedule; the signal it was meant to serve does not.
vs
High signal
Build it for the real need
Solve the present need cleanly, and add flexibility the moment it is wanted. The design stays honest and ready to grow where the work actually grows.
Build for the need you have. Add for the need you are given. The hypothetical can wait its turn.
A surprising amount of engineering speed comes from removing the coordination tax rather than adding people to the problem. A focused engineer who owns a piece end to end can often write the right thing from scratch faster than a group can extend something that merely almost fits. The honest measure is days-to-weeks of clear, owned work against months of negotiation around a near-match.
Two routes from a need to done. The straight line is the small exact thing, written in days. The dashed one is the near-fit library: adopt it, wrap and patch the part that fights you, negotiate the upstream change, and work around whatever is left.
Reuse is excellent when the fit is real; lean on it hard in that case. The judgment call is the near-fit: when a library covers eighty percent and fights you on the rest, the straight line is frequently to build the small, exact thing. Look for the straight line, and take it when you can see it clearly.
Low signal
Bend the project to the near-fit
Adopt the library that covers eighty percent, then spend months wrapping, patching, and negotiating the stubborn other twenty.
vs
High signal
Take the straight line
When a thing only nearly fits, write the small exact piece in days, and lean hard on reuse wherever the fit is real.
Eighty percent of a fit tends to take a hundred percent of the schedule.
When a thing nearly fits, the right small build is often the shorter road. Reuse what truly fits; write what does not.
Here is a question that reliably shakes a simpler design loose: what if I did not have X? Could I still build this another way? Pick the part you reach for by reflex and take it away, on paper. The classic one to remove is the FPGA. Ask what the design becomes with no FPGA at all, and a surprising number of times a cleaner path appears, often something a little old-school with a modern twist: a fast core and clever timing, a purpose-built analog front end, a cheaper part doing one job well. Fewer moving pieces, lower cost, less to carry.
A sample stream needed to reach a DAC on a hard clock, and the reflex answer was a large FPGA to buffer and pace it: a part in the ten-thousand-dollar class once you count the layout effort, the board real estate, and the tool licenses. The question I asked was smaller than “ARM or FPGA?” It was “what, exactly, has to live in fabric?” The answer was the timing, and only the timing. A fast processor core, isolated and characterized for jitter, could generate the samples; an external FIFO part costing about as much as lunch could hold the clock. The potential had been hiding in a place nobody was looking, because everyone was looking at the fabric.
The lesson. The limit was timing, so shim the timing and keep the rest in software. The part number follows from what truly has to be in hardware, never the other way around.
It does not always win, and that is the honest part. Sometimes the FPGA really is the right answer, the throughput, the parallelism, the hard determinism need it, and now you know exactly why, which is its own kind of win. The point of the question is to make sure the default earned its place instead of showing up out of habit. Run it against whatever your favorite tool happens to be, and keep whichever design is simpler for the same result.
Low signal
Reach for the usual stack
Start from the tools you always use; the FPGA goes in because the FPGA always goes in. The design quietly inherits cost and complexity no one questioned.
vs
High signal
Remove it and look again
Ask what the design becomes with the part gone. Often a simpler, cheaper path appears; and when the part truly earns its place, you can finally say exactly why.
A good part can still be a habit, and a habit is cheaper to question than to buy.
Take away your favorite tool and see if the design still stands. The simpler version that survives is usually the one to build.
They share one spine. Start from the need. Keep the signal high. Ask the free question and own the problem out to its real edge. Tell a need apart from a solution. Get everyone onto the same baseline with a plain-English project summary, plan the build and get a real prototype into the customer’s hands early, and finish the handoff so the boundaries others lean on can be trusted. Build for what is actually in front of you, take a favorite tool away to find the simpler design, and let the straightest honest path win.
It is about spending every hour on the part that matters, so the work ships, the customer receives exactly what was asked for, and the next engineer inherits something clear enough to build on. That is the whole game, and it is a game everyone at the table can win together.
Carry these into the rest of the guide. Requirements is principle 1.4 made rigorous. Design and trade studies is where the what-from-how split does its best work. Integration and Verification are where finishing the handoff gets tested in earnest. Lifecycle is where the baseline and incremental delivery keep a program honest from concept to retirement. And Leading the work turns the lens on the people and the clock. The chapters are the craft; these are the compass.
Write the one sentence: “This exists so that…” for the thing you are building right now. Show it to one person who will use the result and ask whether it is true.
Open the file you touched most recently and count: how many lines do the job, and how many serve a pattern? Say the percentage out loud in your next review.
Take the part of your design you reached for by reflex, remove it on paper, and spend twenty minutes finding out whether the design still stands.
Start from the need, keep the signal high, share the baseline, show a slice, finish the handoff, and let the simplest honest design win.
This chapter on one page
Each line is the sentence to remember from its section. The number takes you back to it.
→The principles are the discipline of one focused engineer, written down so a whole team can use it.
1.1Name the need first. Everything good downstream, the requirements, the design, the tests, follows from a need stated plainly.
1.2Signal is the code that does the job. Aim for ninety-plus, and whoever inherits the file inherits something worth keeping.
1.3Asking the right question is critical thinking and costs nothing. Answering it well is where breadth earns its keep.
1.4A requirement names the need. A solution is one way to meet it. Keep the two apart, and simpler answers keep showing up.
1.5A PRD is the starting line. Its gift is that everyone steps off from the same place.
1.6Plan the whole; build a slice; show it early. A thing the customer can see outweighs a promise of the thing.
1.7Build the thing, then finish the handoff: the registers, the sequence, the tests. A boundary others can trust is the most generous thing you can leave behind.
1.8Build for the need you have. Add for the need you are given. The hypothetical can wait its turn.
1.9When a thing nearly fits, the right small build is often the shorter road. Reuse what truly fits; write what does not.
1.10Take away your favorite tool and see if the design still stands. The simpler version that survives is usually the one to build.
1.11Start from the need, keep the signal high, share the baseline, show a slice, finish the handoff, and let the simplest honest design win.