So I tend to optimize the order and the way I execute any kind of task in the working environment or make decisions in life outside the working hours. One of the most efficient tools to tackle this issue is IDGAF (I Don’t Give a Care) and this is what I will discuss in the context of a Software Engineer.

First of all, if you feel like you absolutely don’t care about what you are doing, you should definitely change something. There are many possible solutions to this problem: talking to your manager, making an internal move, or even buying a boat and sailing through the Atlantic in order to become a pirate. You can even do all three if working remotely is allowed.

What I mean about not caring as a Software Engineer is to not care about some specific thing at some specific time for some specific reason, which later results in performance and efficiency increase and, therefore, the happiness boost of the Product Owners. In this story, I will give you a few examples of what I went through and suggest some possible solutions for some recurring problems you might face even outside the examples I will provide.

Motivation

As a Software Engineer, you want to do the least possible work to achieve the greatest results. While doing so you don’t want to just write some spaghetti code and call it a day even if everything is working fine. You have to design and build maintainable software so your peers and yourself, in a few days or months, don’t experience any suicidal thoughts when looking at the code you wrote. To achieve such design and code excellence, you could be writing your code forever and making it the most maintainable possible, and being the great winner of the Software Engineering game. But there is no fun if there are no rules. The most impactful rule and the one that makes us work smart is the time limit assigned to each task, also known as the deadline. Yes, the deadline is a scary word, but don’t worry, sometimes there is a way to achieve what is expected in the due time and, hopefully, the art of not caring will assist you and your team to change that sometimes to always.

Given the classic project management triangle, the three main ideas (blatantly copy-pasted from Wikipedia) are the following:

1. The quality of work is constrained by the project’s budget, deadlines, and scope (features);

2. The project manager can trade between constraints;

3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.

The point that stands out the most is the third one. It is very important to balance all three constraints in order to achieve the best quality. Not caring as a Software Engineer tends to accelerate the development time and, therefore, to improve the number of completed features in the scope. It can also aid in reducing the cost of development if we just ignore certain unimportant ideas.

On the other hand, not caring too much can inflict a wound on the quality of the features being developed, resulting in bugs or heavy technical debt. So, it is very important to learn which ideas are worth pursuing in a given scenario and which are worth being thrown away or scheduled for later.

The art itself

These are some interesting situations that I’ve had the pleasure to experience and that I consider very important for better performance and overall time management:

• One of the most important and valuable lessons I’ve learned is that, when designing a solution for a problem, one should start by designing a more generic solution. Look at what tech stack will be used, what are the systems that this new service will depend or be depended on, and what external services are to be utilized. It is of no use starting to immediately design low-level features and the way they should be implemented. One might then realize that it won’t work at all due to some high-level constraint, or no solution is necessary as someone found out that there is actually no problem to solve. Let’s put it this way: there are ways of writing code that do the same thing in any given scenario, but there might be only one or even no way to structure the system and component architecture which then would imply modification at a lower level. The main idea here is to not care about the low-level implementations during the initial designing phase
• At Talkdesk, we work in an Agile environment using the Scrum methodology. We have refinements where we write some stories, polish some existing ones and estimate them. Sometimes there are stories that require further discussion and cannot be easily defined. We’ve had many refinements where the development team would start discussing the technical details of the implementation. This would sometimes take quite a bit of the refinement’s time, leaving our backlog a very sad place to wander through. To solve this, we created a special weekly hour for engineers to discuss and work on the blocked stories they weren’t able to decide upon during the refinement, drastically improving the refinement’s results. This weekly hour tends to be very productive. Our team learned how to not care about certain details during the refinement to improve our performance, effectiveness and overall team’s time management. So the idea here is to not care and to not be afraid to schedule all the extra discussion outside the scope of some meeting to some other time
• Many times I see (and practice) requests that are not complete and lack some core information or extra work before the request receiving team can finally work on it. It is fine if this occurs only once, the receiving team can happily assist in refining the request. But if this happens more than once, the receiving team’s time wasted on the stuff the external teams should have taken care of increases dramatically. The more teams exist, the more incomplete requests there are and the more time is wasted by the request receiving team. The solution implemented at Talkdesk was to write extensive and rigorous documentation on when and how to create and format requests so the receiving team can start working on the task without clarifying and, possibly, changing it. In this case, in order to not care about something and save the team’s time, a solution was implemented to delegate the work directly to the request reporting persona until it was correctly formatted following the provided extensive documentation. Unfortunately, not all people tend to RTFM, but, nonetheless, it allowed the receiving team to just point the requesters to the documentation instead of diving into the request itself before it was ready
• Sometimes, because of a lack of knowledge in some specific area, a question to your team about some system that your team does not own might be raised. Given the human nature and the immense curiosity a human being can demonstrate, I’ve seen engineers, along with myself, wander around another system in search of an answer to that question. Of course, it is vital to know other areas of the software you are developing and to not just sit in your little box with a doormat saying “My Safe Space”. Although it is critical to understand that one has its own tasks and is not close to being obligated to answer questions on the systems one does not have enough information about. If the answer to the question does not arise fast and easily, the asker should be delegated to the team that owns the system. This is not just because the other team has more knowledge, but because you and your team might have an incorrect idea on the subject due to a lack of information. This might result in an incorrect answer and further issues and, possibly, in a technical debt that could have been avoided. If one is still curious about the answer to the question, one can ask to be added to the conversation or just lurk around it. The idea is to not care too much about questions that are not about the systems your team owns.

Conclusion

The art of not caring is not something easy to excel in and I consider that knowing when you absolutely must care and when you shouldn’t care about skills that should be learned and continuously improved. It is important to understand that one does not have enough time for everything, so one must know how and what to prioritize. Correctly defining priorities and focusing on them, and ignoring completely irrelevant ideas is the core of time management and performance excellence. Not to forget that not caring about something doesn’t necessarily mean to forget about the issue, and never look at it or wonder about its fate ever again (P3 bugs cough, cough). What is crucial to understand is that in some specific scenarios, at some specific time, you should not care about some specific idea.

For better team time management, it is important to:

• Design systems from a more generic point of view to a more specific one;
• Not be afraid of stopping the out of scope discussion and rescheduling it to some other time;
• Not be afraid of clarifying the requestor on the request creation procedure;
• Delegate questions on systems you don’t own to the respective teams if the answer is not obvious.

Usually, a Software Engineer works in a team consisting of a variety of different and beautiful minds which often don’t think alike. When not caring about some idea, it is important to acknowledge such as one might be missing some important details which make that idea the highest priority and might also lead to some interesting discussions. When a team is in its zen zone, this normally is not an issue as each member is part of a unit, and caring or not about some idea derives instinctively as a team decision.