Changing the unseen makes it easier to improve the visible.
Software development can follow many paths, but a relatively common one goes as follows:
Try to figure out everything the software will ever be asked to do.
Design how information will flow through the software to enable all of those things.
Explain to the computer what you want it to do.
Ask it to do what you told it, notice you explained it wrong, and fix the explanations.
As you go through the above steps, you start to learn things are not going as well as you’d like. The process of explaining things to computers includes defining new terms for the explanation to use. But sometimes you realize you didn’t pick those terms very wisely and each new thing you explain gets longer and more convoluted as you labor to use the vocabulary in less and less fitting ways.
When that happens, you refactor:
Pause and rethink the design, looking for a different way that will work out better.
Add the components needed for the new design, ensuring nothing else is changed.
Replace old complicated explanations with new simpler explanations using the new components, ensuring the end results are the same.
Resume the previous work, which is hopefully now much easier.
There are two facts that make refactoring important. First, the ability to increase what a program does is limited by how it is designed. Second, it is hard to get the design right before you see how it is working and experience the limits of the design.
Some personal growth is accomplished by learning. I learn to understand others, learn to do things I couldn’t previously do, learn to see more of the truth and be less distracted by the surface.
How rapidly I can learn things is limited by how my mindset is organized. I am hindered in learning from some because my mind dismisses them as having nothing to teach. I find learning some skills hard because my self image does not identify them as suitable. Sometimes I am so distracted by worry or trivialities that I fail to engage fully in the next opportunity for growth.
But that internal organization is not fixed. I can change my views to see the merits of those I previously dismissed, can change my self image and restructure my reaction to distractions. This is hard work, and at time frustrating for in it I find but little reward. Getting up and retiring earlier results in more tiredness than vigor while I am restructuring my schedule, no matter how confident I am that in the long run it will enable additional good habits and learning.
In other words, sometimes my future personal growth is streamlined by a period of refactoring which has no short-term gain but enables long-term improvement.
Many large, long-running software projects become larger and less effective than they might otherwise be because it is hard to prioritize refactoring time when it does not make visible progress toward the project’s goals. As a consequence, I’ve heard some developers discuss imposing a “refactoring tax”, a surcharge on every bit of progress to be used in refactoring.
I’ve learned the value of adding a refactoring tax to my personal life too. Some time I invest in learning and doing, the growth that pays off; and some I invest in changing and becoming, the harder growth that makes the more visible growth feasible.
Sometimes I notice I’ve stopped investing in changing my character, often by noticing that I’m finding learning and doing becoming more tedious and less effective. When that happens, I’ve learned over the years that when I notice that I have weeks or months of personal refactoring ahead of me, and that if I put it off it will take even longer. But I’ve also learned that it will pay off: I can become more meek, more calm, more open, more attentive, more diligent, or whatever it may be. And once I do, life will become a pleasant path of personal growth once again.