Do We Finish Work at 5?

Samuel Teixeira
4 min readAug 31, 2021

--

Sometimes we don’t.

Do we really stop working when we are not in front of our computers? For me, that’s not always true and this can be different for each person, let me tell you what happened to me last Friday.

So, I was working on an API endpoint that was not performing well and I was analyzing the code to see where I could change it. The day before I mapped the changes that I thought would make the response faster.

I implemented them on Friday morning, I was doing two changes: Caching a call that was duplicated and adding a Completable Future to call two processes and combine the responses.

The code is not the one for my company, but the call is similar.

I implemented the changes, created the tests, and ran a maven command to run the full build ($mvn verify). I had all my created tests passing, and all unit tests too, but I had one integration test that was failing. After the build failed I rerun the Integration test to get only the error message, the test was expecting a list with few items and the return was different, some items were missing.

I saw that some methods that were using my cache were working but others were not. I did run the first one that was failing individually and it did pass. Ok, I thought that I needed to restart the states before I start each execution, but analyzing the code I saw the class already had an After and Before method. Looking into them I was certain that I didn’t need to reset any state. It was late in the day and I could not investigate more. That’s the part when I left the work but the work did not leave me.

I jumped straight away to prepare some dinner for my son and could not forget the problem. When I ran all the tests in the Integration class I had a few of them failing but if I ran them separately it was all good. I started to wonder how could I waste time debugging a problem that is so simple, after so many years of working with programming and struggling with a simple test. Sometimes is hard to not fall into the imposter syndrome.

The weekend was quite busy, I went to the beach on Saturday and for a barbeque on Sunday, I did not have much time during the day to think again about the issue of the Test, not completely to be honest. Sunday just after I went to bed, I got myself thinking again about the issue. Usually, when I am thinking about how to solve a problem like that, I step back.

What did I add to the code that could caused the failure?

I knew the error was related to the cache because the error on the return was somehow related to the list that I was caching. So I realized the code that I moved to the cache was being called in each unit test of that class and after the first call, the next Unit Test execution would use the value cached, I needed to invalidate the cache at the end of each Unit Test. I was wrong and the clean-up was not complete.

This is not the real code, but the call was like this one.

The next morning I went back to the code and created a function to invalidate the cache, called it on the After method and everything worked.

Sometimes when I am working on a complex problem or when I can’t see a solution for a simple error I will be thinking about it even if I am not in my working hours. It’s good to work and be able to use my mind to find solutions to real problems but sometimes I want to disconnect from work and it’s not possible. This is not the first time and will not be the last, but at least this time I could find the solution.

Disclaimer 1: The code snippet share is not the real code that I was working on.

Disclaimer 2: I am working in a company called HubSpot, it’s on my t-shirt if you don’t notice, it’s a great place to work. This behaviour is not related to stress at work or the start of burnout, I am good I promise.

--

--

Samuel Teixeira

Developer (15+ years) | Staff Engineer at IAS | Master of Computer Science | Interests — Backend Dev , Machine Learn, Code performance, System Design