DEV Community


Engineers with Emotions

Kaarel Kann
Java, Performance, Distributed systems, Engineering leadership
・3 min read


Recently I was feature leading a development where a major aspect of our BackOffice system needed a revamp. Most parts of the project were straightforward to deliver. We were able to improve the UX in a meaningful way throughout the feature. One aspect, though, was highlighted as a big risk right from the start: a feature, which had to process and present big chunks of data. This feature was always considered as the biggest weakness of the current implementation and often cited as crippling to the users. So we were determined to figure out all the technical and usability challenges to really deliver a tool to empower our admins.


A security concern was raised during one of the demo meetings regarding the use of this high risk (and high profile) feature. We promised to discuss the implications and mitigation internally in the team. The discussions became quite heated, but we did make progress outlining few possible paths forward.

And then the inevitable happened. Not only was an existing (and improved) feature declared a security risk, it was also now considered irrelevant to the admins as it turned out that they had switched to another solution long time ago. The need had disappeared taking our hard work with it.

The disappointment was overwhelming. It was the feature that had given us much grievance before as the old solution was broken in the core. We always said that we need to rewrite it. Now that we had almost completed - it was deemed unneeded.


I tried to shrug it off and take up the next task on the list in the afternoon. I couldn't. I couldn't make myself do it. As I've been in such situations many times before I knew I needed some time to cool. But I was left pondering what I'm going to say during the next stand-up? Will I neglect mentioning the wasted afternoon?

No! I decided that I will not feel the guilt for this one. If a company can survive wasting 100+ hours on an unneeded feature then it should also be OK to take 4 hours to cool off. I also decided to be transparent about it setting an example for others.


We need to normalize the fact that software engineers have emotions. There is a big incentive to hide emotions as showing them would look unprofessional. OTOH we know that hiding and suppressing emotions lead to build up of stress and anxiety. I also know that there is certain amount of guilt involved when we do not deliver what we promise. Taking the afternoon to calm down means that I'm left with feeling of guilt and underachievement.

It's important to realize that this is not engineers' fault and it's not underachievement. These situations might not be anybody's fault - they happen. But we shouldn't neglect the fact that people have emotions, which affect our motivation and quality of work. It is not unprofessional to have emotions. Emotions make us human.

Normalize Emotions

Looking back at the situation it became obvious that such situations follow the similar stages as grief: denial, anger, bargaining, depression and acceptance. The heated discussions were about the denial and anger and eventually bargaining. The declaration of irrelevance fast-tracked me to the depression stage, which needed to be gone through in order to reach the acceptance and move on. Pushing myself during depression stage would have been a mistake.

Let us not suppress our sentiments in the fear of looking unprofessional. We all have emotions - let's accept and normalize it so that we can process them and move on faster while minimizing our emotional debt.

Discussion (0)