Yesterday, I had to set up a demo environment for a project, we are working on.
Everything was okay, frontend loaded, connection to backend is working, database is connected.
10 minutes before I wanted to leave for my well deserved weekend, PO came over: "I can't play any video, I uploaded"
Okay, couldn't be a big issue, it worked when I added this functionality 3 weeks ago, just before my holidays.
A bit under pressure, my girlfriend Was already waiting downstairs, I inspected the database and realized that a table Was not properly filled.
Checked the backend and everything seems fine, so checked the requests from the frontend and realized that the request was almost empty.
So some code, building the request body had to be wrong.
Already 10 minutes late, with a lightly annoyed girlfriend waiting for me, I found the issue but couldn't recognize that I wrote these few lines. A quick check of the git history showed, that my colleage changed my code during my holidays, so I just reverted everything.
After commit and deployment, I called my colleage and told him that I just reverted his changes.
"But now my feature is not working anymore, I had to change it like this!" he answered. I just responded that we will talk about that on monday and look at it together. While I hurried down the stairs, I was thinking why the hell somebody just changes stuff without checking if it affects other functionalities?
This should be basic knowledge for every dev, that if you change existing, working code to make it work with your feature, you have to ensure to not brake anything.
If you can't do that, then create a new function to handle your shit.

In the end, my girlfriend had to wait 30 minutes, because of 4 lines of codes, someone just changed without thinking what else could happen...

  • 2
    And this, is why tests exist
  • 0
    @rgomez I totally agree, but if there's no budget for tests you can't do anything about it.
    Nevertheless everybody should be sure that he understands the code he's changing and knows the consequences of changing it.
  • 1
    "Not having a budget" for testing is actually the issue, I bet you things like this happen in your team on a daily basis, you are actually wasting time(aka money) debugging issues that wouldn't exist in the first place if you take the time to write tests, for example, I bet my ass off that the tests for that module that was changed would have taken you less than 30 mins to write.
Your Job Suck?
Get a Better Job
Add Comment