4 min read
You might have heard that, here at TimeXtender, we are educated in and practice Franklin Covey’s 7 Habits of Highly Effective People. It’s part of our company’s core foundation and has permeated through many areas of our organization.
As a developer at TimeXtender, this got me thinking, ‘Can Covey’s habits be applied to programming as well?’. They say that great programmers are lazy, but some very bad programmers are lazy too. What makes the difference between these two groups—besides a curious mind, fresh ideas, the reluctance to repeat identical tasks over and over and the willingness to automate these tasks? The answer is habits.
Habit 1: Be More Eager to Reuse Past Work
"Paradigms are powerful because they create the lens through which we see the world... If you want small changes in your life, work on your attitude. But if you want big and primary changes, work on your paradigm."- Dr. Stephen R. Covey
Dr. Covey is right. We’ve heard about procedural and object-oriented paradigms, but do we really work on them, like Dr. Covey suggests? Do we apply them every time when needed?
The procedural paradigm teaches us to separate code into procedures that can be reused. The object-oriented paradigm speaks on separating code into classes and methods that can be reused even more.
Do not copy code. Move it to a class or a procedure and reuse every piece of code you have made, or your colleagues have made. If it is not perfect, improve (or refactor) the existing code instead of making a better copy.
Every piece of logic should be implemented only once and reused when needed. Why? You think copying code is easier? Maybe now, in this moment, but not in the future. In the future, when you modify the code you will have to do it twice, three or five times, depending on how many times you copied. Another modification means doing it many times again. It gets worse when the copies become modified in a different fashion over time and forgotten along the way. It will get more and more difficult to find all the copies and determine if they still perform the same logic. Like Dr. Covey has said, remember programming paradigms.
I admit, I copied code a few times. Well, many times, actually. But not anymore! I have changed and became a better man once I adopted Habit 1 as my own.
Habit 2: Program with the End in Mind
" Your most important work is always ahead of you, never behind you." - Dr. Stephen R. Covey
Again, Dr. Covey has just nailed it. When you program, always think of the future ahead of you when you are going to modify the code and perfect it. Don’t think that the code is done and already in the past. Will you still understand it after 3 months without any effort, once you have forgotten all about it? Will your colleagues understand it? Make it easier for them—and for yourself—by putting an extra comment here and there on why you have written the code, if it is not an obvious logic. Write only the purpose, not what the code does. 
And don’t only focus on readability in your comments. Try to name properties, methods, and classes in a way that is easy to understand and hard to confuse. Avoid e.g. “x”, “f” as names because such names have no meaning.
The code should also be as short and as compact as possible; isn’t it easier to read a shorter blog than a lengthy, dense blog? However, don’t make it too compact at the expense of understanding. Code understandability is as important as what the code does.
I admit, I too used compact code constructions that were sometimes difficult to read, and my colleagues asked me to refactor. But I listened. I changed them—the code, not the colleagues—and I don’t do it any longer.
Habit 3: Optimize Algorithms First
"Putting first things first means organizing and executing around your most important priorities." - Dr. Stephen R. Covey
Exactly like Dr. Covey suggests; use your energy to optimize algorithms before optimizing the code that implements them. If you have a loop that repeats 100 times and inside it you have another loop that repeats 100 times, and you make the code inside both loops twice as fast—e.g. 1 millisecond instead of 2 milliseconds—your entire program will speed up from 20 seconds to only 10 seconds (100*100*1ms). This is a great improvement. But what if you optimized the entire algorithm so that it wouldn’t need the second loop at all, despite still having the slower code inside the first loop?
Improving algorithms has the potential to do that! Well, let’s calculate. 100 times 2 milliseconds make only 200 milliseconds, which is much less than the initial 20 or even the improved 10 seconds. Your program would be lightning fast!
Always think of how many times a given logic is repeated and if it could be executed fewer times, before you think if the repeated logic could be made faster. Nested loops are not always easy to spot if the code is complex and the call stack is deep. Always be aware of nested loops, as all the trouble lies within them.
On the other hand, if a similar logic is executed only a single time, and you speed it up from 2 to 1 millisecond, nobody would ever notice. So, don’t bother. But even the least perceptive and least grateful users will notice an improvement from 20 seconds to 200 milliseconds if you manage to catch their attention.
What We Have Learned
I have offered 3 habits of highly effective programmers, which I have compiled from my years of experience and observation in this field. They may not be obvious to everybody, and for some people they may be too obvious, but it doesn’t change the fact that the habits work well in the long run.
The world is vast and there is always enough room in it for improvement. Even though Dr. Covey probably didn’t include himself in any group of programmers I mentioned, I believe that he would agree with that statement more than anybody.