Engineering Fundamentals: Structuring What Software Engineers Actually Need to Know
Building a tiered knowledge base - from computational foundations to applied patterns
After building Thinking Tools - a taxonomy of 520+ reasoning primitives across 34 domains - I turned the same process inward. The question: can you structure the core of software engineering the same way?
The result is Engineering Fundamentals - 270+ concepts across 19 domains, organized in a 4-tier hierarchy that reflects how engineering knowledge actually builds on itself.
The Problem with Engineering Knowledge
Software engineering knowledge is scattered. Algorithms live in one textbook, distributed systems in another, API design in blog posts, security patterns in OWASP guides. There is no single structured reference that connects these domains and shows how they build on each other.
What is missing:
- A clear hierarchy showing what depends on what
- Connections between concepts across domains (how CAP theorem relates to consistency patterns)
- A single searchable reference that covers fundamentals without tutorial bloat
- Learning paths tailored to different roles and trade-off decisions
Most engineers learn this through years of experience. I wanted to map the territory explicitly.
The 4-Tier Hierarchy
The key insight was that engineering concepts have a natural dependency order. You cannot reason about distributed consensus without understanding concurrency. You cannot design APIs well without understanding data modeling. The 4 tiers reflect this:
The bedrock. Algorithms, data structures, type systems, memory models, programming paradigms. These concepts are stable across decades and technologies.
What happens when your code meets the real world. Concurrency, networking, distributed systems, data persistence. The constraints that shape every architectural decision.
Design decisions that require weighing trade-offs. API design, security patterns, software architecture, testing strategies. This is where experience matters most.
Putting it all together. Observability and performance optimization - disciplines that draw on everything below them and require holistic system understanding.
Learning Paths
A flat list of 270 concepts is not useful without navigation. I built three different ways to move through the material:
By Role
What does a backend engineer need versus a frontend engineer versus a platform engineer? Role-based paths prioritize the domains most relevant to your work.
By Tension
Engineering is trade-offs. Consistency vs availability. Latency vs throughput. Tension-based paths organize concepts around the decisions you actually face.
Transfer Matrix
How do concepts in one domain connect to another? The transfer matrix maps relationships across all 19 domains.
Technical Implementation
Same pipeline as Thinking Tools, refined for engineering content:
Structure 270+ concepts into single-page documents with consistent format
Build with MkDocs Material - 4-tier navigation, search index, cross-references
Generate learning paths and glossary with cross-domain linking
Deploy to Cloudflare Pages at engineering.denis-darkin.xyz
The result: a searchable, navigable reference that maps the territory of software engineering fundamentals.
What You Can Do Now
Browse by tier
Start at foundations and work up, or jump to the tier relevant to your current problem
Search across everything
Full-text search through 270+ concepts
Follow learning paths
Navigate by role, by engineering tension, or explore the domain transfer matrix
Use the glossary
Cross-referenced engineering terminology across all 19 domains
Share specific concepts
Each concept has its own URL - bookmark and share individual pages
Read on any device
Responsive design with dark mode, optimized for reading
Combined with Thinking Tools, this gives a structured view across both how to think about problems and how to build solutions - 53 domains and 790+ concepts total.