this post was submitted on 12 Jan 2025
1404 points (99.3% liked)
Programmer Humor
19965 readers
1199 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
UNIRONICALLY, ASSHOLE! IT'S THE FIRST THING YOU SHOULD HAVE DONE!!!
Fucking "hey guys, we are bringing in someone from another department and they need to catch up. What's the project looking like?"
"I don't know. Nobody wrote anything down and now it's scattered across six didn't PCs in various states of dysfunction."
IT guys think they're all Michael Jordan right until they get the ball.
There's an alternative to creating too many tickets that only add overhead and then make it harder to get into the project. Creating a good amount of tickets.
I took the OP reference as demand for ticket creation when they don't make sense and only hinder development through unnecessary overhead. E.g. creating a ticket before a quick analysis, or creating individual tickets when one story/feature ticket would be enough. Or more specifically in this case, having to create one before fixing a critical blocker.
I get the message here for sure, but imo tickets (while important) take a back seat to a rich commit history. Ifbthe commit messages and history are high quality enough, one can tell whats up with the code sinply by looking at the log.
Tickets on the otherhand are in a secondary system. Of course, they can bind the work of multiple projects together. But honestly, has anyone ever been able to just reach the ticket history and know everything about a project without asking someone?
I've found people who do one will manage the other with ease. But "oops! No ticket" is a canary telling me their commit log is going to be shit.
I've been able to find out the status of individual half-finished bugs off a ticket log and work/reassign it quickly. Without a ticket in queue, I'll either discover the issue has been completely ignored or that multiple people pioneered their own boutique fix without talking to one another.
Problem in some teams are the respective audiences for the commit activity v. the ticket activity.
The people who will engage on commit activity tend to have a greater common ground and sensibilities. Likely have to document your work and do code reviews as the code gets into the codebase and other such activity.
However, on the ticket side you are likely to get people involved that are really obnoxious to contend with. Things like:
In a company with armies of project managers the ticket side is the side of dread even if the technical code side is relatively sane.
Haha, i'd write a thousand pages of documentation before entering ticket hell. I fact I do put a lot of information into the ticket - they still won't read it though and i'll have to repeat myself 15 times to 5 different people.
The solution to this problem. . . I have no idea, but I'm sure they'll appoint another delivery manager who will get hired by the ones who already know fuck-all to know less than them.
I've found that the few managers who want documentation, get documentation, and the others who want tickets and "story points", get tickets and fictional bullshit - in general.___
Don't know about solving, but at least can see the signs:
is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)
The asteroid would have wiped us out before you guys finished this long ass conversation
Let's put a story point estimation on that. Then we can extrapolate time range and risk.
Thats an astute observation. I really cant refute that haha.