Eliot Miranda Eliot Miranda, Author of the Cog and BrouHaHa Smalltalk VMs. Ex tech lead for VisualWorks Smalltalk ('99 - '06). Updated Dec 6
I’m not qualified to answer this question; I’m a very experienced and quite strong programmer but I’ve not studied the development and maintenance of large programs, I’ve not managed teams, and I’ve not invented a programming methodology. That said, my experience tells me that the following (none of which are mine) are the rules to live by
When possible, use a simple approach. Adapting Einstein, programs should be as simple as possible, but no simpler. In the absence of perfect optimizers this principle may have to be violated if one is producing a system whose performance is critical and which is run many more times than it is written (such as in an optimizer).
If you can combine the first two steps into one, do so. If you can do all three you’re either exceptional or not challenging yourself…and be aware of Dunning-Krueger. #Write tests. If you don’t write tests you have no way of changing a program that is in any way underspecified or underdocumented. Tests are the best way I know of specifying and checking correctness. If you want your program to evolve you will need tests. #Before you optimise, measure. There is no point optimizing the parts of your program that don’t take any time. Your intuitions as to where the time goes may be ill informed (the program behaves unexpectedly), and invalidated by differences in underlying processors or broader context, and will be confounded by future developments.
You may think you understand the program from its text because it is beautifully written. The person in the next office may not understand it. And in six months you won’t understand it either. No matter what the intention-revealing selectors crowd says, an undocumented program is an unexploded bomb.
As Greenspun’s famous tenth law states, “Any sufficiently complicated Cor Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”. So if you need to use metadata or interpretation or generate code on the fly, structure the program accordingly; don’t try and cram everything in at the same computational level. Biological and cognitive systems are hierarchical; Friston’s Free Energy Principle derives from the animate world being composed of hierarchically nested Markov blankets. Complex computational systems should be structured this way also. Complex programs are not flat.
Refine, refactor, rewrite, replace, reduce, reuse (responsibly with recognition and realization of the rip-off you’re relying on).
Lots of things are fun and safe to do alone, but like music, programming is often more enjoyable when done collectively, and the scope of the piece is greater with more participants. Like scuba diving, programming in a demanding or potentially dangerous environment is simply too dangerous to undertake solo. Key is that two minds (or more, up to very small N) are better than one. Programming with another, whether pairing or by sharing, will produce better solutions and more readable code, will force you to explain your ideas as you go, will be more considered, will be better. Programming is like sex; masturbation is fun, but copulation is /much/ more fun and the results can be spectacular.
Know why you’re doing something, as well as what and where. This is hierarchical. “Why” is closely related, somewhat or entirely overlapping with where you’re going. Situational awareness is key to good time estimates. If you have to deliver you have to know the why, what, where and at least an initial inkling of how you’re going to do something.
You will forget. Notes can be garbage collected, but the forgotten can only be recalled, or worse recreated, at great expense. Closely related is the fact that notes, and good documentation, record one’s assumptions at some time which will soon become the distant, dimly-recollected past, and assumptions soon become invalid. Knowing what you were thinking at the time is really important knowledge when you want to change something to adapt to new circumstances. An unanswered “why on earth did I do that?” can gnaw at your soul.
See the previous point “take notes”. Apply the documentation and note taking principles to your commit comments, and for the same reasons.
Mistakes are much more expensive than the unmistaken. You are mortal. Stay hydrated, eat protein, and don’t rely on stimulants. I once programmed late into the night, convinced that each change I made was making things faster, but the light of day and objective measurement demonstrated they weren’t. It was simply that as I tired my program appeared to be going faster. Not taking care of yourself is a slippery slope; you can lose your fingers. I once interviewed with a senior and prolific developer at Microsoft whose works were amongst Microsoft’s most important products, and who had worked so hard his health had been damaged (think writing a JavaScript interpreter in your spare time while writing the company’s C++ compiler). At his doctor’s behest he took up a hobby, chose carpentry, and lost two fingers from his right hand to the circular saw he bought to prosecute his hobby. Besides, your subconscious is a better programmer than your conscious mind will ever be. You will come up with better solutions in your sleep which will come to your attention in the warm amniotic environment of your shower. So give yourself a break and get plenty of sleep.
This manifests in the oft recorded exchange: how on earth did you manage to write that?!?! Because I didn’t know it was hard. c.f. make it run, make it right, make it fast. Incremental development is key to being able to evolve your ideas, and being free of crappy error messages, inflexible type systems, verbose languages and long compile and link times are key to solving challenging problems. You won’t be able to keep the entire solution in your head; you’ll need to explore, and if the terrain is difficult to traverse you’ll make slow and dispiriting progress, hence my final golden rule…
Enjoy!