Job Security Through Code Obscurity
seven-degrees-of-freedom.blogspot.com
seven-degrees-of-freedom.blogspot.com
(And I can say this because I've written asinine, passive-aggressive blog posts to boost the ego myself)
Ugh. That's the one I'm continually running across. Inheritance is so heavily abused by novice programmers they shouldn't be allowed to use it without a twenty page written justification.
It's a corollary from the idea that if you think you just wrote something really clever, you probably just wrote an unmaintainable mess that no-one else will really understand and will haunt you for a long time.
It's kinda one of those unsaid assumptions that everyone suddenly knew and yet no-one's really vocalised. Apart from maybe Yegge, I have a vague recollection that one of his articles touched on it.
It's hugely important in console game programming to know exactly how you're using the system's resources - memory and clock cycles. The styles he's criticizing aren't just bad for limiting resource usage, they're hard to analyze. On top of that, it can be very difficult to silo components of game code (and game engines) behind nice clean interfaces. When you're the engine programmer tasked with optimizing game code because you're the one who knows how to squeeze performance out of the console, you don't want to have to climb up and down hierarchies to figure out where everything's hidden. I've been there - it's especially prominent in 3rd party developers with cross-platform game engines - and it's a nightmare.