Perceptions of Code Quality | Hacker News Reader

Perceptions of Code Quality

qaware.blogspot.com

44 pointss-macke10 comments

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.

Not sure why you are downvoted. Must be all the newbies.

I didn't fight club, but I'd guess it was due to the confusion between simplicity and performance.

Simplicity is more to do with following a consistent mental model and not mixing levels of abstraction.

Simplicity definitely has something to do with fewer instructions. To get there, you use the right level of abstraction in which to express those instructions.

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

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.

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.

I'd boil it down to two statements.

* Avoid magic, be idiomatic.

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

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.

> 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.

Reply on news.ycombinator.com