Being Fast Matters

Recently, I learned an interesting thing about my programming ability. That I have become faster at it over the years. In software literature, being ‘fast’ almost carries a negative connotation — of being reckless and clumsy vs. taking a more nuanced approach: using a pen and paper, and deliberating over the solution. Fred brooks famously said only 16% of the estimate should be devoted to actual coding, while 33% to planning and 50% to testing and debugging.

I don’t want to debate merits of one over the other, but judging purely in terms of how much time it will take me to build a web application from scratch, I will need way less time than I’d have took 2-3 years ago.

Where does this leap come from? Quite a few things are at work here:

  1. I have created a solid stack for myself that works incredibly well. VueJS and TailwindCSS for front-end. On the backend, I would pick a bare minimal framework like Express or Python’s Flask. I would prefer raw SQL over ORMs. Again, this isn’t the ‘perfect’ stack that everyone should emulate, but it works really well for me.
  2. I have become better at picking up the simplest solution and things that fare better in the long term. For instance, I had a little bias towards MongoDB in the past because of it’s schema-less design. But it doesn’t take long to see how SQL’s querying is far superior and that being schema-less actually creates more problems than it solves.
  3. I have quite a few tools to my arsenal. I can use bash to quickly automate stuff like deployment, checking logs, and incident response.

In writing, I notice a similar pattern. Although, I haven’t accomplished much in that area, and still consider myself a novice, I have become noticeably faster at it these days. In the past, I often spent five minutes refining and rewriting a single sentence and that happens rarely now. I don’t tend to get blocked as often nor do I overthink words and phrases (in other words, not try to sound highbrow). There’s also a natural simplicity in my writing - something I aspired to when starting out.

Sometimes, I get stuck but I have developed strategies around that, too (mostly letting the draft lie in the drawer for a while before pick it up again).

Speed is a By-product

Swiftness wasn’t my objective; it just happened to be a great by-product. It isn’t a revelation why this happens. What helps you skill up in quality, also helps you doing it in lesser time. Drawing from the two fields I just mentioned, I can notice a few factors behind this growth:

1. Better pattern recognition

You get better at spotting that the problem at hand is identical to the one you’ve solved in the past. The effect is more pronounced in programming, but I think writing is similar. For instance, if I have to write a news report on an accident, a journalist would be much, much faster than me. She would have a better idea on how to start an article, how to communicate the gist of the story, and how to phrase things for that context.

2. Employing better tools

You find newer tools or get better at existing ones. An experienced vector artist would be much better at using different keyboard shortcuts of the software allowing them to switch tools much faster, a researcher at using Google effectively and organising his notes.

3. Creative destruction

Joseph Schumpeter, an Austrian economist, coined the term “Creative destruction”: a process of dismantling of long-standing practices in order to make way for innovation. Film cameras didn’t pave the way for better film cameras forever, they did for digital cameras.

I like to use this term in skill development, too. Creative destruction takes apart your long standing assumption about the field, and creates a wholly new way of thinking. In programming, it helped me a lot to know that being super-organized while useful in a big company, it doesn’t win much at a smaller scale. It’s okay—and even desirable—to be a little messy there.


Does everyone gradually get faster at what they do? The evidence around this is a bit anecdotal as there isn’t a lot of data around people clocking their time right from their beginner days. Nor it’s easy to measure it objectively as creative work’s difficulty is varying.

But, if you make certain assumptions, I see examples all around. John August, an American Screenewriter, says that he took 3 weeks to write screenplay for Charlie and the Chocolate factory. An experienced comic artist takes around a day to create one page of the comic, which includes sketching, shading, and coloring multiple panels.

Of course, there are bounds. Taking a look at how many words novelists write per day, the upper bound seems to be around 3000 words. And quite a lot of it will get edited out in final draft. Another aspect of it is that it’s easy to take speed as the target, and become a victim of Goodhart’s law.

But my point is that speed is a close approximation for skill. If you are getting better at something, you’ll also become faster. In the beginning, you’ll always be slow and deliberate, annoyed why something takes ages to finish and sub-par even then. Gradually, your quality goes up and so does your pace.

Speed shouldn’t be your goal, but it’s good to check yourself once in a while - have I become faster at this as compared to sometime back?

Subscribe

Enjoyed this post? Get an email notification when I publish.

comments powered by Disqus