There is a claim that “Quantity Always Trumps Quality”.

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.

I heard this story from the book while listening to a James Clear podcast which I had “temptation bundled” with playing some Pokemon Sword.

I immediately thought back to the time my boss had challenged me to take 1 good picture every day to get better at photography and thus develop my artistic side more to apply to software engineering. However, I got so hung up on what a good picture was that it never became a habit. I get hung up on the same thing when trying to write or workout consistently.

So does quantity trump quality in software engineering especially with the emphasis on clean code and reducing technical debt?

At work I have reflected that when I am more aggressive with building software and talking about design I put myself in the position to make more mistakes and to get embarrassed about looking stupid. However these soul ego crushing moments are actually the best learning experiences and the more I get now, the better. For example, now I remember that std::collections::VecDeque is a ring buffer after misspeaking and being corrected.

Another example is that we’ve had to rebuild our stream processing “reusable infrastructure” multiple times. Even though we all want to design our software to be future-proof, design requirements change and software has a purpose that it is best suited to.

For example, my first full time job was to work on a stream processing platform. Whereas delivering augmented video in 30 minutes was the cutting edge the first year, that time was cut to 3 minutes the next year, and then sub-second the next. In the first case, it might be best to optimize for individual team productivity by building around a RabbitMQ message passing system for multiple services to interact with. However in the sub-second case, message passing between services on different servers was out of the question and all these services would need to be on the same machine.

Thus, by focusing on quantity, we can eventually achieve greater quality than if we focused on quality to begin with.

Atomic Habit

What if every day I focused on writing one line of reusable code?

In 2001, researchers in Great Britain began working with 248 people to build better exercise habits over the course of two weeks. The subjects where divided into three groups.

The first group was the control group. They were simply asked to track how often they exercised.

The second group was the “motivation” group. They were asked not only to track their workouts but also to read some material on the benefits of exercise. The researchers also explained to the group how exercise could reduce the risk of coronary heart disease and improve heart health.

Finally, there was the third group. These subjects received the same presentation as the second group, which ensured that hey had equal levels of motivation. However, they were also asked to formulate a plan for when and where they would exercise over the following week. Specifically, each member of the third group completed the following sentence: “During the next week, I will partake in at least 20 minutes of vigorous exercise on [DAY] at [TIME] in [PLACE].”

In the first and second groups, 35 to 38 percent of people exercised at least once per week. (Interestingly, the motivational presentation given to the second group seemed to have no meaningful impact on behavior.) But 91 percent of the third group exercised at least once per week-more than double the normal rate.

He also goes on to describe how each one of these decisions is a vote in a voting machine which becomes your identity eventually.

Every day, I will write at least 1 line of reusable code at 9:30 am in my room. I am a 10x engineer. (I am not there yet but will keep saying it to myself until it becomes my identity.)

Also, building reusable code is a good way to get future projects done in a weekend! -_xj7x on Hacker News