My friend Red had a problem with his code.
He was working on integrating a popover onto an application that used a home-brewed variant of Redux Form. This version came with a few extra features to [attempt to] make itself easier to use and reduce development time.
I’ll try to describe the problem in the easiest way possible:
- The popover was to be summoned by clicking a button inside the form.
- Upon clicking the button, the popover indeed showed up (so good so far.)
- The submit event for the form was triggered at the same time.
By the time I found him, he was proposing to catch the source of the event and use it to filter which buttons were allowed to initiate it. He also tried to scout the entire source code for Redux Form and the plugin built on top of it.
I suggested he change his trigger from a button to an anchor. The code was working 2 minutes later.
Well yes, it actually can be that easy.
When working on something for long periods of time it’s possible, and sometimes inevitable, to become so focused on whatever it is we’re doing that we lose sight of any alternative methods of achieving the same results.
We develop what is known in psychology as Tunnel Vision; meaning that we only focus upon a single aspect of a whole, instead of seeing the bigger picture.
The reasons for this behaviour are many and probably outside the scope of my experience as a Web Professional. That being said though, there are a few factors that I have observed to play a part in the process:
- Lack of sleep.
- Being overworked.
- Deadline-induced stress.
But to me the single most interesting factor comes from a belief I’ve seen many people hold in the past:
It just can’t be that easy.
Well, why the fridge not?
As professionals we are inclined to believe that we do things that are supposed to be difficult. After all, why did we have to study so much, gather so much experience and work so hard; if we were going to end up doing things that were easy to solve in the first place.
But it is precisely because we did all of that previous work that we can find the easiest and simplest solutions to our problems.
As we become more experienced in our jobs, we become accustomed to them. We develop an eye for bugs and glitches. We learn of particular quirks in our language that make things easier.
And most importantly: We learn to judge and prioritize a given situation.
Red’s problem was caused by a bug inside the home-brewed plugin: It forcefully caused the submit event to trigger upon the user pressing ANY. SINGLE. BUTTON.
Was it unexpected? Yes. Annoying? Most definitely.
Did he really need to fix it to get his code working? No, he just had to get the popover to display without triggering the submit event.
And that’s what we did.
Your code doesn’t have to be perfect.
Let’s look at another example:
- Upon clicking on a button he would use a selector to gather all the HTML elements that had the same class of “tab”.
- He removed the tab-selected class from all of them.
- He would gather a data-attribute from the button that determined the index of the tab that he had to open.
- He would later use the .index() method to select the tab from the gathered collection and add the tab-selected class to it.
It was a really elegant solution: It essentially allowed him to have an unlimited number of tabs that he could open with any button; provided he gave it a data attribute with the index for the tab he wanted.
The only problem is that it wasn’t working at the time, he had been working on the perfect solution for the past six hours and he had to deliver the code in the next 30 minutes.
His eventual solution: Give the tabs different classes, change the data-attribute to reference those classes instead of the index.
Was his new solution more re-usable than the original? Nope. Was it more elegant? God no. Did it do the needful? Well yes it did sir, yes it did.
Even thought it can be tempting to provide a perfect and re-usable solution to your problem, going overboard with it can lead into something called Gold Plating: to work on a particular task way past the point in which you’re still adding value to the project by doing so.
It may seem harmless, but working like this can really slow a project down and cause you to ignore some of the other, maybe even more important, tasks at hand.
I’m not suggesting that you should do a poor job and cause technical debt just because you think nobody else will work on your code. You should always aspire to write the best code possible within your means.
All I’m saying is that you don’t have to reinvent the wheel, save the country or be a hero. More often than not, all you really have to do is solve the problem.
So, whenever you find yourself wondering if you’re gold plating a given effort, just ask yourself the following questions:
- Could I achieve the same result with significantly less code?
- Am I forgoing other (perhaps even more important) tasks to work on it?
- Can I do with something less re-usable?
- Is this effort adding value to the project?
If you answer yes to any question other than 4, you could probably reconsider where you’re placing your attention. And if you answer no to 4, then there’s most definitely something more important for you to be doing.
My two friends didn’t really need to reinvent the wheel, push the boundaries of coding or be the hero that Gotham deserved. They just had to solve a problem.
And most of the time you’ll find that you don’t have to save the world, either. Not all your code needs to be a re-usable, elegant, multipurpose and perfect API.
Sometimes your code just has to do what your code has to do.