In Handbook For Preclears*, L. Ron Hubbard writes:
Man is successful. That is evident because he is here today after eons of trial and error, good and bad planning. And he is successful because he can change.
Now, you really should read that whole chapter (Chapter One in the book) for the complete context of the quote. It’s actually quite a beautiful and inspiring chapter–well worth reading. But that quote is enough for what I want to talk about today.
What do our software systems do? They change. The environment changes, requirements change–things change. It’s our ability to change our software effectively that largely determines whether we are good or bad programmers. It’s not our ability to construct a system that “works”–although that’s certainly important. No, what distinguishes the great programmer from the mediocre programmer is that the great programmer writes systems that can be changed.
Granted, just being able to construct a working system can be quite a challenge! When you’re a brand-new programmer, that’s what takes up most of the time–learning the language, figuring out how to do things, just making things work. That’s completely understandable if you’re a new programmer, or if you’re new to some language or technology. But once you’ve got a handle on that, it should quickly (or slowly) become apparent that there’s going to be a future to your code, and that means that you’re going to be changing it. If you didn’t plan for change, that’s going to be tough.
What do I mean by “plan for change?” Well, just have the idea, when you’re writing the code, “this might have to change some day,” and think, “what would keep this flexible, while still keeping it simple?” Sometimes that takes learning more about software design, but it’s always well worth it. The more you program, the better you’ll get at it. Just have “changeability” as a goal, and as you become a better and better programmer, your code will become easier and easier to change. It only becomes a problem if you never even care about it, and just spend the rest of your days as a programmer building spaghetti code that “works” but can never be fixed or changed when needed.
And as a note very related to this, never let anybody tell you, “If you’re not coding, you’re not working!” No! Planning, designing, refactoring, and even a bit of scribbling thoughts on paper are all extremely valuable uses of your time, and should not be neglected. Those are a large part of what help you cope with change. Programming isn’t all typing–it’s a bit of observing, thinking, and talking, too.