light at the end of the tunnel

And then I started working in the game industry. Here I found 5 types of programmers.

• The bad programmers: This was the old breed, and slowly dying, that simply wrote shitty code, period. If you're lucky, it did JUST the thing that it was intended to do, for 80% of the cases. If you needed to have the other 20% working, or if you wanted to add a new feature to the existing code base you couldn't. The whole thing needed to be rewritten from scratch.
• The super programmers: Those were the guys of the old-school philosophy, who wrote huge amounts of code, that nobody could touch or try to understand. The code was poorly written, with tons of messy dependencies, and yet it did a lot of useful things, and people were afraid to touch it, for fear of causing the collapse of the card house. In many ways, they were similar to the guys in the "bad programmers" category, except that they wrote a LOT of bad code. In fact they wrote so much of it, that it couldn't all be rewritten. Those giants were people the company couldn't live without. And yet when one of those guys left, somebody had to step in and do it right.
• The cleaners: This was another category of super-programmers who were good at cleaning up the mess created by other programmers, regardless of how poorly it was written. 
• The well-intentioned programmers: These guys seemed to care about software engineering principles, correct design, design patterns, refactoring, and other such concepts, upon which the academians looked down. Occasionally they would even get around to it. Unfortunately, in practice that idea slipped, since under the time pressure of deadlines people often reverted to their evil old ways and forgot about nice structure, readability, maintenance, and sharing. 
• The good programmers: finally there was the select few who could do the impossible: write a lot of code, write it well, so no cleanup was necessary. Anyone coming in after these guys would breathe a sigh of relief over how easy it was to understand their code and add features to it. Or maybe their successors wouldn't even appreciate this fact, nevertheless their job in fixing bugs or adding features would be much easier on this clean code base. 

Of course I wanted to be in the last category, and found myself more in the next-to-last. I was armed with knowledge of design patterns and other cool goodies. Unfortunately, many of the books written about software engineering and proper code design had one fatal flaw. They assumed a top-down approach where proper design preceded implementation, and the textbook-clean examples lead you by the hand towards the right solution. It was akin to doing exercises from a chess book in the flavor of "checkmate in 2, black starts". You know the solution exists, and you know it's a clean one, and you know it won't take too long to figure it out. 

In the real world, you have to play the real chess game, and work with real code, that wasn't necessarily written with you or your features in mind. In the real world, the design patterns aren't handed down to you from a textbook, and instead have to be arrived at from the bottom-up. You have to take code from an arbitrary state A to a final state Z, where

A = typically a mess of some sort, which does some of the things you want right, some of them wrong, and some of them not at all

Z = a functionining application with bugs from A fixed, some new desired features, and (as a side benefit) something which is also easy to maintain for the next guy

So let the journey begin.