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

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.