i agree with boring

I couldn’t help but nod my head the entire length of the blog post written by Jeremy Wagner on make it boring. It’s not often that I find someone literally following my train of thought so succinctly, albeit from their own unique angle. The principle behind the post is that boring things are the big stones to be put in first.

From my early experiences in life, I quickly noticed that people who had observably less than glamorous lifestyles and careers, seemed to enjoy the best of life. The dichotomy made it clear that people who actually showed the greatest want of fun, glamour, etc found those things to be quite elusive. So as a child, I quickly realized and ingrained in myself that to become good at something, one has to be willing to do the dirty, boring work everyone tries to avoid. People whose primary goal is fun and adventure literally stand in their way of attaining that, due to failure to do the hard work first of simply getting money and influence so doors can open. It’s quite perplexing but we usually put the cart before the horse. Due to different experiences, I have come to appreciate the importance of “boring”.

I guess part of the reason why Jeremy’s post struck a cord is that I did Test-Driven Laravel which reminded me of this concept of boring. A lot of people shrug at writing tests but they hate bugs! I came to love tests because my code was breaking way too often and coupled with my uncontrolled enthusiasm that “it now works!” I challenged myself to find a way to guarantee better quality right off the bat, which is how I got involved with testing. Going through Testing Laravel, I was awed by the methodical approach Adam Wathan takes, testing almost all the logic, wiring in the Unit and Feature tests before, usually, any other implementation details. I wondered why this isn’t an approach a lot of people use, and I am not saying TDD is the holy grail of development, but it sures improves quality and costs in the long term. So why don’t we make it a strict requirement? I know a lot of people will cite budget, but many product owners do not consider test coverage in their quotes from the get-go anyways. The true reason why a lot of people don’t do this, is that it’s boring. It is better ignored so that people can get to the interesting bits quickly. In doing so, we neglect a lot of the fundamentals that are needed for the initial sparkle to last.

Boring and predictable are expected qualities of the essential.

This concept overlaps to almost every endeavour in life, and it is most rampant in coding. I have been approached by many peers and friends who would love to code because they see the laptop stickers and immediately think, that’s shiny - i want to look even cooler, and almost always they do not try hard enough before throwing in the towel. Coding is not all hunky-dory, and with the Javascript landscape as it is, a lot of newbies look for quick fixes, lacking the tenacity to try and understand the underlying, future-proof native solution to most problems. This is where I think becoming a junior fullstack developer is also a huge disadvantage in that it doesn’t allow you to deep dive on topics enough to achieve mastery quickly. Instead you merely scratch the surface in different fields and the resulting mindset breeds the quick-fix mentality. I would argue that mastering one field makes it much easier to transfer that knowledge to a related domain and become good in a much shorter period than the alternative of trying to become excellent at more than one simultaneously. Knowing a little about many things can be a huge negative.

To achieve mastery and create delightful products, we need to be masters of our craft. And there are no shortcuts, basics and solid principles that encourage scalability and easy maintenance should come before flashy. Getting them is boring, but boring is where you buy the “fun”. It’s just not enjoyed instantaneously. It might be counterinituitive but I think it can be an eye opener to pause next time you want to npm install something and think about the additional burden the package is going to bring. Do you really need all that chuff it is going to pull, or can you create a little module that covers what you want? Examples are plenty if you are paying attention in your work, but let’s challenge ourselves to do the boring but right way!