How to choose a laptop for programming

The expensive laptop that choked on three containers

A friend spent a small fortune on a gaming laptop "for programming". Top-tier processor, dedicated GPU, gorgeous benchmark numbers. Then he tried running the work stack — Postgres, Redis and two services in Docker — with the browser and editor open, and the machine started stuttering. The problem wasn't the CPU. It was 16GB of RAM turning into 16GB plus swap. He optimized the wrong number, because he bought looking at what sells laptops, not at what makes a difference in a programmer's day.

Here I go into what actually matters for a development machine, in the right order. In passing, if you still get confused by the architecture alphabet soup when choosing, it's worth understanding the difference between 32-bit and 64-bit — it's the baseline for not buying something legacy by mistake.

RAM first, always

If you can only optimize one thing, optimize RAM. It's the resource that limits day-to-day development the most, because modern programming means keeping a lot open at once: an IDE running indexing, a browser with 30 tabs, containers, a local database, maybe a VM.

• 16GB is the floor. Below that you'll live with swap and slowdowns the moment you open a minimal stack. It works for light front-end and learning, but it's the minimum.
• 32GB if you run containers or VMs. Docker with several services, local Kubernetes, virtual machines, large in-memory datasets — here 16GB runs out fast, and the RAM difference pays for itself in productivity within the first month.

And a detail that catches a lot of people: on laptops with soldered RAM (most thin ones and Apple Silicon), you can't swap it later. What you buy is what you have for the machine's lifetime. That's why I always say: when in doubt between bumping the CPU or bumping the RAM, bump the RAM.

SSD: size and type matter

After RAM comes storage. An NVMe SSD isn't a luxury, it's what makes builds, dependency installs and project indexing fast. A mechanical hard drive for development in 2026 is self-flagellation.

Size matters more than it seems. node_modules, Docker images, toolchains, repositories — these eat space at an absurd rate. I wouldn't buy less than 512GB, and 1TB is the comfortable spot if you juggle several stacks. A full disk degrades performance and becomes a constant source of "let me delete some Docker images so I can build".

CPU matters less than the marketing says

Here's the unpopular opinion: for most devs, the CPU is the most overrated component. The difference between a mid-range current-generation processor and the top tier shows up in heavy C++/Rust compilation or for people doing local data processing all day. For the typical web, mobile and back-end developer, any recent CPU is more than enough — you spend your time waiting on network, I/O and yourself thinking, not on the processor.

Spending the whole budget on a top-tier CPU and skimping on RAM is exactly my friend's mistake. Unless you compile giant projects several times a day, the CPU gain is marginal and the RAM gain is daily.

Display and keyboard: you stare and type 8 hours a day

These two are criminally undervalued. You spend the whole day staring at the screen and hitting the keyboard — they're the interfaces that affect your body and fatigue the most, and they show up in no benchmark.

• Display: prioritize decent resolution (Full HD is the minimum acceptable on a 13–14" panel), good pixel density for crisp text, and enough brightness for your environment. More pixels = more visible code = less scrolling.
• Keyboard: comfortable key travel and a no-nonsense layout. A bad keyboard you feel by the end of the day, in your fingers and in your willingness to keep going.

I'd trade half a CPU benchmark for a better screen without thinking twice. Sustained comfort beats a peak performance you almost never use.

ARM (Apple Silicon) versus x86

The architecture question became real once Apple Silicon (M1 and successors) showed that ARM in a laptop isn't a compromise — it's, in many cases, superior in performance per watt. Absurd battery, silent machine, excellent performance.

For development, the ARM ecosystem has matured a lot. Almost everything runs natively. The few gotchas that remain:

• Old x86 Docker images without an ARM variant run via emulation, slower — increasingly rare, but still happens in legacy stacks.
• Very specific native dependencies (binaries compiled only for x86) can be a pain.
• Tools that assume x86 in poorly written build scripts.

In practice, for the overwhelming majority of devs in 2026, Apple Silicon is an excellent choice. If your stack has a heavy dependency on legacy x86 images you don't control, x86 still avoids headaches. Otherwise, ARM wins on battery and silence without losing on capability.

Linux, WSL and battery

On the OS: if you work all day with Unix tools (most back-end and DevOps), running native Linux or WSL2 on Windows changes your life — parity with the production environment, without the friction of emulating Unix on top of Windows. WSL2 today is good enough that many people don't even need dual-boot.

On battery: it matters more if you're genuinely mobile (café, train, meeting with no outlet). High-performance x86 machines tend to trade battery for power; ARM delivers both. But if you live plugged in at a desk, don't pay a premium for battery life you won't use — redirect that money to RAM or the display.

Frequently asked questions

How much RAM do I really need?

16GB is the absolute floor and serves light front-end development and learning. If you run Docker containers, VMs, or multiple local services at the same time, go 32GB — and prefer more RAM over a better CPU when the budget tightens, because on many laptops the RAM is soldered and you can't upgrade it later.

Does Apple Silicon work for any kind of development?

For the vast majority, yes, with excellent battery and performance. The gotchas are rare: legacy x86 Docker images without an ARM variant run emulated and slower, and native dependencies compiled only for x86 can be a pain. If your stack doesn't depend on those, ARM is a great choice.

Is a top-tier CPU worth the extra money?

Only if you compile large projects (C++, Rust) several times a day or do intense local data processing. For typical web, mobile and back-end, any recent CPU is already plenty — the bottleneck is network, I/O and you thinking, not the processor. Put that money into RAM, SSD and the display.

Linux or Windows for programming?

Depends on the stack. For back-end and DevOps with Unix tools, native Linux or WSL2 gives production parity and removes friction. For .NET, games, or tools that assume Windows, native Windows makes more sense. WSL2 today covers most Unix cases well without needing dual-boot.

The criteria I'd apply

Buy looking at what makes a difference in your day, not at what makes the ad shine. The order is clear: RAM first (16GB floor, 32GB if there are containers or VMs), then a generous NVMe SSD, then a display and keyboard your body can endure for eight hours — and only then the CPU, which for most devs already comes sufficient in any recent machine. Decide ARM versus x86 by your stack: Apple Silicon wins on battery and silence barring a heavy legacy-x86 dependency. RAM and a good screen beat a CPU benchmark for nearly every developer — my friend's expensive laptop choked precisely because he optimized the wrong number.