Welcome to another AppnByte. An initiative where our developers unpack the lessons they’ve learned throughout their programming careers.
Today’s piece is on distraction, penned by Bradley Smithies – Software Architect at Appenate.
Let’s jump in.
How To Avoid Rabbit Holes
Every programmer has found themselves here at some point: working, almost done with a code change, when an idea strikes us, “I wonder if this would work …” You’re now teetering on the edge of a rabbit hole, enticed by the unknown that the darkness may hold. Perhaps, hiding down there, just past the entrance, will be a better way of writing the code that already works. The temptation is just too much and we jump in. Quickly finding exciting little scraps that may work better, we are pulled deeper. Around the next bend in the tunnel, we may come across a syntax change that will make it easier to read. Down this little drop, we find a way to not repeat a statement. Maybe, down this passageway – a way to not repeat this similar-looking block of code. So many options!
However, time passes. And after copious coffee consumption and some six hours of digging and trying new things, we decide, no – the original way we had was fine and we run with that solution.
I love programming. It became my interest at age 12, my hobby at 14, and has been my job since age 16. It became my “Lego,” a solution to the frustration of running out of bricks that impeded my imagination. I could build anything. I could automate everything.
The enjoyment of being able to write a set of instructions that allowed me never to have to do a task myself again inspired me to spend hours automating a task that may only take 10 seconds. I would try to perfect every function. Did it make sense to do all this work just to save 10 seconds? Nope, but I loved doing it anyway.
Programming was an art to me, one I wanted to perfect.
Yet, there is a big difference between passion and business projects – time is money. Sure, there is an endorphin rush as you implement the absolute best solution to a problem, but does it make the code base better in a tangible way? I am not suggesting you write sloppy, unmaintainable code. That’s a no-go. But there is a culture within the programming community that everything has to be absolutely perfect – every principle upheld without exception.
On a small scale, a simple example is the concept of ‘Once And Once Only,’ that we should never write repeated code. When we see a few lines of code that look similar to another, it’s tempting to want to pull it out and transform it into a reusable function. However, in real-time, this can often lead to problems. When the code pulled isn’t actually the same, it can add complexity and waste hours dedicated to trying to get it to run in different functions.
On a project-wide scale, it could take the form of a new framework version. It’s tempting to chase the latest, shiniest version with all its flashy new features rather than the one that works best for the business. This can lead you to dive into a project that leads to many hours of work, not to mention the possible bugs that could come from such a change.
It’s better to have a functioning, well-written product than one that has bells and whistles but crashes constantly.
Before embarking on any such endeavour, big or small, the first question should always be – SHOULD I be making this change? It’s so easy to get caught up in the excitement of possibility that we fail to ask if we really need it from a business standpoint.
I’ve learned to keep my passion projects on the side. There, I don’t need to worry about that “should”; I can just tweak and fiddle to my heart’s content. However, when it comes to business decisions, always remember the question is, “Should I?” Not, “Can I?”