10
T0D0
11d

I really resent people who reduce the occupation to tickets. Our world is just tickets, tickets all the way down.

"well the ticket just says this, but that's vague, so what should I do?"

You either ask for clarification, or you get creative with the blank canvas you were handed.

"well that edge case wasn't called out in the ticket's specs"

this is _why_ we do TDD - to design our code to be able to function as expected for ALL cases

"is there a ticket to refactor that?"

what?! no, it's your job to always leave code better than when you found it (within scope/reason of course)

FFS we are not hired to be code monkeys or glorified typists. There should be joy that comes from getting to be more clever than the average bear and to solve problems and improve things with your code and logic.

shit bums me out.

Comments
  • 3
    I've worked in a couple technical areas in my career(s).

    The problem of people who don't think through use case or about the problem more globally, about side effects, etc is ... a global people thing. A LOT of people don't.

    However, it wasn't until coding that I found a place where people seemed to think you could some how 'legislate' such thinking via TDD, or change behaviors with stuff like Agile and so forth. It's kinda amusing.

    Still, I feel that rant.

    "I fixed the thing!"

    Bro... you fixed that one thing, what if they bother typing another character OMG WTF!?!!?
  • 1
    corporate whores
  • 1
    I both agree and disagree.

    Agree - if it's easy and requires common sense to walk that extra mile - then why not. You'll help someone out, maybe some other time you'll need that someone's help too.

    Disagree - there are 24 hours in a day, 8 of which are dedicated to work, another 8 - to sleep, 1-2 hours for commuting, 1 hour for the morning routine, 1 hours for lunch, 1 hour for supper after work. That leaves us with 3 hours of our own / family time. If you keep demanding that other fellow to do something that was not covered by the ticket and it's time-consuming, you're using up his personal time - those 3 hours he's got. That's because you're adding another work to do in his already tightly planned work day's schedule, which means he'll have to sit in overtime to complete all his tasks of the day. And that's unfair. OFC he could ask for his manager's approval and fill in the OT hours, but that extends the total time and effort required.
  • 7
    If I fix something that isn’t in the ticket I’ve been assigned, I get yelled at.

    If I file a ticket for something, fix it, and send it off to review, it doesn’t get reviewed or merged because nobody cares.

    It’s stupid.

    To make matters worse, the favorites can do both of these and are applauded for it.

    It’s fucking stupid.
  • 2
    @netikras totally feel that, which is why one absolutely needs to consider if it is indeed within scope or reason.

    I certainly am not going to harp on a teammate for a design/implementation choice if it reasonably accomplishes the task and doesn't glaringly add to tech debt

    But also, if you just copy/paste code from another section of the app to "get it done" without bothering to discover that we already created a utility or component or extension method to handle that issue, I'm not gonna just let it go.

    I'm sorry if it's unreasonable, but I expect my peers to use their goddamn brains in this occupation.
  • 0
    @Root Yeah some folks have been taught or are forced to operate pretty conservatively in their job.

    That sucks.
  • 0
    I see your complaint ticket, but unfortunately, you're not approved to work on that project code 😞
  • 1
    @SortOfTested JFC don't get me started on that...

    "Hey did you make those changes to the Published Language package yet?"

    "No, sorry Jeff was busy with the pipelines all day"

    "Do you mind if I make those changes then? I have have a PR ready in about 30 minutes and it would unblock me."

    "Mmmm... yeah... I think it would be best for the developer who started that project to be the one who modifies it; that way no one gets confused or mistakenly adds something they aren't supposed to"

    🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕
  • 1
    I think this is not exclusive to the ticket workflow, my teammate and I work by feature and the implementation is up to us, when he says he has finished something lead and I review it and there’s a bunch of flaws, mostly on the front-end and back-end is shit, then we have to point out those evident flaws one by one and he will fix only those that were pointed out and no more. Then instead of proactively looking for more flaws he will ask something along the lines of, that’s it? anything else?
Add Comment