Analyzing Krazy Kode

Accounting for the emotional state of the person who wrote that code

Dear KV,

Sometimes, when I'm reading other people's code, I almost feel I can hear what they were thinking. But then, sometimes, it seems that what they were thinking was completely alien, or possibly even insane. Considering that computer languages are more constrained than human ones, I'm surprised at the wide variation in the code I'm exposed to, even within the same company or group.

Somehow, I thought that—with things like modern coding standards—code would start to look more alike, but that seems to be all form and not function. How do you deal with all the various codebases you must be exposed to?

Variously Confused

Dear Variously,

While recent languages that dictate the form of the code—and here I'm thinking about Go and, to some extent, Rust—can enforce some visual similarity, the process of reading someone else's code is probably still more akin to psychoanalysis. This applies as well to systems that reformat the visual representation before the code is committed for C and C++. KV often wonders if code annotations from the DSM-5 (Diagnostic Standard Manual) [https://en.wikipedia.org/wiki/DSM-5] would be appropriate in a code review—along with questions such as, "Tell me the first thing that comes into your head about... your mother?"

It's true that code can tell you a lot about a coder, including their age, what language they write in most often, and their emotional state when the code was written. If you doubt me, go back and look at your own code and think back on how you felt when you wrote it.

Anyone reading KV code will see that it continues to be tinged with the sins of his past writing in assembler (do this, then this, then this) and C, which remains his day-to-day language. That's because KV angry code has a staccato feel to it—lots, of, short, variables, and comments that clearly once included George Carlin's seven dirty words but were cleaned up before check-in time. KV long ago learned not only to check the spelling of his comments but also to see if there were any other things that might cause future embarrassment. [https://queue.acm.org/detail.cfm?id=2246038].

KV's only emotion besides anger is calm, and calm code has a more playful feel. Variables and functions are named logically, of course, but they may also contain a bit of whimsy, along with comments written in full, grammatically proper sentences that don't sound like orders barked from a ship's bridge.

Now, why should it matter if the code was written when you were sad, mad, or glad? It turns out your mental state when solving a problem often has a bearing on the solution and how correct or complete it is. Code written in a rush of anger ("Damn it! I'm going to smash this bug with a hammer!") is often incomplete because, once the anger has been vented, coders typically lack the emotional energy to go back and check their work. The idea was just to smash the bug, commit, and be done.

Conversely, when code is written in a happy state—a state KV has only heard about in stories—there is a better chance the code (and even the tests) is complete because the person who wrote it was in a great mood and took joy in the work. If you ever find someone who continuously creates code in a happy flow state, you should work with that person. But you also might want to make sure it's a real flow state and not just microdosing, which now is all the rage amongst the kids in the Valley.

There actually are about six or seven emotions, or so I'm told. But the one state you should really try to avoid is confusion, which isn't actually an emotion but instead a state of mind. Code created by a confused mind shows itself in the randomness of naming, which is not handled by modern, fascist, programming languages like Go. Sure, you may have your names in the proper case and your spaces in the proper place, but you can still name a function PublicThingTwo() if you want to, and this is a sure sign of trouble. Now that variables are not often named i through n for integers, except in loops, they can also give clues to the state of the coder's mind. And beware the code that contains blob, new_blob, and blobNG all in the same function.

The overall structure of a set of functions also shows whether or not the coder was confused. The presence of lots of tiny functions that do very little indicates a lack of understanding about how to structure the code as well as a paranoid mindset that clearly expected every little operation to fail since each was placed in its own function so as to allow for easier debugging. Overlong functions, on the other hand, exhibit a sense of hubris, or suggest a very old programmer who dates back to the days when function calls were expensive. Age is almost excusable, but hubris is not. Hubris goes before a fall—or, in KV's world, a kernel panic, which means wading through a 5,000-line function while trying to keep all the context in your head for debugging purposes. This is what leads back to the angry style of coding mentioned earlier. And, as we all know, anger leads to the dark side.

Code, like prose, has style and color and subtlety—if we are sensitive enough to perceive it. When you open a function and start reading, try to think not only, "What does this do?" but also, "How do I feel about reading this code?" Does it make you mad, sad, glad, or something else? Knowing how the code makes you feel will better prepare you to understand it because you will have an important clue into the mind of the previous author. And, as KV has pointed out many times, code is meant to communicate our intentions to other humans.

George V. Neville-Neil works on networking and operating-system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are computer security, operating systems, networking, time protocols, and the care and feeding of large codebases. He is the author of The Kollected Kode Vicious and coauthor with Marshall Kirk McKusick and Robert N. M. Watson of The Design and Implementation of the FreeBSD Operating System. For nearly 20 years, he has been the columnist better known as Kode Vicious. Since 2014 he has been an industrial visitor at the University of Cambridge, where he is involved in several projects relating to computer security. He earned his bachelor's degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. His software not only runs on Earth, but also has been deployed as part of VxWorks in NASA's missions to Mars. He is an avid bicyclist and traveler who currently lives in New York City.

Originally published in Queue vol. 23, no. 1—
Comment on this article in the ACM Digital Library

More related articles:

João Varajão, António Trigo - Assessing IT Project Success: Perception vs. Reality
This study has significant implications for practice, research, and education by providing new insights into IT project success. It expands the body of knowledge on project management by reporting project success (and not exclusively project management success), grounded in several objective criteria such as deliverables usage by the client in the post-project stage, hiring of project-related support/maintenance services by the client, contracting of new projects by the client, and vendor recommendation by the client to potential clients. Researchers can find a set of criteria they can use when studying and reporting the success of IT projects, thus expanding the current perspective on evaluation and contributing to more accurate conclusions.

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.

Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.

Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.