When I got a hand from Sherlock Holmes to help a peer in his problem

Software Engineering & Travel Journal

This week one of my peers was facing a problem with one of our APIs. He pinged the infrastructure team in Slack warning them about it, saying the API was broken.

Another peer of mine, Juan Maia, who’s an awesome engineer pinged me in private, dazzled by the problem.

_Thiago, are you aware of any problem with the API? As far as I know, it is working accordingly in Roku (the platform I’ve been maintaining). It is not possible the API is broken if it’s working in another platform.

When I checked the feature once again, it was indeed working. Juan was right, how was possible it to not work on web then?

I remembered that I got a cookie problem with the API before, months ago, while implementing it in BrightScript. But my other peer followed the discussion back then, he would probably know to check his cookie implementation. Nevertheless, he was still facing problems by using the API. I replied on the Slack thread and asked him about how he was dealing with these little bastards (🍪!).

_It should work on web, right? That’s not possible!

That’s when a citation from Sherlock Holmes, written by Arthur Conan Doyle, came to mind. A quote that I carry on with me while search for root causes for problems.

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.

I copied to my peer the same quote and asked him to check the obvious first, before discarding this option.

The problem was, indeed, cookies.

Software Engineering is partly an Investigation Job

How many times did we face a problem that seemed so weird it could not be possibly happening in normal conditions? No server down, no crash found, logic written at perfection . But yet, the problem happens and we feel confused.

My primary maneuver is always to check the obvious first. Sherlock taught me that. Once you remove the impossible, whatever remains must be the truth.

If a cookie policy is impossible cause to a problem, why not to test it first? Often when we don’t know the cause of a problem, it’s better to start with what we do know, to test the perfect scenario to be sure it is still perfect, so only then we start to dig up more creative possible causes. This technique already saved me many hours of bug investigation.

About The Author

Thiago Ricieri

I'm software engineer at Pluto TV, working on iOS, Android and Roku platforms. Personally interested in machine learning, algorithms, data science and tech industry. I travel a lot and take good pictures.

Add a comment

*Please complete all fields correctly

Related Posts

How IoT, Blockchain, AI, Machine Learning and more trends will shape 2018
The year has begun, and many topics keep getting attention from the community. You probably have stumbled with some of the following trends Gartner, HubSpot and Forbes. Check it out!
Anti-Patterns by Example: Premature Optimization
Donald Knuth wrote this quote back in 1973, and for over forty years software engineers have been debating its validity. Is it still applicable for nowadays?
Services, Content Providers and MVP pattern
This week I got myself wondering when would be the best practical cases to use Services, Content Providers, and Model-View-Presenter pattern. Although the SDK Documentation provides a recommendation on when...