A developer's computer does a lot of work before the first line of code runs. An editor opens language servers. Browsers launch multiple processes. Containers start databases and application services. File watchers, security software, and background utilities all compete for resources.

When the machine slows down, choosing the next step can be difficult. Should you close applications, adjust Docker, upgrade hardware, or move to Linux? This series will help you answer those questions by understanding your workstation and configuring it around the work you actually do.

Start with your workflow

A useful configuration begins with a clear description of your everyday tasks. A Drupal developer running a PHP application, a database, and a frontend build has different needs from someone training models or editing video. Even two developers using the same laptop may need different settings.

Write down what you want to improve: shorter build times, responsive editing, fewer interruptions during container startup, better battery life, or room for a local AI tool. Those outcomes give each configuration change a purpose. Each adjustment should also leave your workstation easier to understand and maintain.

Measure where the memory goes

One workstation review illustrates why measurement matters. Its report contained 471 process entries grouped under 141 application names. The 15 largest groups accounted for about 92% of the measured private resident memory. The remaining 126 groups together used just 1.36 GiB.

That result pointed the investigation toward the largest workloads. It also raised another question: why can the system's total memory use be higher than the sum attributed to applications?

Private resident memory is only one category. System totals also include shared application memory, kernel allocations, drivers, and other resources. Standby cache can be reclaimed and is counted as available memory. Comparing figures captured at the same time, with their definitions understood, is essential. Microsoft's memory guide explains these distinctions.

What we will cover

1. Establish a baseline. Inventory the CPU, usable RAM, storage, graphics adapters, drivers, and development tools. Capture timestamped reports during a representative session.
2. Understand memory pressure. Read system and application figures, distinguish available RAM from private allocations, and investigate the workloads that affect responsiveness.
3. Configure WSL and containers. Examine running services, Linux cache, memory reclamation, and resource limits. WSL offers both a memory ceiling and cache reclamation settings; their effect needs to be checked against your active workload. WSL configuration reference.
4. Give the GPU a useful role. Explore local inference, document processing, media tasks, and GPU-enabled development containers. NVIDIA GPU access is available through Docker Desktop's Windows WSL2 backend with the required setup. Docker GPU support.
5. Evaluate Linux for your machine. Check application compatibility, drivers, displays, peripherals, and everyday usability. For NVIDIA graphics on Ubuntu, we will use its supported driver-management tools. Ubuntu's driver guide.
6. Keep configurations reproducible. Record changes, keep useful diagnostic scripts, and repeat the measurements after updates or changes to your development stack.

Choose an operating system around your tools

Moving to Linux can change how you run development services and containers. Running those tools natively removes the Windows/WSL arrangement, but your application workloads still require resources. Docker Desktop on Linux also uses a virtual machine, so the choice between Desktop and native Docker Engine belongs in the comparison. Docker's Linux architecture.

We will compare setups using the same projects and tasks. Build duration, memory pressure, graphics behavior, sleep and resume, and battery life will help determine which configuration suits your work.

Your first exercise

Before changing settings, capture a baseline with your usual applications open:

• Record your computer model, usable RAM, and detected graphics adapters.
• Note the projects, browser sessions, containers, and background services you are using.
• Capture total memory use, available memory, and the largest application groups.
• Describe any slowdown and the task happening when it occurs.
• Save the report with a timestamp so you can compare it with later runs.

In the next article, we will turn that baseline into a practical workstation inventory and learn how to read the results. From there, each installment will connect a measured problem with a configuration change and a repeatable check of its effect.