3 ms·

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 rese

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 9y ago
> 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.