The Multi-Screen Myth: Stop Amputating Your Working Memory

A while ago, I stumbled upon a post from a startup founder who proudly announced that he had abandoned his three-monitor setup. He admitted he’d been lying to himself about his multitasking abilities, and that returning to a single, minimalist screen was the ultimate cure for his chronic context switching and burnout.

Now, I’m not saying it didn’t work for him. If you struggle with the basic self-discipline required to ignore flashing red badges, physically limiting your visual field might indeed keep you from straying.

But as an engineer, this line of reasoning immediately triggered a different association. (I’m not sharing a screenshot or quoting him directly, because this isn’t about publicly calling anyone out or putting their opinion on blast.) It simply reminded me of a dark, rather brutal joke from my childhood in Poland (back when Soviet-era humour was our staple for absurd problem-solving):

— What did Stalin do to stop Russian children from running around hungry?

— He cut off their legs.

It’s an incredibly grim punchline, but it perfectly illustrates a recurring systemic pathology: fixing Problem A with drastic measures that have absolutely nothing to do with Problem A. Sure, you technically achieved the goal—the children are no longer running around hungry, and the developer is no longer distracted—but the collateral damage and systemic crippling of the actual workflow are immense.

Tooling is Not the Enemy. Lack of Discipline Is.

The developer in that post tried to address a lack of work discipline and poor digital hygiene by physically amputating his workspace. That is a fundamental category error.

There are dozens of tasks in software engineering and creative work that inherently require the compilation of information from multiple sources. This is not “context switching.” It is a single, unified workflow that requires a wider field of view.

By forcing yourself onto a single screen, you are actually achieving the exact opposite of what you wanted. You don’t eliminate the fatigue; you just trade one source of friction for another. Instead of focusing, you force yourself into frantic, non-stop window switching—constantly Alt+Tabbing just to keep state.

In return, you force your working memory to do exhausting overtime. And that process—even for temporary storage—is anything but cheap.

In behavioural psychology, this is known as cognitive offloading—using physical or digital environments to reduce cognitive demand. Your screen is an external cache. If you have to hit Alt+Tab every five seconds to double-check whether a terminal error referred to lines 137 and 213, or 731 and 321, you are wasting precious CPU cycles in your own head just trying to keep state. Your mind remains in the exact same context, but you are draining your mental battery on window management.

Cognitive Offloading in Practice: My Setup

To ground this in reality, here is how I work. Personally, I use a dual-monitor setup: a massive 49-inch ultrawide main display (5120x1440), paired with a 27-inch monitor rotated vertically (2560x1440).

To keep this massive digital real estate structured without spending hours dragging windows around, I use gTile on Linux Mint (Cinnamon). It allows me to instantly snap windows into precise grid layouts via keyboard shortcuts, ensuring no space is wasted.

Here is why this real estate is a necessity, not a luxury, across different phases of my career and creative life:

1. Ancient Webdev in PHP

Take a throwback to the ancient times when I worked as a web developer writing PHP, back before we had LLMs to hold our hands. PHP has a standard library famously designed by what feels like a committee of random number generators, where some functions take a needle first, others a haystack, some return a value, others return an error code while accepting an object handle as a parameter, and a few probably even return the local weather forecast.

With naming conventions that are a chaotic war zone, I had to sit with an IDE in the centre, official documentation on one side, and a browser window showing the live render on the other, just glancing side to side to keep my brain’s context entirely unbroken instead of wasting mental energy guessing parameter orders.

2. Terraform & AWS Infrastructure

Then there is writing infrastructure-as-code with Terraform, which is essentially a high-stakes exercise in managing complex parameters and strict topographies. My setup kept the IDE in the centre, the official provider documentation next to it, and a giant network diagram of our cluster topology on the other side.

I didn’t have to guess valid parameter strings or keep a fragile, imaginary map of our VPC subnets in my head; the entire system was physically laid out in front of my eyes. This allowed me to actually focus on the core task—a massive blessing, considering that manually verifying and testing cloud infrastructure deployments was usually about as exciting as watching European Commission debates without falling asleep.

3. Right-Sizing RDS Instances

Or consider the incredibly tedious joy of right-sizing RDS instances. To pull this off without making a high-budget mistake, I needed four or five active views: two AWS cost calculators side-by-side to compare the “before” and “after” configurations (because nobody should waste energy trying to keep track of $412.31 vs. $211.57 across a dozen databases), AWS limit documentation to look up throughput caps, a CloudWatch performance chart, and a spreadsheet to log the savings.

Honestly, just being aware that these limits exist in the first place already puts you above average. I have no intention of pretending to be some sort of savant who remembers off the top of his head whether a specific instance has a throughput limit of 62.5 MB/s or 125MBit/s — and yep, I don’t even remember the exact unit. Trying to do all of this on a single 15-inch laptop screen is a fast-track ticket to throwing said laptop out the window by your fiftieth Alt+Tab.

4. Writing Non-Fiction

This isn’t just about code, either. When writing my technical pop-science book, Fuckup Almanac, a bare text editor was never enough. Non-fiction is an exercise in synthesising scattered source material, so I wrote with the main manuscript editor in the centre, research notes and case studies on the left, and the overall book structure on the right, instantly verifying historical figures—like how much a Berkshire Hathaway share cost the day it broke a 32-bit integer limit—with a simple glance, and without having to remember (or calculate) what day of the week it happened to be when the counter overflowed (Tuesday, since nobody asked).

5. Reviewing Translated Manuscripts

Most recently, I had to review the German translation of my book (yes, it’s happening: https://dpunkt.de/produkt/fckups/), verifying that my highly specific technical satire and idioms survived the translation process. I kept the original English manuscript on one side, the German draft on the other, an LLM chat open to double-check the rhythm of German idioms and brainstorm localised jokes (like whether swapping a reference to a “Karen” for a “Steffi” actually lands in German without killing the comedic timing), and a feedback log open for notes. All reference materials were visible side-by-side, keeping me in a deep, creative flow that a single screen would have utterly destroyed.

In every single one of these scenarios, I was in a state of absolute, uninterrupted flow. There was zero context switching. And in every single one of them, reducing my visual workspace would have drastically slowed me down, forcing my battered head to memorise trivial details whose lifespan is shorter than the gap between a green light and the impatient honking of Manhattan drivers during rush hour.

Why Have a Vertical Side Screen? (The Physical Friction Hack)

If a second monitor is just a distraction magnet, why keep the vertical 27-inch screen on the side for communication tools like Slack and email?

This is where physical ergonomics act as a productivity filter. Because the 49-inch main monitor is so wide, the vertical screen sits entirely in my peripheral vision.

To check Slack, I have to physically turn my head a few degrees to the left.

That tiny bit of physical resistance is a brilliant cognitive barrier. It completely eliminates instinctive, subconscious glances at incoming notification badges. I only look at that screen when I intentionally decide to break my deep work cycle to check in on communications. The noise has been physically quarantined.

But there is another massive advantage to this setup: it strikes the perfect balance between focus and availability. Because the communication window is always open and physically present on that side screen, I never run the risk of completely losing touch with the world just because Slack got buried somewhere in the chaotic, endless depths of virtual workspaces. I don’t have to hunt for it or dig through minimised tabs—it’s right there, physically isolated, yet instantly accessible when I choose to look.

The Broader Disease: Treating Symptoms Instead of Causes

The point of this post isn’t to convince you to go out and buy a giant monitor. You won’t find any affiliate links at the bottom of this page. Set up your workspace in whatever way makes you comfortable—even if that means a single laptop screen at a coffee shop.

The goal is to illustrate a much larger, more universal truth: make sure you actually understand the problem you are trying to solve before you implement a “solution.”

Context switching (uncontrolled distraction and bouncing between unrelated tasks) is a discipline problem. Cognitive offloading (structuring your workspace to reduce short-term memory load during a single task) is an efficiency strategy. Confusing the two and amputating your workspace is a classic case of misdiagnosing the disease.

Unfortunately, we fall into this exact same trap in software engineering every single day. We design complex “architectural solutions” that only address symptoms, creating massive technical debt and operational complexity while leaving the root cause completely untouched.

Take a database buckling under load, for instance. Instead of analysing inefficient queries or fixing missing indexes, we casually throw Redis and Autoscaling at the infrastructure. We pretend we’re engineering high availability, when in reality, we’re just paying AWS to mask our terrible SQL while adding a massive cache-invalidation headache to our daily lives.

Or consider a team suffering from decision paralysis and merge conflicts in a monolith. The immediate, modern reflex is to yell “Microservices to the rescue!” and split the codebase. Under no circumstances do we stop to think about the broken organisational structure or Conway’s Law; we’d rather spend the next two years debugging distributed transactions and network latency just to avoid having an honest conversation with our colleagues.

Then there is the classic struggle of database migrations blocking deployments. Rather than automating our deployment pipelines or taking an hour to design a backward-compatible schema, we excitedly migrate everything to NoSQL. We tell ourselves we’ve unlocked “schema-less” freedom, ignoring the fact that we’ve just outsourced the exact same schema complexity into our application code, which now has to duct-tape fifteen historical database versions together in production.

And, of course, my favourite: dealing with flaky, unreliable tests. Instead of trying to understand our domain boundaries or writing meaningful integration tests, we mandate a strict 90%—or why not 100%?—code coverage limit. We ignore the quality of the tests entirely, happily racking up points for dummy assertions like assertTrue(true) just to keep the dashboard green, while regressions sail straight to production.

This pattern repeats itself everywhere—not just in software, but in geopolitics, corporate management, and daily life.

But before we build a convoluted system to cure a symptom, we should stop and ask ourselves: are we actually solving the problem, or are we just cutting off the legs?