Code being written instantaneously by AI makes expertise in the craft of software engineering more valuable, not less. What a good software engineer looks like will have many subjective answers depending on who you ask. Some might want a driven finisher, some might want a meticulous bug fixer. But those aren't skills of a software engineer so much as personality traits; important ones to balance across a team.

Training to become an entry-level software engineer, and the journey progressing to senior, takes a decade or more. In the past, engineers could choose the pace of their progress to some degree because of how in demand the profession was. Today though there is urgency and competition. "What do I need to learn to be a great software engineer!?" ask the burgeoning cohort who find themselves joining a workforce in chaos owing to scarce capital, and paradigm shifting generative AI tools.

The fundamentals of making software will always still apply. Be brilliant at the fundamentals, and you will always be in demand. The Three Layers of Software Engineering are here to guide you on where to focus your attention next, and why.

The Three Layers

Programming — you and the machine. The discipline is problem solving. The question is whether you can make a computer do what you intend. Competency shows up across data and types, flow and abstraction, algorithms, and paradigms. When this layer is weak, things work by accident rather than by understanding — and the engineer can't tell the difference.

Development — you and your collaborators. The discipline is collaboration. The question is whether the code you write today makes the codebase thrive in the months and years to come, be maintained by people who weren't in the room, and be shaped by decisions someone else can reconstruct. Competency clusters into craft, communication, and judgement. When this layer is weak, the code is unmaintainable and the choices untraceable — regardless of how clever the individual pieces are.

Operations — you and the world. The discipline is respecting physical reality. The question is whether your software survives, with finite networks, finite memory, finite time, real users, and real adversaries. Competency clusters into limits, delivery, resilience, and substrate. When this layer is weak, the system collapses under real load, real attackers, real failure.

Scope and The Three Layers

Each layer expands scope. Programming is you and one machine. Development adds other humans, present and future. Operations adds the physical world the software has to run in. You can't collaborate on software you can't write, and you can't reason about physical limits until you've built something complex enough, with other people, to hit them.

The key lesson of the three layers is that each is the foundational starting point for the next. The pyramid isn't a ranking of importance. It's a ranking of order — each layer is what the next one is built upon.

Learning and The Three Layers

In progressing as a Software Engineer, you don't finish Programming and move on. You revisit every layer forever as the problems get harder. The layers direct where future learning efforts will pay the most impact. If you want to become an expert engineer begin at the lowest level where you are weak. The following are incomplete summaries of areas where your learning could begin.

Programming — "why does this number come out slightly wrong?"

Starting points cluster around four areas. Data and types: how integers and floating-point numbers are represented in memory, two's complement, and binary operations like left/right shift. Flow and abstraction: control flow from if/else through to pattern matching, how functions compose, how abstractions leak. Algorithms: the implementation and time/space complexity of common data structures, and the canonical algorithms on them, such as sorting, searching, rebalancing, shortest-path. Paradigms: the idiomatic problem-solving shape of imperative, declarative, object-oriented, and functional code, and the taste to know when each applies.

Development — "what will this codebase look like in eighteen months?"

Three clusters. Craft: Gang of Four design patterns, automated testing strategies at every level from unit to acceptance, and codebase architecture that ages well. The disciplined use of tools that share intent across the team: issue trackers, version control, wikis, and shared documents. Communication: written and verbal clarity, and specifically the techniques that enable productive disagreement (active listening, and non-violent communication). The difference between escalating and clarifying, and when to reach for synchronous ceremonies versus asynchronous messages. Judgement: working under uncertainty, evaluating trade-offs when no option is free, and being decisive using a mix of quantitative data, qualitative signal, and the values and targets of the individual, team, and company.

Operations — "what happens when this fails at 3am?"

Four clusters. Limits: the practical capacity of the servers running your code, the devices running your clients, and the networks between them, and the cascade of consequences each limit imposes on the layers above. Delivery: CI/CD pipelines that let you ship with confidence, and the breadth and depth of telemetry that makes the health of the service visible, especially the long tail. Resilience: security as a first-class concern, and the ability to evaluate the whole system against the quality attributes it needs to exhibit — correctness, reliability, durability, usability, timeliness, volatility — knowing which of these matter for this system at this stage, and balancing the cost of perfection against the need to do root-cause analysis when evidence says something has behaved unexpectedly. Substrate: designing distributed systems appropriately for their scale and maturity; when to reach for a queue versus a synchronous call, when a database versus object storage is correct, how designing for a data centre differs from cloud, and the complexity cost of service orchestration and service mesh.

Diagnosis and The Three Layers

In considering where the limitations of an engineer exist, use the three layers as a diagnosis tool. When something feels off about an engineer, a team, or a candidate and you can't name why, the model tells you where to look: walk down the layers and find the instability. The gifted architect whose code no one can read has a Development problem, not an Operations one. The reliable shipper whose designs fall over at scale has an Operations problem, not a Development one. The senior engineer who can't explain why their code works has a Programming problem, no matter how much else they've built on top.

Grow by resolving the lowest weak layer first. Everything above it is more load on ground that's already shifting.