Cognitive Thieves among us

Energy is the ultimate source of everything. All we do as human beings in daily life is transforming one source of energy into another. We consume food that gives us nutrients and energy calories that in turn distributes throughout our body. Then our organism spends the energy to allows us to breathe, makes our heartbeat, allows us to move, allows our brain to think. Energy gives us the ability to work, enjoy our life, and grant enjoyment to those we care about most.

If we are not balancing consumed and spent energy carefully, we inevitably gravitate towards the end of being.

We are Software Developers, and cognitive energy is our bread and butter. But what if I tell you that there is a possibility that there are Cognitive Thieves in your environment that steal our energy from you daily? Moreover, what is the Cognitive Thief is you?

I wrote this article to introduce the concept of Cognitive Thieves. Show insights on how to spot them and how not to become one for your teammates. I would share practices you can use to protect yourself from their impact. You should read it if you want to get tools to protect yourself from losing the precious energy you would rather spend on things you love. Enjoy the read!

The "D-Squad" team

Imagine an average software development team of 5 devs called "D-Squad"; Each team member alone is a clever Software Engineer. Each developer is responsible for developing and shipping new features, fix bugs, and do all necessary for the project to succeed.

Everyone from the team is often working on someone's code, the code they did not initially develop. This work is usually cognitively more intense than working on a greenfield feature from scratch or changing the own code. Because usually, it is harder to pick up the brain of someone who developed it.
One of the team member lets say Bob get a bug he needs to fix and stumbled upon this piece of code he needs to understand:

for j in range(4):
    r = 0
    while i < len(data):
        if not data[r]["is_leaf"] and ( r + 1 >= len(data) or data[r + 1]["level"] <= data[r]["level"]):
            del data[r]
            continue
        r += 1

Does this code look like a small black hole for cognitive energy? It is fair to guess that Bob is frustrated as he needs to understand what this piece of code is doing and why. Although Bob can figure it out with a decent amount of time with a debugger where he will try to revise what the "data" consists of, what do those keys mean, what is the magic number "4". But what would be the cognitive cost of this for Bob?

Today it is Bob, but unless he has enough courage to refactor this code, other team members will stumble upon this "not well-written prose" at some point, and it would suck another portion of cognitive energy. Imagine what would be the lifetime energy cost to maintain this?
Guess who was the author of this code? That is right - it was the Cognitive Thief.

The Cognitive Theif

Let's dive into the definition I created for this. The Cognitive Thief is the person who writes a code in a way that requires others a tremendous amount of cognitive energy to understand.

They disobey the principles of clean code. They write the code as if they do not care about the team members who will work with this code later. They usually really smart and have formal CS degrees. Traditional education institutions allowed them to learn only the academic coding style. And the academic coding style is focused on writing the code for machines first.

The Cognitive Thieves does not realize yet that 60th, 70th, and 80th when there were just a few Software Developers and it was fair to write code for machines only. They do not realize that things changed. That there is more collaboration in Software Development than ever and that Software Development craft turned to be more about human rather than machines.
The more cognitive energy code consumes for its maintenance, the higher level of the Cognitive Thief who wrote it.

The cost of having Cognitive Theif in a team

The overall purpose of forming teams is to get the ability to do more work. In a simple example, if one person can accomplish 100% of the work - 5 people should get done 500% of the work. In rear cases, when synergy occurs within the team, it could be more than 500%. Of course, this is not a real-world formula. But one will serve the purposes of this example well.

But what if there is one Cognitive Thief among them. One writes a code in a way 4 others can barely understand. Hence, to understand and work with the code, they always spend a lot of cognitive energy. And that slows them down. How do you think this trend will impact the overall team's performance? That is right - the overall performance will constantly decrease.

If, for example, 5 people can deliver 500% of results. With the Cognitive
Thief, this number will never be 500%. The cognitive thief could produce 100% or even 120% percent of results, but each of the other 4 people will spend 35% of cognitive energy to grasp the solution. Would not it be 140% of wasted effort? Would not it be that removing this person from the team would add to overall team performance?

Well, there is always a cognitive cost to understand someone's code. But the less effort it is, the more writer of this code cared about you. I believe this is the actual team play when everyone cares about each other.

How to spot the Cognitive Thief

Each time you see a piece of code that does not communicate its intent, use magic numbers, does not use self-descriptive names, does not use domain language, code design that violates SOLID, etc. These are all signs of Cognitive Thief.

Fortunately, we develop in the age of version control systems that allow us easily define the author of the code we see in a codebase. For example, you can start by using the git blame command to find out the code author.

What to do to protect from Cognitive Thieves

There is no direct way to protect your cognitive energy from the impact of the Cognitive Thieves if one in your team. Most companies expect that you, as the Software Developer can work with any piece of the code they have in the system. So what to do to protect your brain from cognitive energy suckers?

One of the fastest and most radical ways to protect your cognitive energy from thieves is to avoid working in teams where they exist. If you are in a position where you can switch the team or easily switch the company, it can solve a problem.

I believe that many Software Developers are not in a position where they can move with the radical approach. And I have other options for these folks.

First of all, start with yourself. Learn principles of clean code and obey them with every line of code. Show everyone how great clean code could be and that it is not hard to write one. Become an ambassador of the clean code principles in your team.

Then use the Pull Request reviews as an opportunity to reveal blind spots of the code Cognitive Thief wrote. And showcase the cleaner way to write the code. Offer them ways to improve the clarity of code. Do it in an emotionally intelligent way though, do not aggressively criticize as the teammate may turn into protection mode, and change will never happen. This way, you can help the Cognitive Thief to become better and even transform out from being one.

The other principle that you can incorporate and use is the Radical Truth and Radical Transparency I borrowed in Ray Dalio. This way, you or your teammates will communicate early to the Cognitive Thief regarding energy leaks caused by their code. If incorporated early, it could save tons of cognitive energy.

Remember that the Cognitive Thief is not writing the code intending to make life harder for teammates. It is just the way they learned to write code at school. Be condescending and try to show that the better way exists.

How not to become one

First of all, aim to write code for people first rather than solely for machines. Always think about your teammates when you write code, show by the code that you care. Be a team player!

Remember that human brain computational power is not as salable as computers. Hence it is often better to write a bit slower code that your team member can understand faster rather than strive for the most optimal solution that everyone would avoid touching. Or write code scalable for people first and machine second.

Apply SOLID principles in your code design. It is hard to overestimate the positive impact of applying these principles in the system.

Use clean code principles. There is a lot of information sources regarding what the clean code is. But if you have not had one yet, I will strongly suggest the Clean Code series by Robert C. Martin.

It is a remarkable book with lots of must-know principles that, when followed, make things a lot better teamwise. All the examples in Java there but they are simple enough to show the essence of the principles.

One quote borrowed from this book that always on top of my head when I think about the clean code:

"Clean code is simple and direct, and it reads like well-written prose. When you read a clean code, you feel that the author cared about the reader."

Think about the question - "Are we write code for machines, or we write it for humans?" Perhaps we were writing the code solely for computers in the 60th. But now things changed, and Software Developers write more for other Software Developers rather than a compiler. 

The growth ratio in machines is higher than the growth ratio of human brain performance. Hence, why not focus on optimization for people rather than machines? The cleaner code you write, the more you care about your colleagues and the less chance to become the Cognitive Thief.

Before you go

Let's recap what we covered. We have gone through the notion of the Cognitive Thieves and the cost of having one in our team. We have also covered how to spot one, what to do to turn one off from the dark force, and how not to become one.

Although I believe every developer, at some point, writes the code that sucks out the cognitive energy from everyone who tries to understand it. I encourage everyone to go the extra mile and incorporate code principles that would help you to write Emotionally Intelligent Code. The code that will show that you care about the reader.

As I mentioned in the beginning, energy is the ultimate source of life. And you as a Software Developer can either waste it or save it for those around you. What would you choose? My choice is to save.