Keys to Success: Reduce Cognitive Load

Jo Rhett — Mon, 19 May 2025 18:27:00 +0000

Reducing cognitive load is perhaps one of the most important things we do, both for our co-workers and for our customers.

What is cognitive load? Simply put, cognitive load is the effort being used in the working memory. This working memory can be overwhelmed when processing large amounts of new or complex information, leading to reduced comprehension and retention.

It would be hard to show this better than was done by Artem Zakirullin at github.com/zakirullin/cognitive-load

When I review pull requests, effort taken to reduce cognitive load for a future reader is one of my primary targets. If your pull request description is so unclear that a person has to read the code to understand it, you aren’t helping your coworkers (who will end up maintaining it) or your customers, who are impacted by the speed and accuracy of the cognition of your work.

If the person who has to maintain or interact with your code later has to spend almost as much time understanding it as you did writing it, then what you did has very limited, and arguably negative value.

So how do we reduce cognitive load?

Our goal should always be to reduce cognitive load for the reader, allowing them to make use of the primary knowledge without having to go through the entire learning process on their own. You found the way up this mountain, leave a clear trail to make the process easier for the person behind you.

1. Remove noise – Don’t ask someone else to expend effort to identify what is important.

What you submit for review should be focused and high quality. Remove any:

inactive pieces of code
junk or obviously wrong values
personal notes or obtuse comments that would confuse someone from outside

A code reviewer should never be required to identity and discard pieces of unused code that aren’t applicable to what they are reviewing.

2. Describe the change clearly. Make clear to the reader What changed and Why , as the How should visible in the code itself.

Speak only to the change and how it works. Don’t include references to other efforts unless they are necessary to the topic, and never, ever refer offhand to something only a person with current context will understand. You’d be surprised how fast context degrades even in closed, tight teams.

3. A pull request ready for review should have all commit messages squashed down to a clear definition of the changes. Under no circumstances should a PR contain commit messages speaking to the progress of the development.

There’s a tremendous load put on the reader by seeing dozens of commits that go back and forth on minor changes. Squash your development process down to make it easier for the reviewer.

Hiring — Yer doin’ it wrong.

Jo Rhett — Thu, 11 Apr 2019 19:18:33 +0000

Effective earlier this month, I’ve decided to start rejecting requests for whiteboard coding not actually related to my job. I think you should too, and here’s why:

I think we’ve all faced it. The request to code up and optimize an algorithm on a whiteboard. While these can be fun and once in a while lead to interesting discussions with the interviewer, unless you are an engineer being hired to work on algorithmic work, this is a waste of time.

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

— Max Howell (@mxcl) June 10, 2015

I’ll explain why in my experience with Google. Time and again I’d get offered a great role there… and then get interviewed for some completely different role. No matter how dead on my skills are for the job, my technical interview is variably with someone from a totally different team that knows nothing about my job. So they interview me about theirs.

After getting through a few of these interviews at other jobs, I’ve realized that it’s more than annoying–it’s actively harmful to your team. Yes, I said actively harmful. Here’s why:

Good at simple algorithms does not mean having the skills relevant for the role.
You’re missing out on time to interview the candidate on real needs.

If you put both of these together, you have two scenarios:

You have difficulty hiring people with experience appropriate for the job.
You will hire people who have the wrong experience for the job.

I’m going to put this straight on it’s nose as relates to my own DevOps / SRE roles. Most of the time we don’t want someone who will try to go code up a new data structure algorithm for a small infrastructure management task. When you are managing infrastructure at scale, having a bunch of individual hand-crafted one-off automation implementations isn’t ideal– it’s your worst nightmare. You should be interviewing for someone who:

Can identify and classify risks around any given implementation
Knows existing tools and libraries applicable to a given need
Is aware of and can recommend best practices related to a given scenario

To make it clear, what you want is an automation engineer who can reuse and adapt existing tooling to create as many hand-crafted, one-off instances as necessary without creating a new set of tools for each one.

Yes, the ability to create new tools when the existing tools are insufficient is important. But I’d rather hire someone who understands the ongoing cost and investment of doing that, and can weigh the costs and benefits.

DEV Community: Jo Rhett

Keys to Success: Reduce Cognitive Load

Hiring — Yer doin’ it wrong.