2025-09-28 13 Min. Lesezeit EN

Do We Still Need Low-Level Knowledge in Software Engineering?

Dieser Artikel ist auf Englisch.

TL;DR

The software industry has split into two worlds: most developers orchestrate high-level abstractions, while a smaller group builds the infrastructure everyone else relies on. Low-level knowledge isn’t dying, it’s concentrating. This article explores when systems expertise matters, when it doesn’t, and why the answer shapes your career more than you might think.

Introduction

Here’s a question that sparks arguments at every tech conference: Do software engineers still need to understand low-level systems?

The gut reaction depends on who you ask. A React developer shipping features daily might say no. A kernel engineer debugging memory corruption at 3 a.m. would laugh at the question. An SRE watching production melt down because someone didn’t understand TCP would have… strong opinions.

The real answer is more interesting than either extreme. Yes, we still need low-level knowledge, but only for a shrinking slice of engineering work. The industry has fundamentally restructured itself. Cloud adoption jumped from 32% of enterprise workloads in 2018 to 52% in 2025 [1]. Most developers now compose infrastructure instead of building it. Yet the people who do build it command serious premiums. Stack Overflow’s 2024 survey shows about 20-25% of developers regularly use systems languages like C, C++, and Rust [2], and this group isn’t struggling to find work.

The market is bifurcating. On one side, high-level orchestration work where you glue together APIs and services. On the other, specialized systems roles that are simultaneously rarer and more valuable. Joel Spolsky nailed it back in 2002 with his „Law of Leaky Abstractions“ [3]: abstractions work great until they don’t. And when they break, someone needs to understand what’s underneath.

That someone might need to be you.

What Actually Counts as „Low-Level Knowledge“

Let’s get specific about what we mean by low-level knowledge, because it’s not just „knowing C.“

The deepest layer is systems programming. Memory management, OS internals, CPU architecture, assembly. Languages like C, C++, Rust. According to Stack Overflow’s 2024 survey of 65,000+ developers, C sits at 20.3% usage, C++ at 23%, and Rust has grown to 12.6% [4], up from roughly 7% in 2019.

The second tier is understanding how your tools actually work. Database internals. Distributed systems theory. Networking protocols. What happens when your abstractions fail. Werner Vogels, Amazon’s CTO, put it bluntly in ACM Queue: „There isn’t a technology in a computer science textbook that wasn’t pushed to the edge at Amazon.com. We made a change before building S3 to go back to fundamentals“ [5]. When you’re building infrastructure that millions depend on, you can’t afford to treat your database as a magic box.

The third tier covers algorithmic and data structure expertise. Computational complexity, optimization techniques, the math underlying performance. This knowledge crosses abstraction boundaries. Whether you’re writing kernel code or web applications, understanding why your algorithm is O(n²) instead of O(n log n) matters when you hit scale.

Notice these layers stack. You can understand algorithms without knowing assembly. You can grasp database query planning without writing C. But the deeper you go, the more options you have when things break.

When Abstractions Leak (And They Always Do)

Joel Spolsky coined „The Law of Leaky Abstractions“ in 2002, and it’s aged like fine wine: „All non-trivial abstractions, to some degree, are leaky“ [6].

His examples still hit home. TCP abstracts away unreliable networks, giving you a nice reliable stream, until packet loss causes mysterious latency spikes. SQL queries that look logically identical differ by orders of magnitude in performance. ORMs work beautifully for simple cases, then generate catastrophic query plans that bring your database to its knees [7].

Production systems surface these leaks constantly. Why does Photoshop take minutes to start on some machines? Network printer detection hanging the UI thread. Why does iterating a two-dimensional array run fast in one direction and slow in the other? Cache behavior and memory layout [8]. Why is this code generation tool producing output you can’t debug? Because you don’t understand the system it’s generating code for [9].

Michelle Brush, Google’s Engineering Director for SRE, reinforced this at QCon 2025: „All abstractions leak, especially our hardware abstractions“ [10]. Her key insight, drawing on automation research, is that when you automate work, the job left for humans gets harder, not easier. The routine cases disappear. What remains requires expertise to diagnose [11].

Think about what that means for your career. As tooling gets better and abstractions proliferate, the easy problems vanish. The only problems left are the weird ones, the edge cases, the situations where something five layers down isn’t behaving as advertised. If you don’t have the mental model to descend those layers, you’re stuck filing support tickets and hoping someone else can help.

Where Systems Knowledge Still Matters

Certain roles explicitly require deep systems expertise, and they’re not apologetic about it.

Trading firms like Jane Street specify requirements including „thorough understanding of modern computer architecture“ and experience with „kernel-bypass implementations“ like DPDK and InfiniBand. Their job postings ask candidates to describe modern x86 AMD and Intel cache hierarchies [12][13]. Two Sigma’s Trading Engineers build „low-latency, high-throughput trading systems“ [14]. When microseconds matter, you can’t afford to treat the CPU as a black box.

Infrastructure teams at major cloud providers need engineers who understand what they’re abstracting. Google’s engineering ladder explicitly weights „system design ability“ heavily at L5 and above [15]. Distinguished Engineers (L9) and Fellows (L10) like Jeff Dean „drive technical strategy spanning a large technical area“ [16][17]. You don’t get there by only knowing how to call APIs.

Game development consistently requires C++, memory management, and performance optimization [18]. When you’re rendering 60 frames per second with complex physics, garbage collection pauses aren’t acceptable. Embedded systems represent a $20.7 billion market growing at 9.6% CAGR through 2034 [19], with demand for engineers exceeding supply.

Security research requires understanding memory layout, buffer overflows, system vulnerabilities. You can’t find exploits if you don’t understand how memory actually works.

Bryan Cantrill, CTO of Oxide Computer and co-creator of DTrace, articulates why this matters: „For software that’s at that layer you really have to pick performance above everything else. Anything that you do in that layer is machine capacity that you are taking away from the software that you’re going to run“ [20].

These aren’t niche roles. They’re the foundation everything else runs on. And they pay accordingly.

When High-Level Knowledge Is Enough

Let’s be honest: most software engineering work operates effectively at higher abstraction levels.

Web developers building user interfaces and server-side logic rarely need memory management expertise. Modern JavaScript engines handle optimization. Mobile app developers working in Swift, Kotlin, or Dart benefit from platform-managed performance optimization [21]. Desktop application developers using Electron or similar frameworks have runtime environments handling system-level operations.

Business logic implementation forms the bulk of enterprise software. Encoding real-world rules for how data is created, stored, and changed [22]. In three-tier architectures, this layer sits between presentation and data access, largely insulated from systems concerns [23].

The Stack Overflow data confirms this distribution. JavaScript has been the most-used language every year since 2011 (except 2013-2014), with 62.3% usage in 2024 [24]. Python reached 51%, TypeScript 38.5% [25]. These languages dominate precisely because they let you be productive without deep systems knowledge for most tasks.

If you’re building a CRUD app, implementing business workflows, or creating dashboards, you probably don’t need to understand CPU cache hierarchies. The abstractions work. The question is what happens when they don’t.

The Job Market Reality: A Barbell Distribution

Bureau of Labor Statistics projections for 2024-2034 reveal divergent paths.

Software developers overall show 15% projected growth, much faster than the 3% average, with approximately 129,200 annual openings [26]. Web developers show 7% growth [27]. But computer programmers (traditional coding roles) are declining at -6%, with the BLS noting „programming work continues to be automated“ [28].

The salary structure reflects this split. Systems and embedded engineers earn $100,000-$170,000 median compensation [29]. Application and web developers earn $90,000-$133,000 [30]. DevOps and platform engineers, occupying the middle ground, earn $116,000-$148,000 [31].

At the extremes, AI specialists command a 17.7% premium over non-AI peers [32], and senior GPU infrastructure professionals can exceed $300,000-$400,000+ in total compensation [33]. Embedded systems represent a growing niche with 21% projected growth [34] and 580,720 job postings in 2023 alone [35]. Linux kernel developers command $136,000-$240,000 according to ZipRecruiter. Rust developers earn 15-20% premiums over comparable roles, with job postings increasing approximately 35% year-over-year.

The historical trend is revealing: C and C++ usage has remained stable at 16-25% over the past decade while higher-level languages grew. But Rust is the exception, growing from a niche language to 12.6% usage with the highest developer admiration rate (82.2%) for eight consecutive years [36].

The market is telling us something. High-level work is growing but also commoditizing. Low-level work is concentrating but commanding premiums. Choose your path accordingly.

What Drove the Shift to Composition

The transformation from building infrastructure to composing it has been swift and measurable.

Cloud spending grew from $90 billion in 2019 to $335 billion in 2024, with McKinsey projecting $1.6-3.4 trillion by 2040. The value proposition shifted from cost reduction to „increased business agility, resiliency, developer productivity, and access to higher order services.“

GitHub Octoverse 2023 documented this shift: 4.3 million repositories now use Dockerfiles, HCL (HashiCorp Configuration Language) adoption grew 36% year-over-year, and 81.5% of all contributions happen in private repositories, indicating enterprise work increasingly happens behind platform abstractions.

Gartner projects that 80% of large software engineering organizations will establish platform engineering teams by 2026, up from 45% in 2022. The DORA State of DevOps report, surveying 39,000+ professionals over a decade, found that „internal development platforms effectively increase productivity“ [37] by reducing cognitive load through self-service capabilities [38].

The consequence: infrastructure knowledge is being concentrated in platform teams rather than distributed across all engineers. Puppet’s 2023 report found 93% of respondents consider platform engineering a „step in the right direction“ [39].

This isn’t inherently bad. Specialization enables progress. But it creates a dependency: most engineers now rely on a small group who actually understand what’s happening under the hood.

Forces Renewing Demand for Systems Expertise

Despite the abstraction trend, several forces are creating renewed demand for systems knowledge.

AI and ML infrastructure requires GPU programming expertise. NVIDIA’s CUDA ecosystem demands „five distinct competency levels“ with salaries reaching $400,000+ [40]. McKinsey’s Technology Trends Outlook 2024 shows talent deficits, not surpluses, in Applied AI, Machine Learning, and Cloud Computing.

Rust adoption is accelerating across the industry. Microsoft announced in December 2025 its goal to „eliminate every line of C and C++ from Microsoft by 2030.“ Commercial Rust usage grew 68.75% between 2021-2025. Discord migrated services from Go to Rust to eliminate latency spikes. Cloudflare uses Rust for Pingora, serving over one trillion requests daily. Automotive sector Rust adoption is valued at $428 million (2024), projected to reach $2.1 billion by 2033.

Edge computing and IoT demand low-level skills as devices proliferate. Estimates suggest 41.6 billion IoT devices by 2026 [41]. WebAssembly is expanding beyond browsers. American Express deployed „the largest large-scale adoption of WebAssembly in a commercial application“ for their internal FaaS platform.

These aren’t legacy markets. They’re the cutting edge. And they all need people who understand what happens close to the metal.

Where Engineers Learn Systems Knowledge Today

Elite computer science programs maintain rigorous systems tracks.

MIT’s 6.033 covers operating systems, networking, distributed systems, and security [42]. CMU’s 15-213 („Introduction to Computer Systems“) is considered „one of CMU’s most reputable courses“ with challenging labs including the famous Binary Bomb exercise [43][44]. Stanford’s CS107 covers C programming, memory organization, and code compilation. Berkeley’s CS162 uses Pintos educational OS with team projects exceeding 2,000 lines of code [45].

The ACM/IEEE CS2023 curriculum guidelines (January 2024) maintain Operating Systems, Architecture, and Networking as core knowledge areas within approximately 270 „CS-core hours“ [46].

„Computer Systems: A Programmer’s Perspective“ (CSAPP) by Bryant and O’Hallaron remains the gold-standard textbook, used at CMU, Stanford, and numerous other programs. It originated from CMU’s 15-213 course in 1998 with the philosophy that „students should be introduced to computer systems from the perspective of a programmer“ [47][48].

For self-study, MIT OpenCourseWare provides free access to 6.033 materials. CMU publishes CSAPP labs for independent study. Berkeley and Stanford webcasts are publicly available. The barrier to systems knowledge isn’t access, it’s time and motivation.

You don’t need a CS degree to learn this stuff. You need discipline and curiosity.

The Competitive Edge: Synthesis and Judgment

The most interesting insight comes from recent DORA research: AI adoption correlates with reduced delivery stability by 7.2% and throughput by 1.5% [49]. „Batch size tends to increase when AI is used in coding. And bigger changesets are riskier“ [50].

The implication: as AI handles routine implementation, human engineers face harder debugging and design challenges. Precisely where systems knowledge becomes essential.

Gartner predicts developers‘ roles will shift „from implementation to orchestration, focusing on problem solving and system design“ [51]. But orchestration without understanding creates fragility. Michelle Brush notes that „our brains are going to start working on higher and higher abstractions“ [52], yet when those abstractions fail, someone must descend the stack.

The competitive edge lies in selective depth combined with broad orchestration capability. Most engineers can work effectively at high abstraction levels. The differentiating skill is recognizing when abstractions are leaking and having sufficient systems knowledge to diagnose and resolve the underlying issues, or knowing enough to collaborate effectively with specialists who can.

Google’s engineering ladder at L5+ explicitly evaluates system design ability [53]. The difference between a senior engineer who can diagnose mysterious latency and one who cannot often traces back to whether they ever understood what TCP is actually doing.

You don’t need to be a kernel hacker. But you need to know enough to ask the right questions when things go sideways.

Conclusion

The question „do we still need low-level knowledge?“ has no universal answer.

For approximately 75-80% of software development work, high-level abstractions suffice. The industry’s trajectory toward platform engineering, cloud composition, and AI-assisted development will continue. If you’re building web apps, mobile experiences, or business logic, you can have a successful career without ever touching a pointer.

But the remaining 20-25% of systems-focused work is becoming more valuable, not less. Embedded systems, AI infrastructure, performance-critical applications, and the infrastructure underlying everyone else’s abstractions require deep expertise. Rust’s ascendance signals that systems programming isn’t dying, it’s modernizing.

For individual engineers, the strategic question isn’t binary. Understanding systems fundamentals, even without using them daily, provides insurance against leaky abstractions and a foundation for growth into senior technical roles [54]. The market increasingly rewards those who invested the time.

Joel Spolsky’s Law remains apt: abstractions save us time working, but they don’t save us time learning [55][56]. You can skip the learning and have a fine career. But when production is down at 2 a.m. and everyone’s staring at you, you’ll wish you hadn’t.

The choice is yours. Just make it consciously.