Time traps that software developers face

And how to mitigate them

Photo by Brooke Cagle on Unsplash

As software developers, we enjoy a high level of autonomy. As long as we achieve our goals, we have the luxury of allocating our time as we see fit.

If we are not careful with said freedom, we run the risk of spending time on activities that offer minimal benefit to our work. It is easy to be carried away with these activities because they provide the illusion of moving forward.

These time traps are everywhere. They sneak up on us. Recognizing them is the first key step in mitigating them.

Trap 1: Perfectionism while coding

It is admirable to produce the highest quality work all the time. But it is possible to do “too much”. When coding, we can be bogged down by perfectionistic tendencies.

One typical occurrence of perfectionism is the urge to continuously optimize code, beyond the point of necessity. Optimization usually revolves around two aspects: performance or code “cleanness”.

Don’t get me wrong, I am all for highly readable efficient code. I’m guilty of writing unreadable and sluggish code, especially in the first few years of coding. I wish I read Uncle Bob’s book Clean Code in kindergarten.

Too much of a good thing can indeed be a bad thing. Unless you work on real-time systems where every ounce of performance matter, there is no point in spending days squeezing out the last 0.005% of the code performance.

The same goes for code cleanness, there is no end to cleanness. You can always go “cleaner”.

Solution:

Good enough can be really good enough. Writing high-quality code requires a certain amount of discipline. Equally as important is the discipline to know when to stop optimizing!

How do we know when to stop investing effort into our code? Here are some aspects to consider:

  • the type of software we are building: it makes sense to put in more effort into production systems than throw-away prototypes
  • the lifetime of the code: obviously, more thought should be put into a feature that needs to run for many years as opposed to a feature that you know will be replaced in a few weeks
  • upskilling: if you are not familiar with the system or programming language, you might want to invest more into optimization for the sake of honing your skills

Trap 2: Future proofing architecture

Designing the architecture of a software system is a time-consuming endeavor. Just like coding, it is also possible to spend too much time when dealing with architecture.

Thinking about the extensibility and maintenance of the architecture is part of the job. When taken too far, we can spend too much time making the architecture overtly generic, in hopes of future-proofing it.

When working on concepts in a group, an easy way to spot unnecessary future proofing is to listen to the ongoing conversations. Phrases like “what if we want to..” or “I assume that product management would want later..” are good signs that there is some tendency to overtly future proof the software.

We simply cannot see into the future. Future requirements can change as a result of market feedback or a shift in product management strategy.

Solution:

When designing architecture, focus on fulfilling current requirements and not on possible future requirements.

I am not saying just blindly focus on the current task and totally ignore the future. It makes sense to communicate with product management to gain perspective on the general direction of the product. Even if the information is not yet concrete, this heads-up is still much better than baseless assumptions.

We have to make a clear distinction between handling edge cases and future cases. Often, these two are confused with each other. One good way to recheck the specific requirements.

An edge case is a real possibility that can happen within the parameters of the current requirements. Future cases are hypothetical what-ifs.

Trap 3: “Tradition” of doing things

Processes are defined for good reason. They are created because we have figured out how to do something efficiently and have decided to standardize the solution.

In the software development lifecycle of tech companies, we have clearly defined deliverables for each phase of development. These deliverables include software artifacts, documentation or the passing of certain checks.

Sometimes, processes no longer provide their intended value. Possible reasons could be changes in the product strategy, changes in competencies or organizational changes.

Blindly following processes after this point out of “tradition” is a waste of resources. Every one of us can all think of examples when we had to fill out certain forms or provide artifacts, despite clearly knowing it is simply because “it is the way we have done things”.

“Tradition: one of those words conservative people use as a shortcut to thinking.” 
― Warren Ellis

Inefficient or unnecessary meetings could also be a result of “tradition”. People can easily drift into autopilot mood when organizing and executing meetings.

In a previous job of mine, the department scheduled retrospective meetings. The purpose was to find out what the department can improve. The purpose was noble but the execution was not.

Every meeting was structured the same way. Lists are made of what needs to be changed. After that, dot-voting is done to select what work on. Then, people are assigned to tasks.

Unfortunately, no action is taken after each retrospective. Yet, such retrospective meetings were continuously repeated every few months because of “tradition”. With time, people were increasingly more frustrated and bored. They attended the meetings because of obligation.

Solution:

To remove “traditions” that bog us down, we have to first identify them. One quick way to identify processes that no longer offer value is to listen to the conversations around us.

Listen to colleagues when they complain about processes. Are they frustrated because they are involved in a pointless process? Are they making snarky remarks that a process takes too long?

When listening to complaints, it is important to make the distinction between cold hard facts or mere opinions. Some people complain because the situation is shitty. This is valuable input you can use. Some people complain because they are complainers. Ignore these.

Avoid optimizing processes for the sake of optimization. This is unnecessary and is a time trap by itself!

Trap 4: Optional information sharing meetings

Tech companies invest tremendous resources to ensure employees have essential information. One of the main ways to spread the information is to organize information sharing meetings.

I notice that these meetings typically fall into one of the 2 following categories:

  • information about company strategy and leadership
  • knowledge sharing

Examples of meetings that fall into the company strategy and leadership category:

  • strategy and all-hands meetings
  • “informal” coffee-corner meets with leaders
  • open dialog sessions with the focus on Q&A

Examples of knowledge sharing meetings:

  • internal conferences
  • sessions where external speakers are invited to share their knowledge
  • workshops on specific technical or soft-skill topics

The larger the company is, the larger the number of such information sharing meetings exists. These sessions are a good thing. Knowing what to do and having the necessary information to do them is vital to the success of any company.

The caveat here: just like the previously discussed time traps, too much of a good thing is a bad thing. We can take part in as many information sharing sessions as we want. No one checks up on us to see how much time we spend at such meetings. It is possible to attend too many meetings, i.e. being at meetings that have little to no relevance to us at all.

Solution:

The solution is, of course, is to have discretion when choosing which meetings to attend. So the question is: how do we know which meetings are relevant?

To be honest, I am still trying to find this balance for myself. Currently, I use the following criteria to filter out meetings:

  • relevance to the current job: do I need this information to execute my current job to the highest standards I can?
  • relevant to the career path: would this information be relevant to the things I want to do down the line?
  • interest: do I find this topic to be interesting, despite not directly relevant to my job?
  • perspective change: could this meeting offer me a fresh perspective on how I see things? Is there a possibility of obtaining new information that could challenge my current assumptions and beliefs?

Trap 5: Distractions

Distractions are time traps. Plain and simple.

I’m sure you have read or heard of Cal Newport’s book “Deep Work”. He does a great job explaining the importance of focusing deeply without distractions when working. I will not try to regurgitate the concepts here.

I feel mentally tired when I have to fight distractions when working. This wastes time in two ways:

  • it takes a longer to complete tasks
  • it takes longer to recover before doing other tasks

Common distractions that I experience are:

  • the activity of colleagues in the office: I used to work in the same office as a colleague who yells expletives and slams his keyboard when frustrated with code
  • on-screen notifications: I would be distracted by the blinking of notifications for my emails and Slack. It is costly for the brain to manage context switches

Solution:

Obviously, the solutions have to depend on the type of distraction we face. We can either remove the distractions or remove ourselves from the distractions.

I used to work in a bigger office that sat my whole team of 10. Now, I work in an office of 4. I can concentrate much better at work.

A common justification for having larger offices is that they facilitate communication. From experience, the benefit of focused work outweighs any benefit of improved communication. Walking out the door and into another office does not take much more effort than swinging your chair around.

To cut off distractions, I also experiment with working from outside my office. I occasionally work from home, at the cafeteria or on a bench outside the building.

As for notifications, I turn off all my notifications on all my devices. It has been one of the easiest and most beneficial productivity “hacks” I ever tried.

Conclusion

In the world of software development, resources are abundant. Companies have obscene amounts of money to hire the brightest minds. Employees have access to the best of what technology has to offer.

“How did it get so late so soon?” 
― Dr. Seuss

Time remains the one resource we can neither buy nor manufacture. That is the reason we have to guard time closely by minimizing time traps.