In job interviews, when asked about my greatest weakness, my answer is usually that I am possibly too much of a hands on guy; I like to have something concrete up and running quickly and go from there. It is of course a typical interview answer, as it can be considered both a weakness and a strength. Today I was pondering the quote below by Alexis Carrel:
Man cannot remake himself without suffering, for he is both the marble and the sculptor.
— Alexis Carrell
There are a lot of developers who need to have every line of code neat and elegant from the beginning. Like fearing that an errant brush stroke will ruin a painting, they obsess over each line. For lack of better term, I call them code painters. I am the complete opposite of a code painter: I fear the chains that mode of working puts on me. I want to bridge the gap between the implementation detail and the large scale vision quickly. In my vision, software is developed in these steps:
- Something that roughly works
- Something that works fast enough
- Something elegant that works fast enough
In a world of hectic deadlines I usually have something good enough up and running pretty quickly and clients certainly value that. But there’s a danger that for whatever reason, I get stuck in a loop of steps 1 and 2 and when I get around to the elegant part, there’s quite a lot of baggage to shed — a lot of suffering,. I guess I would describe myself as a code sculptor. I view the third step as chipping off unnecessary bits of stone from a rough block of code.
I suspect why I love the microservices architecture is because it is the architecture style where you can take a block of stone — a monolith — and sculpt from it what you will, revealing the elegance inherent in that block. The services that emerge are like features of a statue.
Incidentally this focus on quantity over quality seems to be supported by experiments from (appropriately to this topic) the field of art. In their book Art & Fear, David Bayles and Ted Orland report an experiment they performed on some students of clay pottery. The teacher split the group of students into two groups, one which was graded based on the amount of work they produced, while the other half was graded on the quality. The results may seem counter-intuitive at first.
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
After a little thought, the reason becomes clear, however. By focusing on quantity, you get multiple times the practice that you get from obsessing over trying to get it right on the first go. You can go over several iterations, arrive at the best solution and throw away the baggage at the same time as the pedantic takes to arrive at their first pass. Which surely will be more beautiful than your first pass was, but is rarely more elegant than your final solution.