When our brain manages a high cognitive load, it depletes our resources for willpower and self-control. That was the finding of a Stanford researcher Professor Baba Shiv in 1999 when he did an experiment. He asked two groups of people to memorize a number and walk to the next room and recall the number. What they did not know is that he gave one group a seven digit number and the second group he gave a two-digit number to memorize. At the end of the experiment, he offered both groups the choice of a bowl of fruit salad or a piece of chocolate cake. He found that by an overwhelming degree, the people who had to memorize the seven digit number chose the cake over the fruit salad. Memorizing hard numbers or solving complex problems erodes our ability to maintain self-control and people caved to their feelings rather than what was logically better for them more easily.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler, "Refactoring: Improving the Design of Existing Code"

When I first started working in teams and became self-aware about the kind of code I wrote. I started to ponder about what was well-written code and what wasn't. One thing that is easy to forget when developers work is that code is written for humans. A lot of new developers think that the use of some obscure syntax or some convoluted workflow shows off their ability to code "well" but I learned over time that is the wrong way to code. Your code has to be legible to your colleagues as well as your future self.

Well written code is a like a well-written book, it is easy to follow, you do not need to frequently research what you are reading to understand it and you do not need to mentally carry complex constructs from other parts of the book to understand what is going on now.

In one of my first Software architecture classes my professor sang the mantra "Your software should have high cohesion and low coupling". He repeated this over and over again that it has been beaten into my skull. In layman terms, this means that similar concepts in your code should be close together in proximity, and these unique concepts should be as independent of one another as possible. This is important in order to have a maintainable codebase, it makes it easy to read and makes it easy to prevent and fix potential bugs.

This all goes back to the beginning well-written code should be easy to follow. I should not need to memorize what the function from three files ago does to understand this one line, so adding, modifying and understanding a code base should leave me going for the fruit salad as supposed to the chocolate cake.

So a question I ask myself now when I sit down to write code is, will this code make me fat?