If you take up a new art form, even if you fail to become extremely proficient, you may notice a change in how you perceive the world. I am not a particularly adept photographer, but I’ve spent enough time learning to understand the medium that it has affected my vision: I see light and shadow and geometry now in a way different from how I saw them before.
So perhaps the only way to truly understand how a programmer feels when she programs is to become one, attempting a serious enough project that the practice of programming alters the way your mind and perceptions work.
Of course, no one has the time to pursue every craft, so I’ll try to explain what programming feels like to me. If it sounds attractive, you should try it yourself. Otherwise, perhaps you can take up the piano. I’ve always meant to and never had the time.
Programmers, like athletes, sometimes speak of being “in the zone.” This time usually occurs after several hours of uninterrupted work on a single problem.
To me, it is a feeling of suspension: as if your mind is inside of (or part of) a complex mobile, with dozens or hundreds of moving parts, and yet you can feel inter-relationships of the pieces and how they move and affect each other.
As you proceed in your task, these pieces become more fixed in your mind, as if they are locked down into place. The number of degrees of freedom becomes fewer, and the work generally goes more rapidly. Unfortunately, while this state of mind can cause you to feel a great degree of certainty, sometimes it is unwarranted, and you find that you have made a mistake.
A piece you have placed early in the game is not right, so that something else can’t fit. This error may have happened earlier in the day, or years before. It might have been made by you, or maybe someone else. Now you are stuck, and panic can set in. The reason is that there are only three ways out.
One way is to tear up a substantial amount of work, causing ripples throughout the system. Suddenly, everything has moved from careful order to chaos, and you must re-establish all the necessary connections and implications in your mind. The chance of causing serious errors in the program is high. But if you redo the work well, the system will be more flexible and more correct.
The second way is to create a hack. A hack is an aesthetically displeasing piece of code: something that you had to shoehorn in to make the system work, but which lacks generality or elegance. Perhaps it depends on shaky assumptions. Perhaps it is just overly complicated and weird.
Finally, sometimes you can escape the trap by being clever. Perhaps the requirement can be finessed in some completely different way. This requires creativity, lateral thinking, and luck. Unfortunately, this mode of thinking is difficult when you are in the throes of highly concentrated thought that most code requires. If you want to escape this way, it’s best to go home and sleep on it, or at least take a quick walk.
Since the second method is ugly, and the third is chancey, programmers have tried to think of ways to make the first more tractable. This is where the art and craft of programming come closest to the discipline of engineering: if you have test frameworks and type systems and re-factoring tools, tearing up the floorboards of your programmatic house is much less scary. If you have these things, even major reshaping of code can feel less like a home renovation, and more like molding clay (or perhaps beating metal into shape —- some structures are still rigid).
A few final observations.
While in the zone, programmers are very good at making complex things. In a sense, they can be too good. Later on, when that programmer (or, worse, another) returns to the code, they can find that their deep understanding of the complexities and dependencies is gone, and it can be very hard to recover it. They will fear to change it, and instead add hacks to the system (failing a clever insight). When coding, try to remember that someone, maybe you, will have to understand what you’re doing in the future, and that your clear vision of the system will be gone by then. Write tests, add documentation, and simplify. This will seem unncessary when in the midst of a creative burst, but it will help.
[ A really good feeling is when you come back to an old piece of code, and it’s easy to change it because you designed it well. ]
The state of mind that leads to powerful code is difficult to establish. It can take hours of sustained work to get into it. It is very easy to break. Do not distract a programmer needlessly. Signals like a closed office door or a pair of headphones are the programmer’s quiet way of asking you not to carelessly erase hours of effort. (This is also, incidentally, why programmers often work long and non-standard hours.)
Finally, a good deal has been written on the subject. Some favorites of mine:
http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm