Programming is highly subjective

One thing I've come to learn in my journey as a computer programmer, is that programming is highly subjective. It isn't necessarily subjective by necessity, but the manifestation of it as it is in 2019 is with things like the so-called "Social Coding" that GitHub made popular - instant online feedback and commentary on everyone's work by others.

Let's explore a concept. What makes code "good?" Even just this simple definition is highly subjective, and thus any conclusions made to that end must also be.

To some people, the most well documented code is the best, to others, the least amount of source code to get the job done is best, to others, code which repeats itself the least is best, the code which is most modular is best, and so on... Moreso, there are compound supersets and subsets of these. Let's list out some of them:

Readability of syntax - variable naming, logical order, module naming, etc...

Maintainability - Separation of concerns, central version control, etc...

Optimization - source code file size, binary file sizes, compilation speed, runtime speed

Complexity - Two programs perform the same function... One is 5,000 lines of code and has 25 classes, the other is 1,000 lines and has 5 classes... That sort of thing

Logic structure - if(NULL == some_var) vs if(some_var == NULL),

   return case1;
return case2;


   some_var = case1;
   some_var =  case2;

return some_var;

The list goes on... What I've found is many of these things are simply a matter of preference and don't have an effect on program correctness - that is, programs A, B, and C all perform the exact same functionality, but are simply written differently.

And programming lends itself for this, because there are literally thousands of ways to write any program, if not more. In fact, there are thousands of common ways to write any given program.

However, programmer A may say that programmer B's code is inferior, programmer B may say programmer C's code is inferior, and so on. Each programmer may make suggestions that the other one follow, which are purely based off of preference.

However, I've also noticed that the more specific advice gets, the less this is the case. For instance, given a particular code snippet, to say one snippet is "better code" than the other could mean "easier to read," "less repetitive," "more performant," and etc... These can further be broken down - "Code B performs on average 500ms faster on an AMD Ryzen 9 3900X over 200 executions" is less subjective, but even still, another programmer may retort with "500ms is not significant for the purpose of this application" and so on.

I've noticed that all of the above, makes programming generally a highly subjective field. Additionally, culturally, software is a relatively loose field. Almost all standards are "conventions" rather than hard specifications and many shops write code wildly different from other shops: bad practice at one shop may be the gold standard at another. A valuable constructive critique in one team may be a overtly unwelcome criticism in another.

To top all of that off, there are then different paradigms - OOP, procedural, functional, etc... And some programmers completely disagree on these paradigms. For example, SOLID principles were developed specifically for OOP design, but anti-OOP programmers believe that OOP is usually a bad idea, avoid OOP, and since SOLID are OOP principles, they aren't relevant to those programmers, and so on.

In this type of environment, I've found getting actual constructive feedback to be challenging at times - what is "better" versus "different" is a theme that I've happened upon more than once. One person says "you should write this function like X for reason Y" and another says "actually, it should be written like A for reason B." Ultimately, it's up to each individual programmer and in the case of work, the company/team to decide on style guidelines, but nevertheless, it's certainly a jungle out there.

It would be interesting to hear others' experience with this.

Gaponenko Andrei's photo

Very true. Reminded me of Parkinson's law of triviality, which is

an observation about the human tendency to devote a great deal of time to unimportant details while crucial matters go unattended.

I have experience working with highly opinionated people, was one of those myself actually. Almost every code review was a passionate discussion, mostly about trivial things, not always though.

Then I also have recent experience working with people who don't care at all about how X should be done as long as it's working and doesn't look like complete piece of crap. Actually scratch that, most of the project was written like there is no tomorrow.

Nowadays it's somewhere in the middle, which I think is actually a great place to be. Trying to make a uniform code style for a team is a good effort, nothing wrong with that. Giving suggestions about why X should be done as Y (e.g. it's easier to read or less error prone) is fine.

But I think one should always remember that the code we write as stable and long lasting as a fictional sitcom family. Or enriched uranium. Being too opinionated, to the point where only your opinion is the answer, is very stressful for everyone involved, even the person himself.

Francisco Quintero's photo

Software Engineer & Ruby on Rails Developer

Parkinson's law reminds me of Bikeshedding. Arguing unimportant stuff because it's easier.

Francisco Quintero's photo

Very interesting read here, Todd.

I recall when I was studying the teacher who taught me algorithms said that there are multiple ways to solve a problem. That's a programming truth. In the end, we just choose a style we feel comfortable with or that help us deliver.

As Gaponenko Andrei said in his comment, it's ok to have standards agreed upon, giving suggestions to improve but never getting married with an idea of how something should be done. It won't be helpful in the long term.

There's no point in chasing perfect code when the project might just be an MVP lasting 3 months 😆