81
bzq84
12d

Me: code quality is important

Everyone: <no shit given>

Director: code quality is important

Everyone: yes, it is very important, hurray!

Fast forward few weeks/months...

Me: why this function accepts 14 arguments?

ShitDev: yhm, you know, we need to fix it... maybe

Me: why this exception is swallowed?

ShitDev: oh, really? yhm, yhm

Me: why this function is copy-pasted and repeated (20 LoCs)?

ShitDev: yeah, true, but we wanted to make it fast.

Me: Dear director, this project sux and its quality is shit.

Director: you're exaggerating, it can't be that bad, it works, right?

Me: <polishing CV>

ShitDev: got praised for delivery

Comments
  • 8
    god i hate people like that
  • 27
    Me: Why does this function accept 14 arguments?
    ShitDev: Because I was able to remove five that weren’t used in the body...
  • 3
    @platypus are you defending ShitDev? I did my investigation. I checked git history. It was 14 from very beginning.
  • 5
    @bzq84
    You never know how bad the code was before he cleaned it for the commit...
  • 27
    For management, I often use buildings as a metaphor for code.

    "Yes, this code works. The developer who made this created a beautiful gazebo, it looks truly amazing. But your land is a swamp, and there's zero foundation support under your new little garden structure"

    "So?"

    "Well, that means that you can sit in your gazebo on a starry night with a glass of wine and everything will be fine. At least for a while. But it might break at a critical moment. Like when you plan a party for all your friends. Scalability is important, also for your reputation!"

    "Yeah but we won't have that many visitors for a while"

    "It also means that if you want a new feature, like a couch or a BBQ, it might be too heavy"

    "So what are you saying?"

    "That until you let us do some foundation repair, we should basically consider the gazebo off-limits, except for essential visits. No more new features, no big parties, no promises to visitors."
  • 6
    Aside from the actual rant topic, those arbitrary delivery milestones always crack me up, as mentioned in the shitDev last reply. I could straight put a bullshit description in a ticket and estimate it to 20 story points, now implement it and make it work. I could also link it to a requirement as well as say what is the acceptance criteria. It still does not mean what I did was actually useful.

    The real question: how do you measure. that work being done goes towards the right direction? I swear nobody wants to answer it.
  • 1
  • 3
    @PepeTheFrog because it requires people who have idea what are they really doing. While management thinks they can hire bunch of random guys, and make it work with an agile.
  • 6
    The problem is that mfers think code happens quickly and magically, and some idiots realize they can hide their ineptitude by quickly (and sloppily) doing things.

    This job makes me want to scream sometimes. It's not the code, it's the asinine business culture and its unrealistic expectations of smart/skilled people.
  • 3
    @natesymer exactly my reality just now. Fcuuuuuk fcukkk.

    I haven't been learning good practices last few years just to do B.S. coding now, B.S. management politics, etc.

    This weekend I think nothing else but only how fcuked up next week will be... Damn it.
  • 0
    Reminds me of a legacy app I’m working on at the moment it sucks. But “it works”. The team didn’t even do any CI testing at all haha that’s the tip of the iceberg.
Add Comment