great-engineers — the most conspicuous absence

Every person who has seen the shipped Constellation asks the same question immediately: where is great-engineers? It is the most conspicuous absence, and the reason it is absent is not neglect. It is complexity.

Why engineering is hard to package

Engineering is not one craft. It is a family of crafts that share a common orientation toward correctness — and almost nothing else.

Systems design (Carmack) has a different register than algorithm correctness (Dijkstra). Frontend architecture (Dan Abramov, in the sense of the problems he has worked on publicly) has a different register than object design (Sandi Metz). Kernel-level clarity (Linus Torvalds, in his code review mode) has a different register than distributed systems thinking (Leslie Lamport).

A single "great-engineers" plugin that tried to hold all of these would violate the one-craft rule immediately. The persona would be incoherent. The output would be generic engineering prose — correct in a general sense, optimized for no particular problem.

The approach that will work

great-engineers ships as a constellation within the Constellation: multiple sub-plugins, each with a narrow craft definition. (At the time this lesson was originally written, the plugin had not yet shipped; it has since.)

Carmack: systems programming at the performance boundary. The register is physics-adjacent — cache lines, branch prediction, the cost of abstraction. What would this implementation cost to run on 1990s hardware?

Dijkstra: correctness at the boundary conditions. The register is mathematical — preconditions, postconditions, invariants, proof obligations. The question is always: what breaks this, and can you prove it cannot break.

Sandi Metz: object design for changeability. The register is humanist — code is read more than it is run, and the reader deserves consideration. Dependencies, cohesion, the cost of coupling.

Linus: code review for kernel-level clarity. The register is adversarial — if it is not obviously right, it is wrong. Simple over clever. The comment that explains why, not what.

What it unlocks

Code review by persona. Architecture decisions filtered through multiple engineering voices in sequence. The ability to ask "what would Dijkstra say about this invariant?" and receive an answer in Dijkstra's register, not in generic code-review prose.

The pipeline would run: Sandi Metz for the initial design review (is this cohesive, are the dependencies right), Dijkstra for the correctness pass (what breaks this), Carmack for the performance pass (what does this cost), and Linus for the final review (is it obviously right, or is it clever in a way that will cost someone later).

If you get stuck

If you are designing a great-engineers-style plugin for your own stack and you are not sure where to draw the sub-plugin boundaries, use the failure-mode test from Lesson 5. If two engineering sub-crafts fail in different ways that require different diagnostics, they need different personas.

If the personas you want to use are not historical figures but living engineers, you can still write the persona file — just use their public writing, their code reviews (GitHub for open-source contributors), and their documented decisions as the primary sources.

Cross-reference

Lesson 5 (One plugin equals one craft) is the principle that explains why great-engineers ships as multiple sub-plugins rather than one.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-engineers. Nine engineering personas (Carmack, Hopper, Knuth, Torvalds, DHH, Hejlsberg, Eich, Dijkstra, Sandi Metz) — installable now, despite this lesson's framing as "not yet shipped."

Deliverable

Pick one engineering problem you are currently working on. Identify which sub-craft it primarily requires. Write a two-sentence brief for that persona: what problem they are receiving, what they are being asked to produce.