Wednesday, August 1, 2007
Refactored Thinking
Programmers are comfortable with clarifications. These clarifications occur in three varieties: hacks, optimizations, and refactoring.
If the specification of a task changes after the programmer has already completed the programming for the task, there are times when adapting to this change can be done without starting the task. Programmers can add a feature to existing code without reworking the overall structure. Programmers refer to this kind of "enhancement" as a "hack." Programmers who frequently find themselves performing this kind of enhancement may call themselves hackers.
On the other hand, sometimes once the work has been completed, the programmer will decide that the program is inefficient in some important way. It requires too much memory, too many CPU cycles, too much input and output. In this case, the programmer may decide to optimize the program by implementing some subsets of the feature set using an algorithm that
requires fewer calculations or less memory. This kind of optimization can sometimes also be a hack, but programmers who do it probably just think of themselves as smart, rather than hackers.
Last, but not least, as programmers iteratively change an existing piece of code- hacking in new features and optimzing existing ones- the program may become more complicated. If this process continues too long, or occurs too frequently, the program may become illegible for humans. There may be inadvertent side-effects to the hacking. Programmers call these inadvertent side-effects bugs. Worst of all, the programmer may simply have decided that a given program started out illegible (probably written by a coworker), and decide to "fix" it.
When these eventualities occur, the programmer "refactors" the program. Refactoring programs is great fun. It involves deleting unnecessary parts, rewriting unclear parts, re-organzing everything, and presenting it to the world as Version 2.0.
It is my fondest hope that I am able to refactor my thinking much as I do with programs. As new ideas come, they may be hacked on. Old ideas may be clarified and updated. And the entirety may occasionally undergo a significant refactoring, resulting in a more elegant, coherent, and presentable whole.
This is my apologia. If you notice some content here has changed, arbitrarily and capriciously, it's been refactored. If you liked the way it read before the refactoring, I tend to keep the older versions around. I also tend to think that the older versions aren't as good, so you'll need a pretty good reason to get me to cough one up. On the other hand, if Google's cache or Archive.org keep one around, have at it.
If the specification of a task changes after the programmer has already completed the programming for the task, there are times when adapting to this change can be done without starting the task. Programmers can add a feature to existing code without reworking the overall structure. Programmers refer to this kind of "enhancement" as a "hack." Programmers who frequently find themselves performing this kind of enhancement may call themselves hackers.
On the other hand, sometimes once the work has been completed, the programmer will decide that the program is inefficient in some important way. It requires too much memory, too many CPU cycles, too much input and output. In this case, the programmer may decide to optimize the program by implementing some subsets of the feature set using an algorithm that
requires fewer calculations or less memory. This kind of optimization can sometimes also be a hack, but programmers who do it probably just think of themselves as smart, rather than hackers.
Last, but not least, as programmers iteratively change an existing piece of code- hacking in new features and optimzing existing ones- the program may become more complicated. If this process continues too long, or occurs too frequently, the program may become illegible for humans. There may be inadvertent side-effects to the hacking. Programmers call these inadvertent side-effects bugs. Worst of all, the programmer may simply have decided that a given program started out illegible (probably written by a coworker), and decide to "fix" it.
When these eventualities occur, the programmer "refactors" the program. Refactoring programs is great fun. It involves deleting unnecessary parts, rewriting unclear parts, re-organzing everything, and presenting it to the world as Version 2.0.
It is my fondest hope that I am able to refactor my thinking much as I do with programs. As new ideas come, they may be hacked on. Old ideas may be clarified and updated. And the entirety may occasionally undergo a significant refactoring, resulting in a more elegant, coherent, and presentable whole.
This is my apologia. If you notice some content here has changed, arbitrarily and capriciously, it's been refactored. If you liked the way it read before the refactoring, I tend to keep the older versions around. I also tend to think that the older versions aren't as good, so you'll need a pretty good reason to get me to cough one up. On the other hand, if Google's cache or Archive.org keep one around, have at it.
// posted by David @ 4:52 PM 
Subscribe to Posts [Atom]