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.
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.
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.
10 comments
[ 52.2 ms ] story [ 131 ms ] threadAnd-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.
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.
Simplicity is more to do with following a consistent mental model and not mixing levels of abstraction.
* Avoid magic, be idiomatic.
* If you create something even slightly non-trivial, explain it in documentation.