3 Benefits of Doing Something Different When Stuck
As some of you may know, I build automations as part of my day job. Sometimes, I do find myself getting stuck on building an automation. When it comes to programming, you can do an online search and find an example or the exact code for the thing that you are trying to program but cannot figure out how. However, there are times where the answer cannot be found on Stack Overflow. I know every programmer that is reading this probably had a facial reaction or yelled an expletive to the previous sentence, but it is true. I will admit, Stack Overflow does have a lot of the answers to the most common routine programming and computer questions, but there are still unknown unknowns that it does not have the answers to.
In my younger programming days (you better not be laughing), I would keep trying different ways of accomplishing the programming task. This, continue working on it until you get it right approach, would work some of the time because I would become so focused on the program until I got it right. Things have changed since then. New technologies have taken over (Python gasp). New programmers are not following the common standards or the specific language, like starting Java functions with an upper case letter, or just coming up with their own standards and wonder why other programmers do not want to touch what they have created.
One: You Get More Work Done
With the automation team that I work with, we use JIRA for our task tracking. I put those JIRA tasks and the amount of time I spend on each task on my Outlook calendar, so that I can get a visual of how much time that I have spent on a given task in comparison to my week. By combining the visual from Outlook calendar and the Scrum Board from JIRA, I realized that I was completing fewer tasks in less time when I got stuck with a programming issue. Those of you familiar with Burn Down Rates and how it can impact a project will probably understand this the best. Staring at the round peg to see how you can get it in the square hole will not make the solution come by easier. If you know that you have other square pegs to place into square holes, then you can work on those and come back to the round peg and square hole. I have even completed lower priority tasks before higher priority tasks because I knew that I had or could reach the solution to that lower priority task faster than the higher priority task. Some project managers may balk at this approach. If they do, my recommendation would be to reference your Burn Down Rate so that they see that you are completing more tasks, although it may not be the high priority ones.
Two: The Numbers Favor You
The more that you are able to complete in given amount of time, the more valuable and productive that you appear. If your manager is only concerned with the numbers and not the science or reasoning behind the numbers, then this tip is great for you. Managers that only look at the numbers and not the data that supports the numbers think that things are going great because more tasks are getting completed. However, if you have 10 tasks that are to be completed within a sprint, and 5 of those are defects from crappy done work in a previous sprint, then you are really only completing 5 new items instead of 10, thus 50% new feature rate. Solely looking at the numbers may not convey this point depending on how it is presented. If your manager actually wants to know the science or reasoning behind the numbers, this will probably get you on the Naughty List. When I work on an automation, I design it in a way so that unless something major changes (e.g. API changes, new elements on a page, conversion to new technology), that automation will work correctly and has the intelligence to handle minor issues that may occur. That way I’m truly completing the tasks assigned and not repeatedly patching defects or making small adjustments, thus reducing the number of new automations that I can complete.
Three: Less Mental Fatigue and Strain
Since I was not so dedicated with completing one single task before moving on to the next, I realized that I was able to complete the work without being as mentally drained at the end of the day. Programming does not require much physical effort as most programmers either stand or sit in one spot while they do their work. However the ability to be able to assemble things in a logical fashion takes a lot of mental effort. Combine that with not being able to complete a given task, in other words doing the same thing over and getting the same results, and you will have a high level of frustration and a low sense of accomplishment.
Conclusion
This article was written with programming and technology examples included. However do note that the main points can be applied to anything that you encounter. For instance: Cannot figure out why the tv will not turn on? Go listen to the radio. Later, check the power cord, surge protector if it is plugged into one, and replace the remote batteries. Cannot figure out why the ice maker is not making ice? Go buy some ice. Later, check to see if the water line is connected and that it has power. Worse case by another fridge. Cannot figure out why that person cut you off in traffic and did not use his or her turn signal? Let them go on down the road. Then pray for that driver’s bad habit be removed from them and continue on to your destination.