Programming: doing it more vs doing it better

A few years ago, very early into my programming career, I came across a story:

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.

Jeff Atwood’s “Quantity Always Trumps Quality” post, though he himself took the story from somewhere else.

This little story has had a tremendous impact on how I approach software engineering as a craft. I was (and still am) convinced that the best way to get better at software engineering is to write more software. I was careful enough to not take the story too seriously – I have always strived to write readable, maintainable code without bugs. However, deep inside my mind was this idea that one day I would be able to write beautiful code without thinking. It would be as effortless to me as breathing. “Refactoring code” would be something left to the apprentice, not something that I, the master who has churned out enough ceramic pots, would be bothered with. I just have to keep making ceramic pots until I get there.

Three years later, I am still very much the apprentice. Rather than programming effortlessly, I have learned to program more deliberately. I have learned (the hard way) to review my code more thoroughly and to refactor it now rather than later. I get pangs of guilt and disappointment every time my pull request has to go through another round of review. I am frustrated when I deliver a feature two days late. As an engineer I want to, above everything else, churn out (the right) features as fast as possible.

Today, I came across an essay that would let me resign from my perpetual struggle to “get faster” at engineering:

I used to have students who bragged to me about how fast they wrote their papers. I would tell them that the great German novelist Thomas Mann said that a writer is someone for whom writing is more difficult than it is for other people. The best writers write much more slowly than everyone else, and the better they are, the slower they write. James Joyce wrote Ulysses, the greatest novel of the 20th century, at the rate of about a hundred words a day

William Deresiewicz, Solitude and Leadership

I can strongly relate to this – I would often read and re-read something that I wrote and then I would go back and change it, only to repeat the process again. Though comparing my modest penmanship (keymanship?!) to “the best writers” is outright sacrilegious, even I have in the past noticed that the slower I write, the better I write.

The equivalent in software engineering terms would be to (nothing you did not know before, except for maybe the last point):

  1. Put more thought into the design of your systems
  2. Refactor liberally and lavishly
  3. Test thoroughly
  4. Take your sweet time

As I said, nothing you did not know before. Also, this is almost impossible to pull off when you have realistic business objectives to meet.

But James Joyce probably did not write Ulysses with a publisher breathing down his neck saying “We need to ship this before Christmas!”.

So the secret sauce that makes good code great and the average Joe the next 10x programmer might be this – diligence exercised over a long time.

How does this affect me? Disillusionment. Writing more software does not automatically make you a better programmer. You need the secret sauce, whatever that might be.

10 thoughts on “Programming: doing it more vs doing it better”

  1. One thing I always get confused when thinking and refactoring stuff for the better is how my git history will look like. I always try to keep it understandable and easy to rollback. Tips are appreciated!


    1. Something we started doing at my previous employer was to commit without giving a thought and then squash/amend commits [] before opening a PR. If you are talking about a refactor done months later, then I see no problem in having a single “refactor” commit.


  2. > But James Joyce probably did not write Ulysses with a publisher breathing down his neck saying “We need to ship this before Christmas!”.

    Perhaps not, but Dicken’s _A Christmas Carol_ certainly did. And he basically died a millionaire. If you think writers don’t act under time pressures, you are sadly mistaken.

    Liked by 1 person

    1. Well, yeah, but Dickens was kind of a special case — he wrote *huge* amounts of text (look at how much he produced!) and frankly, most of it wasn’t very good. No one ever compares him to James Joyce. He was writing in the era when you were paid by the word, and so he optimized that pretty well. So even though he was (and is) probably more popular than Joyce, none of his other Christmas books is remembered today (did you know he tried a number of times to strike gold the way “A Christmas Carol” did?) even though he churned them out by the bucket-full.


  3. Nice article and great quotes. I relate to your experience.

    And luckily I still feel I’m deliberately learning and refactoring 18 years into engineering.

    I wouldn’t have it any other way!

    Liked by 1 person

  4. Great article and great quotes. Easily applicable to almost everything in life, “the journey to perfection is as imperfect as it can get”. You need to push out things that aren’t the best before they become the best.

    Theorising and aiming for the perfect tool will just lead to a whole lot of nothing of nothings.


  5. Somewhere both the stories talk about evolution. Actually in the quantity vs quality story, the team that targeted quantity were creating pots all the time. The thing is they were creating pots and gradually their processes evolved with practice. In other words, they were doing the same thing again and again which gave them time to learn from their mistakes
    When we refactor we revisit and rethink after reaching a position, which again helps come up with better ideas.

    Both the stories somewhere talk about giving it time and of course practice. You actually have to start working on your idea, develop it, reach a stage, retrospect, refactor, redesign, continue development and the cycle goes on. We did not get smartphones right from day 1, first we had walkie talkies, press button phones and gradually smart phones happened


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s