
Perceptions of Code Quality - s-macke
http://qaware.blogspot.com/2017/12/i-know-it-when-i-see-it-perceptions-of.html
======
austincheney
In my experience coming from a multi-paradigm background the difference is
experience writing code. A newb tends to argue about things like tabs versus
spaces, latest trends, and easiest abstractions. Rockstars don’t care about
any of that and instead focus on performance, predictability, and simplicity.

This can cause a fair amount of friction as simplicity isn’t easy and newbs
cannot differentiate those terms. Simplicity is the fewest instructions to
perform a task, which often means fewer conventions and rituals in the code.

~~~
vlaaad
You mistake simplicity for performance. Simplicity is about lack of
interleaving of abstractions, it's about one concept, one task, one role,
single responsibility etc. I recommend Rich Hickey's talk "Simple made easy"
for that matter: [https://www.infoq.com/presentations/Simple-Made-
Easy](https://www.infoq.com/presentations/Simple-Made-Easy)

~~~
austincheney
Performance is faster execution and lower resource consumption. Perhaps this
isn’t so much a factor anymore with low level languages, but in high level
languages with several layers of abstractions and giant frameworks there are
huge opportunities for writing faster code.

------
cdevs
I've noticed a disconnect between people we bring on the team that have a
heavy oop style or do brilliant things in low level code but they lack writing
code for teams fresh out of college. I remember writing magic code that did
convenient abstractions for me in the background when I programmed for myself
but I quickly learned this sucks when I found out someone provided me with a
function that doesn't follow single responsibility in a team environment. When
you work in a team write for a team, I tell everyone to write for a imaginary
jr developer starting the next day who's going to read your code on day one.

~~~
nine_k
I'd boil it down to two statements.

* Avoid magic, be idiomatic.

* If you create something even slightly non-trivial, explain it in documentation.

------
nicolashahn
Interesting that for students and devs, colleagues were the best meter for
code quality, but academics ranked textbooks higher. Mirrors what I've seen as
a research assistant for the CS department of my university, which is roughly
"I don't care what the code looks like as long as it works". At places in the
industry I've worked, I've spent a significant amount of time arguing about
the "right" way to do things. And some (not most) of the time they'll have
almost no effect on performance, functionality, or end-user impact at all, but
we still do it.

~~~
dualogy
> _And some (not most) of the time they 'll have almost no effect on
> performance, functionality, or end-user impact at all, but we still do it._

And-that's-okay --- the effect isn't on today's but tomorrow's: performance,
functionality, _and_ end-user impact. As long as a business/org is developing
stuff that's "here to stay" \--- in-house solutions or software products with
a life-time expected beyond a 0$-mobile-app's 15 weeks-to-months of fame in
the best case --- it will or should be _hugely_ motivated to learn from what
you and others have to say in the "code quality" department. If only to avoid
twice-a-decade whole-system-rewrite pains & costs.

