The world is moving at such a high pace, it might feel like we can’t keep up unless we go faster and faster. The quote above from programmer Jeffrey Ventrella is a reminder that slow and steady wins the race.
Ventrella is making the case for programming slowly, but this can be applied to just about any endeavour:
The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia — whereby my coding rhythm got aliased out of existence by the pummelling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.
And sometimes, after a mature organism has emerged, I go back and start over, because I think I have a better idea of how to do it. Sometimes I’m wrong. Sometimes I’m right. There is no way to really know until the organism is fully formed and staring me in the face.
Anyway, back to the cauldron-soup-programmers. The problem is this: with no stasis in the overall software ecosystem — no pools of stillness within which to gain traction and apply design process, how can anyone, even a fast coder, do good design?
By going slow and exploring along the way, you build a better product (and can also avoid costly and time-consuming redos later). It’s not just good design that takes time, but also good idea generation and other kinds of mental activities.
The Case for Slow Programming [Nature…Brain…Language…Technology…Design]