Engineering North Star
A working engineer’s guide to the discipline behind systems that ship on time and survive contact with reality.
Written for the person who already builds things and wants to build them better. It is opinionated, it is specific, and it is what I would actually tell you if you walked up to my desk and asked.
Contents#
The shape of the problem, first-principles thinking, the four kinds of work a team can be building, and how to read this guide.
- 1
The operating habits underneath every chapter: ask what you are actually trying to do, keep your Software SNR high, separate the what from the how, and let the simplest honest path win.
- 2
Power, mass, link, timing. The four budgets that decide whether a system is physically possible, with worked examples and calculators you can type your own numbers into.
- 3
Requirements as contracts. Writing them so they are testable, decomposing them so they are tractable, tracing them so they survive the lifecycle.
- 4
How to choose between alternatives and defend the choice a year later: trade studies step by step, COTS versus custom, and the complexity nobody chose.
- 5
Designing for testability from day one, locking interfaces before internals, and bringing up the dumb path first so the last six weeks are calm.
- 6
Proving the system meets its requirements with evidence: test isolation by tier, writing a test procedure, traceability, reliability, environmental testing.
- 7
Taking control when you do not know the way through: bounding the situation, ranked hypotheses, test solutions that check boxes, and the four-line status.
- 8
Concept to retirement: phase gates and what they ask, code freezes, configuration management, hotfix discipline, and engineering as a business.
- 9
The lead’s lens: growing people into the right tasks, holding a shared vision without endless meetings, and estimating honestly.
- 10
Context diagrams, the C4 model, flowcharts, UML, and the discipline of choosing the right altitude for the question you actually have.
Red flags, the troubleshooting checklist, formulas, margin thresholds, decision frameworks, and the acronyms. Bookmark this one.
Four no-cost ways to give something back if the guide has helped you.
Why this exists#
Smart people, real budgets, plenty of tools, and projects still slip. The reason is rarely that someone got the math wrong. It is that the team skipped a fundamental, accepted an unexamined assumption, or spent three months building the wrong thing because nobody wrote down what “done” meant.
This guide is the playbook I wish I had been handed twenty years ago: the constraints you cannot engineer around, the discipline of writing requirements that hold up in court, the trade-study habits that make decisions defensible, and the integration patterns that turn the last six weeks of a project from a death march into a victory lap.
It is a survey of one engineer’s working practice rather than a survey of the literature. Where it is opinionated, it says so. Where the honest answer is “measure it,” it says that too. And where a principle was learned the hard way, the story is in the chapter, marked From the field, with the names of the programs and the people left out and the lesson left in.
The amateur focuses on tools. The professional focuses on principles. Tools change every few years. Principles are timeless.
Who this is for#
The new engineer. You have learned the tools. You can write code, read a schematic, run a test. You can sense that the people around you are doing something different than you, but you cannot name it yet. That “something” is the discipline of working under constraints. This guide is what your mentor would tell you over coffee, written down so you can revisit it. Start with Start here, then Fundamentals.#
The working engineer. You have seen projects succeed and fail, and you suspect the failures had patterns. You are right. This guide names the patterns: bad requirements, missing margins, integration as an afterthought, process that exists for compliance rather than effect. It gives you language to push back when you see them. Skip the introduction and open the chapter that matches your current pain.#
The accidental TPM. You were handed a program with technical depth, schedule pressure, and stakeholders who use words you do not recognize. You need a vocabulary and a framework, fast. The Reference is the cheat sheet, especially the red-flag list. Read the rest in any order.#
One example, carried through#
Most engineering guides illustrate each idea with a different, disposable example. This one carries a single project through the whole book, so you can watch the same decisions compound from the first conversation to the field.
The project is a forest sentinel: a scatter of cheap, battery-powered acoustic nodes fixed to trees inside a preserve, listening for chainsaws and logging trucks, relaying an alert through a mesh to a ranger post in time to send someone. It first appears in Principles as a plain-English project summary. In Fundamentals its power and link budgets get run for real. In Requirements the promises in the summary become testable statements. Design runs the radio trade study. Integration plans the bring-up. Verification writes the test procedure. Lifecycle puts the research phase through its first gate, and Leading estimates the build.
The numbers are illustrative and the project is composite. The method is the point, and the method is real.
Free, and why#
This guide is published by Wavelet Solutions as a public resource. There is no paywall, no signup, no email harvest, no “upgrade to read the rest.” Engineering knowledge is most valuable when the people who need it can find it without negotiating with a vendor first.
If it helps you, the best return on the favor is to apply it. Build something that works. Push back on the next bad requirement you see. Mentor the engineer behind you. That is the loop this guide is trying to feed, and Pay it forward says more about it.