69

This is so fucking relatable.
Everytime there's atleast one dumbass in the organisation who frequently does this exact thing.

Comments
  • 8
    It's valid critique though. If there was a problem and you fixed it without making a fuss, you might only get acknowledged by the people directly looking at your work, or not at all.

    P.S. And I'm not saying "do make a fuss out of everything", but at least make anyone responsible for the problem (if it's not you) aware of it - even if you fixed their fuck up.
  • 0
    Yeah, it's obvious to celebrate only when you solve the problems made by others or teams!
  • 0
    They do the right thing, to get valued LOL
  • 3
    Fixed 800+ line shitstorm by refactoring it down to concise, readable and reusable 86 lines of short lean code.

    I documented and addressed much bigger functional issues that nobody knew existed and fixed those 7 unknown bugs(regular ones, not edge case type).

    Still got scolded as I was supposed to do one other task with very low priority(noted on the task) where something was off by 5 pixels on iOS.

    So 6/7 tasks done in sprint was not good enough.

    The other guy slapped 3 sloppy fixes in one sprint and I am pretty sure he was the one who produced that 800+lines monster and was praised for doing good job.

    I decided that it was feck this shit o clock and I left!
  • 3
    Sometimes when I fix a hazard which won't get noticed I add a ticket as a new issue, and set it to Resolved a few minutes later. Just to make sure it doesn't go unnoticed. 😁
  • 0
    @jiraTicket this is my approach too, often they're easy complete tickets :D
  • 0
    anyways, such a great illustration designed
  • 1
    He also started the fire
  • 0
    Yeah. I writing untested code and no using modularity and reusability creates these type of shit. Deadlines are just suggestions not fucking rules to skip good code.
Add Comment