Layer 1 — Mathematics. Not because software engineers need to be mathematicians. Because mathematical structures are the most precise way to express patterns that appear in computing. Understanding that a hash function is a surjection from a large domain to a small codomain reveals not just what hashing does but why collisions are unavoidable and why the distribution of the hash function matters.
Layer 2 — Algorithm Engineering. The translation layer between theory and production. Most developers have learned algorithms in isolation — sorting algorithms, graph algorithms, dynamic programming — without seeing where they run in real systems. This layer makes the connections explicit.
Layer 3 — Infrastructure Patterns. The building blocks that every production system uses. Caches, queues, databases, load balancers, consensus protocols. These are not individual technologies but patterns that technologies implement. Redis, Kafka, PostgreSQL, Nginx — all of them are implementations of patterns that have existed for decades.
Layer 4 — System Design. Where all the infrastructure patterns combine into complete systems. A payment processor, a news feed, a video streaming platform — each is a specific arrangement of infrastructure patterns, selected to meet specific requirements.
Layer 5 — Code Architecture. The layer between algorithms and infrastructure that governs how code is structured. Coupling, cohesion, hexagonal architecture, testing strategy. The concerns at this layer are different from infrastructure — they are about how code is organised, not how systems are deployed.
Layer 6 — Leadership. The layer where technical decisions intersect with organisational ones. Conway’s Law operates here. Technical debt becomes a business risk here. Architecture reviews, technology roadmaps, and hiring decisions all live at this layer.
Layer 7 — Product Strategy. The layer where systems create user value. Network effects, growth loops, platform design, AI product architecture. The concerns here are product and business, but they are grounded in technical reality — you cannot design a platform without understanding what the technical constraints on extensibility actually are.