There comes a moment in every developer’s life when the laptop looks up from its fans, clears its tiny metallic throat, and says, “I’m terribly sorry, but I appear to have become a toaster with delusions of warp speed.”
This is rarely caused by one dramatic villain in a black cape, unless you count the meeting app. More often, it is a committee of small gremlins: browser tabs, containers, language servers, desktop apps, indexing jobs, local databases, and that one “temporary” development server that has been running since the last moon landing and now appears to have developed a constitution.
This is a generic field guide to keeping your local machine from attempting faster-than-light travel through the medium of memory pressure. No specific machines, no private screenshots, and no forensic autopsy of one laptop’s bad afternoon. Just practical advice, with a small towel tucked safely in the toolkit and a warning label that probably reads, “Mostly harmless.”
The Problem: Your Laptop Is Not a Starship
Modern development workflows are brilliant, but they are not shy. A normal day can involve:
an IDE with file watchers, language servers, extensions, AI helpers, and indexing;
a browser with enough tabs to qualify as a minor civilisation;
Docker or another local runtime keeping services, databases, caches, and queues alive;
desktop chat, meeting, AI, and collaboration tools;
build tools, test runners, hot reloaders, and background synchronisation processes.
Individually, each one seems reasonable. Together, they can behave like a fleet of Vogon constructor ships parked on your RAM, idling loudly and insisting the paperwork was filed in triplicate.
The aim is not to stop using powerful tools. It is to avoid having every tool in the galaxy switched on at once, humming ominously.
Rule One: Know What Is Actually Running
Before reaching for heroic solutions, check what is consuming memory, CPU, and disk. Guessing is how people end up blaming the kettle, Mercury in retrograde, or “probably Chrome” without evidence.
Useful checks include:
your operating system’s Activity Monitor, Task Manager, or process viewer;
the browser’s built-in task manager;
your IDE’s process explorer or extension diagnostics;
container runtime commands such as docker ps, docker stats, and docker system df;
disk usage tools to spot swollen caches, old build artefacts, and container images.
Think of this as asking the ship’s computer, “What exactly is on fire?” before replacing the engines.
Keep the Browser from Becoming a Black Hole
Browsers are magnificent, but a browser with too many live tabs can become a small gravitational event with bookmarks, favicons, and a worrying appetite for moons.
Use built-in memory controls
Turn on memory saver or sleeping tabs where your browser supports it.
Disable page preloading if it is using resources for pages you may never visit.
Use browser task manager tools to identify runaway tabs or extensions.
Be ruthless with tabs
Keep active tabs for active work.
Move research trails into bookmarks, reading lists, or project notes.
Close duplicate tabs before they begin forming a union.
Audit extensions
Extensions are often separate processes. A few helpful ones are fine; a museum collection of forgotten extensions can quietly eat memory while wearing a false moustache.
Disable extensions you do not use.
Remove overlapping tools that do the same job.
Be especially careful with heavy developer tools, grammar tools, AI helpers, and blockers with large rule sets.
Tame the IDE and AI Coding Tools
Modern IDEs are less like text editors and more like orbital stations with opinions. They index files, run language servers, watch folders, host terminals, manage extensions, and increasingly invite AI assistants aboard.
Open only what you need
Open the actual project folder, not the parent directory containing every repository you have ever loved.
Close workspaces when you switch context.
Avoid keeping multiple large projects open “just in case”. That phrase has doomed many spacecraft.
Exclude noisy folders
Use ignore files and editor settings to keep generated or low-value content out of indexing and search. Common candidates for banishment to the cargo hold include:
node_modules, vendor, virtual environments, and dependency folders;
build outputs such as dist, build, .next, and cache directories;
logs, reports, coverage output, local database files, and generated fixtures.
Your editor does not need to contemplate every generated file in the universe. It already has enough existential burden.
Review extensions and agents
Disable duplicate AI assistants or overlapping code tools.
Turn off language servers you do not need for the current project.
Reload the editor occasionally if extension hosts or language servers grow unexpectedly.
Stop development servers and terminal processes when you are finished with them.
AI agents are useful, but they are not houseplants. Do not leave them quietly photosynthesising in the corner forever.
Do Not Let Containers Colonise the Planet
Local containers are wonderful for repeatable development environments. They are also very good at leaving behind images, volumes, build cache, stopped containers, networks, and mysterious space barnacles.
Check what is running
docker ps docker ps -a docker stats
Stop services you are not actively using. A local database, queue, cache, search index, and background worker may each be innocent. Together they can form a small moon, then apply for planning permission to become a planet.
Check disk usage
docker system df
This helps identify whether images, containers, volumes, or build cache are taking up space.
Clean up carefully
Useful cleanup commands include:
docker builder prune docker image prune docker container prune docker network prune
For a broader cleanup:
docker system prune
Use more aggressive options only when you understand what they remove. Be especially cautious with volumes, because they may contain local database data. Accidentally deleting your local data is a poor way to discover the meaning of life, the universe, and everything.
Set sensible resource limits
If your container runtime allows CPU, memory, swap, and disk limits, set them deliberately rather than letting local services raid the pantry unattended.
Give containers enough memory to work, but not enough to devour the host.
Use resource saver or sleep modes where available.
Prefer starting project stacks on demand instead of keeping every service alive all day.
Preserve Disk Headroom for Swap and Breathing Space
When memory pressure rises, operating systems often lean on disk-based swap. If the disk is nearly full, the machine has nowhere to put the extra furniture and starts making dramatic noises.
Good habits:
keep meaningful free space on the primary drive;
regularly remove old downloads, installers, archives, and build outputs;
clear obsolete container images and caches;
move bulky media or archives off the local machine where appropriate;
avoid treating the desktop as a long-term storage architecture.
A laptop with no disk headroom is like a spaceship with every corridor full of mattresses. Technically cosy, operationally doomed.
Reduce Desktop App Duplication
Many desktop apps are effectively browser-based applications in a trench coat. Running several of them at once can duplicate engines, renderers, helpers, and background processes.
Consider:
using web versions for tools you only need occasionally;
closing chat, meeting, and AI clients when not in use;
avoiding multiple apps that provide the same capability;
checking whether a command-line or browser workflow is lighter for some tasks.
This is not a moral judgement. It is merely a reminder that “just one more desktop app” is how the bridge crew ends up sharing oxygen with six Chromium engines.
Offload Heavy Work When It Makes Sense
Not everything has to happen on the local machine. Some jobs are better sent to a more suitable part of the galaxy.
Run heavy test suites in CI or remote runners.
Use remote development environments for large projects.
Move long-running automation away from your daily workstation.
Use ephemeral environments for short-lived experiments.
Keep local development focused on fast feedback, not heroic endurance trials.
Your laptop should be the cockpit, not the entire planetary defence grid.
A Simple Maintenance Ritual
Once a week, or whenever the fans begin reciting poetry in a language last heard near Betelgeuse, run through this checklist:
This is less glamorous than shouting “Engage!” at your laptop, but it is much more likely to help.
The Takeaway
Local resources are finite. Modern tooling is powerful. The trick is to avoid treating your development machine like an infinite improbability drive with a keyboard attached and a cup holder full of build cache.
Keep active work active. Put idle work to sleep. Clean up after containers. Trim browser and editor excess. Offload the heavy stuff when local work stops being sensible.
And above all: don’t panic. But do keep a towel, a process monitor, and a healthy amount of disk space nearby.
