loading...
Cover image for Laptop Performance Matters

Laptop Performance Matters

integerman profile image Matt Eland Originally published at killalldefects.com on ・7 min read

The post Laptop Performance Matters appeared first on Kill All Defects.


Let’s cut to the chase: the performance of developer machines matters a lot more than many people think it does.

When I write a post like this and post it primarily on a developer-oriented blog, I take it as a near-certainty that I’m going to be “preaching to the choir” with this article.

Nonetheless, it’s important to expand and explore this topic, because it impacts so many developers and it’s something so few organizations truly understand the impact of.

A Typical Conversation

Many conversations about machine performance look something like this:

Dev: My machine is so slow. Please can we replace it?

Manager: Come on, stop complaining; it can’t be that bad.

Dev: Trust me, it’s bad! It takes forever to do simple things like build code or open files.

Manager: That’s because you have so many tabs open in your browser!

Dev: Yeah, these are tickets I’m looking into, the time tracking application, my E-Mail, my calendar, search results on technical problems, documentation on methods I’m working with…

Manager: Fine, but your machine has a lot more memory and a better CPU than [random non-developer]

Dev: Yeah, but I push my machines to their limit with various tools. I’m not content with mediocrity and I don’t believe I should have a machine that limits my performance. Besides these specs don’t make much of a difference when the security software scans every build temporary file generated when navigating code or building software.

Manager: Security is not optional. The scanner is important for keeping our applications and code secure. I’m angry you would even suggest that security is bad.


Sound familiar?

I’ve had a few conversations like this over the decades and all of them left me frustrated and feeling like i wasn’t understood.

Let’s look at the impact of a slow machine and explore some things we can do to help others understand.

Note: If security scans are a primary cause for slowness, your organization may be able to relax that policy so that it doesn’t scan temporary files generated by your development environment or during compilation.

The Impact of a Slow Machine

Photo by Jonas Leupe on Unsplash

Let’s take a look at a simple scenario that I can relate to:

You’re working on a difficult and complex technical problem and trying to reproduce an elusive issue. You decide to make a logging change, then re-run a complex portion of your application to see what additional details get logged and if it gives you insight as to why you see a certain behavior on your machine while others encounter different behavior on theirs.

You make the change and then tell the application to build. The build process begins and … you wait while it goes through the motions of building the application, launching a web server, attaching a debugger, or whatever other operations it needs to do.

This takes awhile and you know it takes awhile so you do something else. You check your E-Mail, walk down the hall to the bathroom, chat with a coworker, surf the web, or do something else equally a better use of your time than waiting for he machine to become responsive.

Then, human nature takes over and you get distracted. Something catches your eye or you get pulled into a side conversation by a coworker. By the time you get back to your desk or remember the task at hand, you’re no longer even certain that you saved all the files prior to building or if you even built at all (if you got pulled into a lot of different directions).

Your context is gone and you need to pause again to remember where you left off.

What just happened is an expensive operation, and not at all an unusual one. Something that should have taken 10 seconds, wound up derailing you for 5 minutes or more.

Now imagine this scenario repeating itself many times each week and you can start to see how little things like memory, CPU, or even disk performance bottlenecks can cause a lot of waste over time.

The Futility of Machine Performance

What’s really difficult about having a slow machine is that it’s hard to fight it. If an operation takes a significant amount of time to complete (let’s say 20 seconds or more), our natural tendency as human beings is to do something else with our time in that delay.

And yet, we saw in the last section how occupying our attention with other things tends to snowball into distraction and difficulty rejoining the original task.

In fact, it’s often more productive to stare at a busy screen for a minute than to try to find something to occupy our time while waiting, just because you don’t lose focus.

However, our minds don’t see it like that.

We’re wired to always be doing something, always be solving a problem or making a productive use of our time. The idea of making a conscious decision to wait for a prolonged period of time and intentionally not multi-task is an almost alien concept.

Because of this, machine performance matters significantly. If a good machine can run a build in 10 seconds and a slow machine takes 60, these represent two entirely different scenarios from a user behavior perspective. Developers are going to be focused and able to wait for a handful of seconds with a fast machine where they would be tempted to go get coffee or peruse the web on a slower machine.

Little things add up over time.

Other Effects of Slow Machines

If an employee has a machine that is slow, they’re going to feel slow too. That machine delay is going to delay the speed at which they can execute their thoughts.

This means that machine performance can have a detrimental impact to human performance – particularly drive and motivation.

Think about it: If I show up to work and I’m ready to change the world and do whatever it takes, but my editor takes 5 seconds to display the words I just typed in, I’m not going to stay at that productivity level for long.

In fact, if I know or suspect how much my machine is hurting my performance and you don’t fix it, that can start to create a false narrative in my head where I start to believe that because you can’t afford to replace my machine, you don’t value me as an employee or contributor.

Let’s take another look at the idea of “going down the hall to get some coffee” when a machine is taking a long time to do something. Not only is this a case where you’re no longer working, but because your machine was acting up, you’re now a lot more likely to strike up conversations and distract other coworkers whose machines may not currently be giving them issues.

In short, this makes laptop performance issues almost contagious in their effects on office productivity.

This is dangerous stuff.

Why is this still a Problem?

Nobody wants employees to feel undervalued or under-equipped. So why don’t we take machine performance more seriously?

I think it’s a concept of understanding and trust.

People controlling financial decisions are not typically the same people working in the day-to-day writing tests or building out features.

In fact, financial professionals, like many office workers, need only a web browser and basic office productivity software, along with potentially a specialized accounting application or two.

For these users, a Chromebook is almost enough to live on.

That makes it hard to understand the drain of heavy development environments, the quantity of small intermediate files that are created during builds, or the nature of text indexing and code parsing that goes on under the scenes in a modern development environment just navigating through source files.

In that case, it can be hard to understand the exact impact of slow performance because the full performance load of a stressed development environment is hard to understand.

A Modest Proposal

To fix this, I have a simple idea: record yourself.

I don’t mean record your screen. I mean take some form of device and record you at your desk looking at your monitors and working with your code.

Although this is intrusive and unnatural, it can help in a few key areas:

  • The actual severity of hangs and delays is recorded objectively
  • Your behavior during these delays is recorded as well, helping illustrate the loss of context that can happen.
  • Any other forms of distractions (Slack messages, people coming to your desk, etc.) are recorded

On top of these things, taking the initiative to record your day-to-day shows that something matters to you enough to be inconvenienced or uncomfortable enough to help you communicate a point. If you are willing to go to that sort of length to illustrate a problem, people are going to be a lot less inclined to think you are “just whining and complaining”.

Of course, you don’t have to go to this type of an extreme. You could do something simpler like keep a tally sheet near your desk and record the number of times each day you got distracted waiting for a slow machine or simply the number of times you felt inconvenienced by a slow machine.

Closing Thoughts

It doesn’t always make sense to upgrade laptops, and even when it does make sense not all companies can afford it.

Additionally, recent threats and vulnerabilities around CPU architectures have lead some businesses to choose slower processors they believed to be less vulnerable to processor-specific exploits like meltdown.

This is to say that just because your machine is bad (or not as good as you would like) doesn’t mean that your organization doesn’t care about you. Business is about hard decisions and tradeoffs and that’s okay.

What’s not okay is organizations not understanding the full impact of performance issues on developer machines.

Take what you’ve learned in this article and find an opportunity to gently explain the nature of delays and distractions that we can experience as developers due to slow machines.

Posted on by:

integerman profile

Matt Eland

@integerman

Matt is committed to helping people achieve greater things. After over three decades of coding, Matt put away his mechanical keyboard and made teaching his primary job as he looks to help others grow.

Discussion

pic
Editor guide
 

Your article is really well written and you are spot on. I think for me this really depends on what you are doing.

About 8 years ago I could do this job with a MacBook Air. It was great, it had more than what I needed. The only thing I really wanted was a Retina display.

Now, I have a 13 inch MacBook Pro, the first with the touchbar and no escape key.

At 8 GB of RAM, double the MacBook Air, I am constantly maxing the RAM out.

The good news, I know what the problem is! It’s Chrome.

I am either opening 4GB or tabs in my browser. Or I have Figma or VSCode opened, both of which are electron apps.

Basically every app I use on my laptop today is just Chrome with a specific purpose. And those eat memory like nothing else.

So much so I am going to get 32GB, if not 64GB in my next machine.

So I feel this article could be less, why developers need good machines, and more, why does Chrome eat every resource on my machine, and why it has changed the developer landscape.

 

So I feel this article could be less, why developers need good machines, and more, why does Chrome eat every resource on my machine, and why it has changed the developer landscape.

Ahah so true 😂

 

I picked a few straw men culprits for the sake of getting a point across: Chrome and build times. For me the issue is actually Visual Studio with ReSharper, but that's less generally applicable.

Typically, developers are going to find ways to push their machines to the limits.

100% I agree, I just know that for my job it’s much worse today due to the tools and processes to do the same job I use to do. Yeah it’s more complicated, but is it better? IDK.

 

I feel your pain 😔 almost the same story's here. Thinking about MacBook Pro with 32 GB (I would choose some Linux machine, but I need to build XCode apps regularly)
Browsers and npm are evil, especially when you have to work on an application with huge codebase...

 

This is something that has always surprised me, that many companies don't understand that developers need good laptops and that good laptops cost money.

At my previous employer, the budget for laptops was roughly 1/14 of the amount of money I was billing our client each month as a consultant. That craptop was planned to last three years before I could get a new one. Of course it was the same budget for all employees, regardless of role. This doesn't make sense to me, especially as a good laptop can contribute to employee satisfaction for devs.

And then Windows. It might be fast on your personal machine at home, but being part of a corporate domain, it's doomed. Some organisations have probably solved this, but I have yet to experience that. CPU usage is strong and I can hear the fan, even though I'm not really doing anything. And no, WSL 2 isn't available on Windows 10 Enterprise Edition on the several-years-behind ring.

At lest we're having a constructive discussion about this at my current work 💪

 

You have hit the nail on the head with record it, you need metrics and real substance to change financial number and to influence and convince others especially financial types.

Just look at dual monitors, when i started most developers had single screens at the company that I worked for, now every one has two.

Queue the research:

business.com/articles/increasing-p...
The paper is linked in the article but the same applies to development work.

 

True.

Funny thing is that it's only several minutes after reading the article that I realized that my work laptop doesn't matter much. My development machine is actually an Azure VM running in a data centre nearly 500 Km away. "Oh no! That's crazy!" Well, it's actually a better experience than the desktop tower I used to use for development. Our laptops are really just for connecting to VMs and for corporate email (not accessible through the VMs).

The same problem persists, however: There is a cost associated with running those VMs so, for example, we cannot pick VMs that run on SSDs. Just hard disk ones. The default recommendation is something like 7 GB RAM, though we can pick 16 GB if we need it (like me). You'd need to spend time making your case to get anything fancier. But, as I mentioned above, this is waaayyyy better than it used to be for us.

 

Yeah, these are tickets I’m looking into, the time tracking application, my E-Mail, my calendar, search results on technical problems, documentation on methods I’m working with…

As a frontend developer you can add the the Figma design including desktop and mobile demo from the design.

Occasionally you also need to run BrowserStack to test your app on multiple native devices.

Besides the browser, let's not forget the unit tests that are running in Node while solving the problem, Node for the client, Node for the server. VSCode performs pretty well, but it still takes a few resources.

Oh, and of course you need to run Spotify to drown out all the noise from the open office space.

Chances are you are also expected to keep your Slack client open most of the time if not all the time.

16GB RAM is my minimum for a dev laptop, but of course the CPU needs to be decent as well. If you're doing machine learning, which I'm not, you also need a good GPU or a dedicated PC.

 

I don't have a coherent response, but I do have a whole bunch of comments!

I think that way more often than it being the machine's fault, it's the fault of the build systems or bloated software used.

I spend more of my time waiting around for remote builds for demo or production environments than I do my local ones, and I can generally continue working while kicking off a build.

I appreciate that not all developers have the same chores - most of my work doesn't require a recompilation step, because I don't work with those sort of languages very often and I don't need to import half a gig of dependencies to run a hello-world app. I change something in-place and see what it does, or I run my module in isolation.

I know you titled this "laptop performance matters" but I generally offload the processing to whatever machine I have around that's fastest, and sometimes that's a desktop. Desktops will always perform better than laptops with the same numbers.

There are other blockers, such as using Docker on a Mac with mounted file systems. That still makes things one or two orders of magnitude slower than running them natively or on Linux.

Having to deal with awkward window management, clumsy key bindings, not-very-ergonomic input devices, monitors with crappy colour profiles, that sort of thing makes everything feel a bit like a grind, and it makes you want to "upgrade your machine".

I waste more time during the day context-switching between real keyboard layouts and Apple's halfway-between-ISO-and-ANSI thing. I close windows when I expect to delete a word. That sort of thing. I'm faster in the office because I have one keyboard that I share between two machines, and I don't accidentally my work.

I guess what I'm saying is that it's my overall experience that's the problem, not the computer.

 

The "bloated software" part really hits, especially with today's software suite (take Slack, VSCode, Thunderbird, or any web browser with Js enabled) where no one cares about performance, and instead focuses on "development efficiency".

It's no wonder people are going back to "older", mostly CLI or very basic, softwares, or no-js web, as time passes.

 

That's why I use desktops for serious work. My 4 year old desktop at work was cheaper than a powerful laptop back then, and still outperforms modern thin laptops.

 

p53 with xeon cpu and 128gb of ram is still modern thin laptop :D
Jests aside, PCs are just much better for serious work because they dont have thermal or power throtling.

Suitable dev machine is workstation laptop that has quadcore cpu with at least 16gigs of ram or at least posibility to upgrade it in the future. I mean, we live in the times when even smartphones have 12GB of ram.
And Chrome with opened dev tools is eating few gigs just for apetizers.

 

And we live in times where developers no longer really care about being conservative of RAM and CPU because systems have plenty anyway :/

I still don't understand why people use the Slack client rather than just having a tab open in the browser.

Absolutely agree but why would they? Ram is cheap.

Slack notifications in browser are not that reliable as in desktop client.

RAM isn't cheap when you need to keep adding it because you want to run more than 4 processes on your system.

I don't use any kind of notifications except for confirmed meetings. I've got work to do and that works better without things screaming for attention :p

 

FYI if you are using canonical links then you don't need to specifically mention other source.

see here the doubled info

 

Feel free to put in a feature request. That's auto-generated content from the RSS import feature of dev.to.

 

The top one is, but the bottom one should be brought in from your content.