11. Rewrite something that desperately needs to be rewritten.
So many times I've encountered something and thought, "I can't believe that people are actually expected to use this software."
It was bad from a user perspective: difficult to use, slow, tedious to do what you actually needed to do, unable to "get there from here".
Then once I looked under the hood, it was often worse: built upon a horribly designed data structure, inflexible with constants where there should have been parameters, no apparent thought put into its use, too many violations of acceptable practice to mention, looking as if it evolved haphazardly (which it probably did).
It's easy to bitch about stuff like this, but you often have to go to the next level to do something about it. It's amazing how much rethinking you have to do and how many tools you have to build to turn horrible software into what should have "obviously" been done in the first place.
Easier said than done. And often, some of my best learning experiences.
Rewriting something is most definitely a good way to learn that a) rewrites are easy to underestimate, and often not such a good idea as they seem, and b) the previous programmer may not be such an idiot as you first thought.
Understanding the thinking behind other peoples code (yes, even crap code) is one of the hardest programming skills to acquire.
This is something that took a lot of mistakes to learn for me. Replace only the code that's definitely wrong, and resist the urge to start over. Whenever I see a project announce that they're going to rewrite the next version, I know I'll never see it.
Instead of rewriting something, you should really refactor it until it is beautiful. Unless the original author was really stupid, you are bound to go through all the same errors and dead-ends the original author went through on his first try.
So many times I've encountered something and thought, "I can't believe that people are actually expected to use this software."
It was bad from a user perspective: difficult to use, slow, tedious to do what you actually needed to do, unable to "get there from here".
Then once I looked under the hood, it was often worse: built upon a horribly designed data structure, inflexible with constants where there should have been parameters, no apparent thought put into its use, too many violations of acceptable practice to mention, looking as if it evolved haphazardly (which it probably did).
It's easy to bitch about stuff like this, but you often have to go to the next level to do something about it. It's amazing how much rethinking you have to do and how many tools you have to build to turn horrible software into what should have "obviously" been done in the first place.
Easier said than done. And often, some of my best learning experiences.