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),
if(something)
return case1;
//stuff
return case2;
vs.
if(something)
some_var = case1;
else
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.