Personality trait influences in the codebases we debate over

Some time ago, there was a certain piece of source code that a game developer released that sparked some debate. It called Player.cs was intended for character movement code in games. It was 5400 lines long and it got other programmers debating over the denseness of the code and why it wasn’t split up for easier code management. The author’s response: it would’ve made for a messy web of dependencies. I got me thinking, what is the nature of the debate itself? What aspects of our personalities go into the codebases we write?

There is widely accepted research on the aspects of personality thanks the efforts of psychologists across the world. What I’m referring to are the Big 5 personality aspects, specifically Conscientiousness, which is a measure of how careful or vigilant one can be. For people on the higher end of the Conscientiousness scale they tend to be more orderly yet more conformist. They are also likely to be more disgusted. People on the lower end of the Conscientiousness scale tend to be more creative and adaptable yet more messy.

So it stands to say that the most prevalent philosophy of programming, Object Oriented Programming(OOP) promotes a more conscientious style. It advocates using encapsulation, abstraction, etc - techniques to segregate, or ‘draw boxes’ around our code into chunks of other reusable code segments which in turn promises to yield programmer productivity benefits. You’ll see this prevalent in enterprise code, and some of the technique have even been enforced onto the rules of programming languages.

On the flip side, you’ll more likely to find code that breaks such established rules in the codebases of growing startups, software that changes frequently or has a large count of intermingling features, even small hobby projects. Compression oriented programming talks about pushing code for reuse only when it is needed rather than architecting it in detail at the start. I find it suits a very adaptable and low mental overhead style of programming, and yet is capable of producing dense code.

There are a number of real-world parallels that describe the conflict between the two ends of the Conscientiousness scale. As an example, think of the orderly person going ‘Why don’t you pick up?!’ to the messier person, in which he/she replies ‘Why does it matter?!’. We debate endlessly on which side is the ‘better’ side, trying to achieve the perceived notion of a ‘perfect’ codebase.

A bunch of very detailed class names in the Spring Libraries

The above picture shows a glimpse of what happens when programmers overindulge on putting too many barriers in place in an attempt to make nice and orderly. Like all barriers, we end up with a rigid, hard to change codebase - similar to the real-world Red tape phenomenon, where each aspect has to keep up with the other’s changes resulting in efficiency losses.

On the cognitive side, each time we introduce a named object, it has to be input into our brain’s memory space. Given our knowledge on how memory retention works, these memory nodes have to be exercised or refreshed so that the memory sticks around. Perform one too many encapsulations and abstractions in your codebase and your programmers will find that they have to review code often least they forget them, leading to time wasted.

And it’s this overindulgence that makes for very bad practices. The orderly person, being used to certain norms and practices all his life suddenly finds himself unable to adapt to new situations around him. The messier person is too scattered to do anything of worth. To solve this, what psychologists recommend is that one should try to find a balance between the two sides, and even tune it to meet certain objectives.

And that is what I believe that we as programmers should try to balance and fix. As a wise programmer once said, “Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.” , I hope that programmers can consider the range of personalities and find a sweet spot for their codebase which it feels productive and fun to work in with the minimal amount of abstraction necessary. So long as there are people with different personality traits, there will be no perfect codebase of a uniform quality.