As an engineer, if I have to pick something that I always struggle with, and seems like a never-ending problem, it's worrying too much upfront about an issue that hasn't happened yet, and probably never will.
In general, given the number of unknowns and uncertainty that life has, preparing ourselves and worrying about what may happen in the future is a natural reaction of our body. And that can have multiple implications in our day to day as engineers.
How does impact our daily work?
Generally, as we can’t predict the future, we might end up in situations where we are working on something that might have no importance in the future, causing our time management fail.
In my experience, breaks or coworkers are the ones who help me get out of those situations. Or at least they force me to tweak my time-investing strategy.
Although context switching might have the opposite effect and makes me lose concentration, it encourages me to have fresh starts and empowers me to recap and look at what is happening from a different perspective.
Following techniques such as Pomodoro often helps me prevent this from happening. A technique, which basically consists of doing 25 minutes of work, with a 5-minute break. But most importantly, I turn off notifications to make those workspaces more productive.
I must say that I don’t use any tool or software for time tracking. Being aware of it already does the trick for me, since sometimes 25 minutes is not enough to finish something that I can continue later.
On the one hand, being meticulous with details is positive, since things may seem simple, but in reality, the details are complicated and likely to cause problems. On the other hand, it could make us lose focus on the big picture. With time and experience, we will eventually find the right balance.
Let the problem become one
Like I said before, I tend to worry about details and possible scenarios that may or may not happen in the future beforehand.
How many times have you, as a team or individual, invested a lot of time on a specific problem or edge case that ended up not being a problem?
An example that I always recall when discussing this matter, was that time when I spent a week trying to figure out a CSS issue on Internet Explorer. And, over a cup of coffee, some stakeholders noticed my demotivation and told me that for that particular browser I shouldn't worry too much, as the analytics for that browser were lower than our official threshold.
Or even from another angle, sometimes I feel that in previous experiences I have foreseen performance issues because I was assuming how the users were going to use part of an application.
In both cases, the investment of time and effort didn’t pay off, and I could have used that time to develop other meaningful tasks.
These situations are not only discouraging in terms of technicalities, but also demotivating, as we realized too late in the process that what we have done in the last few days or hours, has a really low impact.
I also attribute this to the fact that we just like to be challenged, and the feeling we get after solving a complex is hard to explain, but maybe in the environment we are in and from a business point of view it’s meaningless.
In a nutshell, let issues become problems, and look for real evidence instead of gut feelings or making the wrong assumptions.
Did anyone give us feedback about that particular issue? Is it really an issue? Is it a blocker? Try to get the full context.
Speaking of getting the real context before jumping right into it, I remember one Christmas Eve I was on-call and got a phone call about a service not working. I spent 2 hours fixing the issue with the other person, and when I asked the counterpart to do a verification check, he sent me a QA link.
As you can imagine, that was the exact moment when I realized that it wasn’t a real issue and it was only affecting the QA or staging environment for that particular person.
Hope this doesn’t sound like I am against preventing, just being aware that sometimes we go too far down the rabbit hole.
Business breaks
As we progress, we begin to realize how important meetings or sync ups events are (whether they are synchronous or asynchronous) to align expectations and learn more about the business plan. As a result, it will give us the ability to make better decisions in the long run.
Iterations and metrics also play an important role here, as those two factors can be deterministic to define when, how, and where should we invest our time.
Lean on stakeholders or co-workers with higher views such as Product Managers, Engineer Managers, Project Managers, etc, when in doubt about something. Being autonomous is great, but it doesn’t apply to all scenarios.
In simple words, validate ideas up front before making big commitments.
Being preventive helps us prepare for the future, but if we turn that into a waterfall, we might be holding ourselves to deliver faster in a world without patience.
So, in case you spot a potential issue, simply save it to investigate later on when there’s less of a rush. And most importantly, avoid getting caught up in the scope creep of a task.
Top comments (0)