Never! Deploy! To production! On Thursday! *banging my head against the wall*
Now I need to revert some things manually on production ON MY DAY OFF 🤦‍♂️🤦‍♂️

So today, again, I discovered the importance of unitests.
I was solving this performance issue, in which we had a few update actions for multiple entities in mongo, but it took FOREVER to complete, even when I unified it into one bulkWrite command.
Since the unified write did improve performance slightly, and we wanted to move on, we decided to let this bug go.
So there I was committing my changes when I got a rejection from the pre-commit hook since I didn't have enough unitests coverage.
Ok, let's start writing some unitests.
Some unitests also needed to test the bulk write. So there I was comparing expected with actual result, and suddenly I got a huge facepalm.
Apparently some rogue for loop iterated all entities again for each entity that needed update. So instead of getting one update per entity, I got N identical update commands per each of the N entities 🤦‍♂️
Needless to say, fixing this fixed the performance bug entirely.
Thank you unitests and pre-commit hooks!

So today my pr needed approval. One of the lines of code created a unique ID using the uuid4 functionality.
I got a reject saying I didn't handle a case where I would get the same uuid twice.
Well, I guess it would be the problem of the developer working on my code in a couple thousands of years 🤷‍♂️

So I needed to go through a documentation of a program that was obviously developed by Chinese people, and went through some kind of Google translate to be in English.
This is an utter disaster: sentences that barely make sense, code blocks without a matching ending that cause the rest of the paragraph to be in the code block as well, code outside code blocks and without formatting, sentences unrelated to the section they're in, etc.
The program itself is great, but the shitty documentation makes me wanna kill whoever wrote it

I was working on a bug in a parser for the response from an api which returns 'n/a' when a certain measurement isn't available. The code was "if ($value == 'n/a')" and when this was true the value was rejected (language is php).
Some of you may instantly understand the problem here. I didn't. Some of the measurements were 0 which is ok, but for some reason it didn't accept them.
Then I discovered the bitter truth:
0 == 'n/a' is true!
Apparently php tries to convert the string to a number to compare it and if it fails it returns false, so false == 0

😞

So we had a service provider which would provide climate info. The service is paid for. Then suddenly we started getting irrational or no data. When asking the provider, he said their job is to provide the api and they're not responsible for the quality of the data which apparently comes from other places. So we basically pay for an api which we could have done ourself....