In 1992 Arien Mack and Irvin Rock described a psychological phenomenon, when people don’t see unexpected things happening just before their eyes.
Our brains are wired to have a selective focus. It helps us do our daily jobs. But it also means, we miss things right in our plain sight.
The phenomenon of unintentional blindness affects various aspects of our lives. For example, we are almost 100% blind if it comes to seeing ads. We all know they are there, but ignore to see them.
Likewise, the phenomenon impacts our work as software developers. So it is important to make sure, important stuff is truly visible to us.
No matter if you use Visual Studio Code, or WebStorm, each of these IDE’s offers notifications about problems in the problems tab, and by underlining pieces of code that pose a risk.
The thing is, we don’t see them anymore. It is a trap that many of us are caught into. It just takes ignoring one error or warning for several hours, and our attention to all new warnings drops drastically.
Eventually, we just ignore issues tabs, and underlined code, because, it is not necessary to publish a perfectly working solution.
I was working with that issue for many years, and today I want to share with you a method to fix it.
The method is the Problem Zero Rule (PZR). Similarly to Inbox Zero, it helps in productivity, concern handling, performance and peace of mind. Like Inbox Zero rule helps to have a better experience with e-mails making it a great experience to work with them.
3 rules of Problem Zero Rule
To apply the Problem Zero Rule to your coding behavior, you should apply these three rules:
Your code should never have problems.
Problems tab should be clean 100% of the time
No portion of your code should be underlined
It means that every time you work with the code, you make sure, it does not expose any non-critical concerns from now on.
By doing it, you will stop being blind to IDE warnings and start treating them as a helpful resource to improve your code rather than ignoring them.
How to start?
Your code may actually have a lot of warnings. So it will take some time to tidy it. Here are some tips to do it:
Fix easy to fix warnings
If you don’t have time to fix other warnings, but they are not critical, add ESLint, or TSLint ignore comment
Make it your routine to remove these lines over time, so you eventually end up with no ignore comments and no problems
Now, adding ignore comments seems like a bad idea. Because you won’t see warnings about issues that are already there. But the fact is, these warnings are there, but you, and your teammates, are already infected by inattentional blindness.
Incorporate Zero Problem Rule!
First, you have to regain your sight for potential issues before you can actually work with them.
I strongly recommend using the Zero Problem Rule in your coding practice. It seems like an additional effort, but it is worth it. Later on, your problems tab and underlines with warnings will give you back time, but helping you write better code and spend less time for debugging.
Also, you will have the pure satisfaction of writing 100% clear and valid code and empty concern list. A feeling that is something great to have while working with serious coding challenges.
Share your experience in the comment, and upvote the article for more coders to incorporate Zero Problem Rule for benefit of us all!
Oldest comments (0)