ProgrammerHumor
pleaseGiveMeYouTicketNr
Discussion
I both hate and understand this...
And it extends so far beyond programming, too...
Why do they keep sending me emails instead of just submitting a ticket? Are they stupid?
There tends to be a self-reinforcing phenomenon where management and tech leads do business by email, out of band from any ticketing system, and emails are implied to be higher priority than tickets. So it becomes expected that sending an email is a de facto way to get something done quickly without the overhead of a ticket.
If a requestor has the right personal connections to a manager, then they can use this to get in touch with engineers directly and leverage this as a “fast pass” lane to get work done and are rewarded for it.
Except when all of your KPR's are ticket based and you get literally shit-all for credit at review time for doing tasks that upper management sent you by email only and all you get asked is what all of those unallocated hours went to.
"Your KPRs are you're problem. This is my problem"
"exactly, so if you want your problem to be my problem, then you make a ticket"
I'm aware of KPI (Key Point Indicator), what's the R for? Key Point Regurgitate?
Key Performance Result or Indicator or whatever. Whatever it's called, if it's how HR quantifies how well you're doing, no one gives a flying shit if you did something really awesome that doesn't fit into it when review time comes around and it's time to talk bonuses or raises or even whether you "met expectations."
Gotta play the KPI game.
It pisses them people to no end when I refuse anything without a ticket but at the end of every quarter I have a paper trail for everything I did and I am bulletproof.
I just intake the email into a ticket? I don’t understand. That’s just good service. Copy paste email into ticket description and work it, follow up via email.
As always, it depends on the organization. Your typical bureaucratic org sees that you were both the ticket creator and the assignee, demands to know why you were doing internal work instead of spending those hours on something important. But of course, God help you if you don't follow up on that email.
and then if you don’t create a ticket you have a bunch of unassigned hours which makes them eat you alive at KPI
I worked with a guy who was, frankly, a bit of an asshole. He wasn’t that bad but was rude.
But he no issues being a dick to sales for not making a ticket, or making arsey comments to them. He had no issue pointing out their low effort support requests either. Soon, it turned into one of the best support channels I’ve ever worked with. Sales themselves, would write full steps to replicate bugs customers had found. Thankfully the guy became less of an asshole.
I’m not defending or recommending rude behaviour. It was one case it worked, and primarily because everyone privately knew he was right. Changing culture at places can be very difficult, and this was one way we managed to push people to change.
Setting expectations doesn't make someone an asshole. Of course, this person may have been doing it in asshole-ish way, but politely saying "hey we need more information and we need this tracked in the proper channel to make sure nothing falls through the cracks, please make sure you do that" should be seen as behavior from a good employee, not as asshole-ish
You are right. For this story, he wasn’t doing it in a polite way. He would do it in a very judgmental way, putting people down for not doing their job right. Really calling them out.
I literally just forward their emails to our ticketing system lol.
Didn't the requestor become you?
Yeah but I just change it in the ticket.
Ours is just smart enough to know (most of the time) to attribute a forwarded email to the original sender. That might only work if the forwarder is an agent email address but I'm not sure.
It's NOT smart enough, however, to recognize a vacation responder even though there's a specific toggle in admin to catch them. Pretty annoying during the holidays when the poor intern has to cc their multiple vacationing bosses to "keep them in the loop".
Very simple fix. When they email you say- why sure! I'd love to help you! Just give me the ticket number and I'll take a look at it.
Pushback? A ticket really helps me keep track of changes and communications.
More pushback? Tell them I deal with 50 problems a day. Tickets help me keep track of them all.
My manager spent a year trying to get us out of tickets. But they didn’t want emails either. Eventually they realized how stupid this was. 😒🙄
Vibe-based troubleshooting.
In my experience, people do this because their tickets get ignored. Either that or because nobody showed them how to log one, or in one case, because the system was plain inaccessible to half the company, IT was informed but just told everyone that it was all working.
I've pretty much had to tell my team to ignore emails unless we bring up the topic during a stand-up or other meeting. Too often someone get a dev's email address and think that they can just go to them with all of their problems directly.
I try to set the standard with everyone that an email means a reply in few days, a chat message means a reply in a few hours, and if you want to get my attention immediately... Call.
I find that the barrier to call is high enough that most people will just say that their problem isn't as important anymore and can wait a few days.
I've never worked at a place with a ticket system, but I'd imagine that doing both would be good. If you make a ticket and then email me saying ticket #23487 is urgent can you please take care of it ASAP I'd be more than happy to prioritize it.
No ticket? No work.
Nah, just need to add a culture that email has no sla
I totally do this and didn’t realize until now…
Why don’t you just set up tickets based on email?
That is how its set up. They send the emails to me instead of the ticketing email.
I just forward their emails to the ticketing system lol.
you can do that? what tool do you use?
Zendesk.
Being freelance with my own clients, be happy they email instead of call.
...at 4 AM.
He was surprised I answered, he just was planning to leave a vm. He was a bit of a pain.
Or calling my extension instead
at least emails I can forward to the support mailbox with a "here, you accidentally sent this to me instead of where it belongs, Ill take care of it for you this time".
But an unprompted teams DM can seriously just fuck itself right in it's goddamn ear.
The ticket system keeps asking for pestering little details like "Which system isn't working?", "What are you trying to do that isn't happening?", "What error messages have you seen?", and "What steps have you already tried to rectify the problem?"
They'd rather send an email that only says, "Please come fix my stuff." with no further details. And you're damn lucky if they included the "please".
That's IT not programming though. In programming 90% of the time they just want to 'ping' you to 'remind' you that they have something in the queue as if you arent working and there rent higher priority tickets.
My job is particularly bad at educating non devs about the Jira queue and people really think the devs just don't do anything or choose to work on random things.
Hi yeah a client asked if we have implemented the feature to change one specific letter to a 7 sometimes maybe, they are chasing, is it done? Any ETA?
My company has soo many teams and soo many pop up apps that all may have their own tickets. So sometimes it easier to just find the code base, and email or message the engineer directly instead of finding their arbitrary link to internal ticket system in confluence.
Just setup a script to auto-parse them into a ticket.
If only I had the perms :(
just automate a bot that creates a ticket for them when they send an email
I used to work in a small machine shop. "Just" was the scariest word in there.
Guys would wander in with a personal project they wanted faced for $20 or whatever, "All you have to do is just ..."
sorry bud, its $100 minimum cuz I got a setup on the mill already
I work in surgery. I’ve had to call engineering for equipment problems in the middle of an operation. I really really don’t like being asked for a ticket number in that situation.
I just hate this. Our IT is like that, and they aren't exactly stellar.
It's a way to protect a limited asset, the problem is when it starts to become a ticket for the sake of tickets.
As soon as the bureaucracy starts to entrench it's game over because you will get people that want that to justify their existence.
The distance between "protecting a limited asset" or otherwise actually making those tickets to help manage things, and the point where it becomes tickets for the sake of tickets is way shorter than i've used to imagine, though. Unfortunately.
I have the opposite problem as a QA. I create very detailed bug tickets and the devs are always trying to hop in a call with me to talk about it without even reading the ticket. So I always say 'read the ticket first, if you have questions, please send them in writing or add a comment. Then we can look into a call if it's required.'
I have a similar problem except I don't feel comfortable enough to say it.
As a dev, you’re doing the lord’s work. Cannot tell you how many tickets have been lobbed at me with, like, a sentence. No screenshot, no video, no steps to reproduce, not which account, not even an indication of the goddamned environment.
Yeah that sounds unacceptable to me. I would speak to your QA lead, tech lead, or project manager or whoever have authority and see about setting up reporting standards or at least a best practices document that you could send to a QA member if they send you something shitty. In the same way I wouldn't accept an incomplete feature, shouldn't accept incomplete reports.
Ha, QA member.. I remember those..
Look at me. I'm the QA member (and dev and ops and release and support and...) now.
"It's broken, please fix as soon as possible!"
“Selecting too many options in check box list crashes the response.” This is verbatim. Which check box list? We may never know.
team lead powers: activate! Huh, time to ping the PM and "ask" why this POS ticket has been sent to my team. Aaannnd it's back with the QA who raised it until I'm satisfied it's detailed enough and there's going to be a follow up call with the PM, COO, me and head QA to clarify why they keep wasting dev time with this crap. Excellent stuff. (This actually happened last week, except it was a BA not knowing how to do their job rather than a QA.)
BA?
Bug Assurance, they're the one putting all the bugs in the code so QA have jobs.
Business analyst
Business Analyst
Problem title: "Broken"
Problem details: "I tried to use the application and I got an error."
Priority: "Critical"
Actual issue: User accidentally zoomed in the browser window.
/two minutes after being filed:
Closed: Cannot reproduce
We had to change our no access login error to bright red because people didn't read the message when they couldn't get in. But they still sent us screenshots of the red text anyway.
Which is why everyone calls the person who submitted the ticket.
The number of 'please create a server for <Environment>' Tickets i got. With no indication of which customer, application, name, use-case, hardware requirement or software version requirement is insane. Gotta pull all that out of their nose (is that a saying? it is in my country)
"Could not reproduce." *closes ticket*
I have always appreciated people like you as a dev. Having detailed tickets is a blessing.
I'm not sure what's wrong with some of my devs tbh, I've only gotten complaints that the tickets have too much info, they just want a few sentences. But I'm adding details for future reference of testing as well, not exclusively for their reading.
I even include a "Summary" section at the top that explains the issue in plain English, 2 to 3 sentences; how I might explain it in conversation first before going into structured details. Some of them still just don't even try to read beyond the ticket title. It truly baffles me.
You may be writing too much? Good developers are busy, have short attention spans, and lazy. I spend quite a bit of time with new QA team members (and new developers) teaching them how to update tickets succinctly. Do your explanations fit on one screen? And are they bullet points rather the sentences? (And not the dreaded bullet pointed sentence.)
Better too much info than just 'hey, this thing isn't working' without any context or anything, that's what I am dealing with currently...
I wish I could have you as a QA.
Mine only poke me on teams with "hi, I have a bug, can I show you?" even after telling them to just open tickets
If your company is hiring, let me know, I'm trying to find something better paying and with better tech culture
YES! Enforce documenting questions.
Some of the most useful fixes I've ever seen were on FLOSS projects' BBs of the back and forth. And those people weren't even getting paid! It's amazing what happens when you don't have a phone number to fall back on and actually have to, you know, communicate.
And here I am getting tickets with ni text in them, and titles that barely suggest at what the ask is.
People always forget about regression! It's not just enough to have a notice about a bug and then fix it. You need a history of bugs, and a history of fixes. Sometimes you have a systemic issue that keeps popping up and will be continuously hotfixed unless you can look at a trend of behaviour over time, and then you can diagnose the underlying cause. All conversations about defects should be in the ticketing system.
I personally like to chat as it gets me up to speed quicker. Can easily take 15 minutes to understand a bug that could be demoed in 30 seconds.
I love loom for this exact reason.
I'm on the dev side myself and we have two QA meetings a week. The QA team goes through everything they've found and we decide in real time if each finding is worth a ticket. We include someone from the product team, and two from the engineering team to set priority as we review it.
At the end of the day, having issues prioritized by a combination of the product and engineering teams seems to add a lot of credibility to the tickets, and we get less sass from engineering as a whole. Plus, questions typically hit the engineer in the QA meeting so that you guys don't get kickback.
It works for us, but I'm always interested in picking up better habits
That sounds really heavyweight to me. Big meetings like that are very expensive to run if you consider the hourly rate of everyone on the call. It doesn't scale well with large teams either. I'm in favor of always making an actual ticket, actually document it the bug (i'll just bounce tickets if they don't have logs attached), and follow up 1:1 as needed.
Lol I have a similar problem, I'm only do QA for the UI because my company is cheap and basically put people without knowledge as QA for web, I write everything in detail on how to reproduce a bug, attach videos, notes if necessary, and yet now they expect me to include what part of the backend broke it.
Brotherman I don't know what the heck the UI does with the network, I just click things and sometimes it breaks, plus I'm the only QA, I have to attend three different chats about my bugs at a time sometimes
That's odd. As a dev, I do anything possible to avoid human interaction.
I could be guilty of this. Constantly communicating in writing is just too annoying. I also believe that people tend to overestimate their own communication skills. Often writing in ways that can only be followed if you are officially educated in that exact area. Have you ever tried to ask for feedback on your tickets from the people that keep calling? (Or they are just not reading ofcourse which might be a question to ask as well. Why not read the damn ticket?)
They simply do not read the ticket, just the title. I take logging bug details, steps to reproduce with screen shots, videos, test scripts with logs in exact point of failure, test data used, etc. very seriously. It's my job. If there are ways I can improve I'm always listening, and I'm not opposed to hopping in a call but if I spend 10 to 15 minutes writing a detailed buy ticket, I do not want to spend 10 to 15 minutes repeating myself in a call just because the developer couldn't be bothered to read the ticket. I'm happy to provide clarifications and such but I expect team effort, not laziness.
Hence my rule of "please read the ticket first." If they have, great, let's hop in a call. I'd sometimes prefer that over back and forth messages.
Sounds more than fair. Have they ever given you a reason (or bad excuse)
Not really, in my opinion they just have shitty soft skills like communication and being considerate of other people's time. I don't work at a super high end company, it's insurance adjacent so I know they're being a little underpaid and so am I, so it is what it is. But no, they usually just say "oh okay" and then read the ticket like it never dawned on them to do that first.
Hope for you that they will learn it one day.
Learn to respect other people's time. As a swamped senior dev, if everyone called me that wanted to call me, i'd be on calls 10 hours a day and have -2 hours to do real work. The QA OP is doing the lord's work, I wish my QAs would be like that naturally.
I find calling to be the most efficient way to save everyone's time sometimes. If i could properly formulate the question there would often be ways to solve the problem without your help or it would end up as a simple fact question. I try to have the minimum amount of contact so i use that same call to make some rules for further contact when it comes to people from my team. Inside my team i will then fight for your time and have people communicate by the rules (that only works if you actually talked to someone somehow). There is just too much confusion when it comes to text based communication in my experience.
If I had a dollar for every time I had this talk with my manager...
"Hey, XYZ from sales told me about this bug that still hasn't been fixed in months"
"Do you have a ticket number?"
"No"
"ok, let me check XYZs open tickets.... Nothing. Let me check the closed ones. Still nothing. Can you ask XYZ for the ticket number?"
"Ok"
Five minutes later...
"XYZ said there is no ticket, he told dev department about it"
"He told whom?"
"He can't remember"
"Well, if he'll create a ticket we will handle the issue if it's on top of the queue".
Doesn't happen often, but it happens. And maybe he really told someone at the coffee machine but without a ticket you can't trace it down.
On a side note: OP, I noticed your username. Brandi, is that you?
I recently asked a question in our dev forum and their SVP joined the discussion after they realized it may be a bug and told me to create a ticket for the issue. I immediately created a ticket and sent it to them. 4 weeks later I asked the product owner if we could get some attention on because it is affecting the customer directly and he told me they don’t review tickets and I need to create a ticket for support who will then escalate to them, even though his SVP told me to a make a ticket for his department. So I made a ticket for support, who will not even open it for 4 more weeks and it will be an L1 from the South Africa time zone who will not escalate for another week and then 4-8 more weeks will go by until the dev team looks at the ticket at all. It’s a great system that has no documented rules and when I try to document them it turns out the policy changes on a whim anyway…
Can't blame you if you try the direct approach. Sounds like a complete nightmare.
3 months waiting later on a issue that takes actually a minute
Except it's never actually a minute. It might take a minute to ask a question, but the actual resolution taking a minute is rare.
I'd say it really depends on the issue and who tackle it, because I sometime fixed issues in less than a minute, the real issue was the CI taking 10 minutes to run
It can sometimes take an actual minute, but they're normally the questions so simple that a quick search would have fixed it for them anyway.
If they knew how to search, why are they paying me?
Sometimes you just need an admin to change a simple setting which is locked
Half the time I could do it in 2 minutes if I've got the access. Just gimme your standards docs and change procedures and I'll get it done.
But also... yeah I get it.
And even if it does take a minute to fix, you gotta go through change control
"Turn it off and on again, dipshit."
There, one-minute fix.
These tend to be the "look, I just need this port opened, it'll take 5 minutes in the firewall." type issues.
Which is technically correct, it would take 5 minutes, but then the production database with sensitive medical information in it is accessible to the world.
Working out how to do it properly, and getting people to sign off on the solution takes a couple of months, and some back and forth to work out what you actually need to do, so we can solve it in a different way.
Either that, or it's a pain in the arse and you bothered me late on a Friday, so I stuck the low priority tag on it and hoped you didn't care enough to take it up with my manager.
In that case it is necessary to have a chat as the requesting party has no idea that it will take longer than a minute. Hearing the request and then sending them back with new information is sometimes vital to them not just gambling on how long it will take.
Yeah, the solution to your problem might only take a minute. And yeah, it is the best practice solution. But it also first requires clearing months of technical debt because it breaks a critical outdated component that needs to be updated and tested first.
So yeah, we are aware of your problem and we are aware of the simple solution. But we don't always have time to explain all the spaghetti.
I had my secure USB drive stop responding. I was convinced I just forgot the code, so I took it to the help desk. They used the admin code, and it still wouldn't respond. He literally says to me "we have them in stock right now, so just put in a ticket and then it will only take a few minutes to get you a new one once the ticket is approved". I put that ticket in (and got the approvals) about 2.5 months ago. I have followed up multiple times through the help desk directly and through the ticket system, and have not made any progress on it. I have tasks I can't do without it, so those are just all on indefinite hold.
Let me guess: you've never had to field a "actually takes a minute" issue from users?
If your tickets take three months to resolve there's a problem
I used to have a policy at work that I would not answer any DM‘s on Slack for support. If someone tried to get DM support I would make them post in the support channel for our platform. Then I would respond to them in the channel.
Half the time they never even had to post because as soon as they joined the platform support channel they saw the automatic solutions to one of the top three issues they were having.
Kinda unrelated but I get so annoyed when I need to get support but I need to click through all of the “Read this article to find help” or “look through the FAQ’s”.
Unfortunately (or fortunately?) I already did the basic debug steps and whatever I’ve got is unique enough or I’ve royally screwed something up enough that I just need to talk to someone, not get put on the automated support merry-go-round.
Nothing against what you did though, I’m sure the “Read the article” type steps weed out plenty of people to be worth it.
I use a support forum for a company who has quite a good solution for this. As you're entering the details to log a ticket they search keywords from your subject/description and in a sidebar they suggest solutions from their KB which might match. You can ignore them and carry on creating the ticket, but sometimes it throws up something I might have missed.
Jira’s service desk does this now, works fairly well if your articles are tagged properly
I was a sys-admin back in the late 90s. We had a policy that if someone came in to our office or called us, we would walk them through filing a bug. Then there were the people who would file a bug, and then want to come talk about it in person. The dumb is infinite.
the modern equivalent is filing a ticket and then 3s later @ing the whole slack channel about the issue they just filed
Was also first line support, then sys-admin in late 1990's. We explicitly had tech support people in a locked closet to work on things so users could not waste their time. Oh yes, we had someone at the desk out in the open, but they were more often than not akin to the defensive line in American football.
Mate when I was a network admin I had someone send me an email, then print the email and bring it to me to discuss it. Not becasue I was taking a long time to get to the email or something, it was immediate.
It's not because time. It's because traceability.
If it's not logged, it can be used against you as if you did nothing and wasted your time. As if it never happened.
- Always log your work
- Always log the decisions made
- Always keep a copy of any important verbal instructions, transcribing them via email or written message, confirm with your direct superior
- Always confirm with your direct superior their decisions and make sure you understood anything critical
- Always confirm via email if something is unclear and ask in writing, don't Teams, Slack or voip, ambiguity doesn't protect you, but puts you in danger.
- NEVER accept poorly defined tasks; ask for clear objectives, deliverables, and deadlines.
- Always document your part and report if something goes wrong. Silence is seen as guilt.
- NEVER expect effort to speak for itself: what isn't visible doesn't exist. No one will defend you.
- Always keep backups of your important deliverables, preferably off the work computer, to avoid them remote access, blockage or deletion.
And the most important thing: - The company is not your family - HR is not for helping you, is for helping the company - The primary goal of the company is to make money, not to help you - You are disposable - You can always search for a better place, don't marry any place, loyalty isn't worth your mental health
Hell, as a solo dev and IT guy, my most useful notes follow the format of any good ticket - I have a list of "tried this; result" that I can search. It also helps keep me on track and not to "dissociate" after many hours trying to solve something
It is sad that we work in environments where there is so little trust that we have to put in so many processes. Not blaming you, but management.
You're absolutely right. It's unfortunate. At first, I trusted, but as you learn how the corpo world works, you trust less.
Hey, if one of your metrics / KPIs is tickets closed or points, they are asking you to hurt your numbers.
Plus, how do you know I’ll be “done in no time”? I don’t do YOUR estimation for you.
And they proceed to create a ticket with barely any relevant information to locate the issue.
Honestly... It's dumbfounding
Title: problem
Body: voiceRecording42069.m4a
Closed: Cannot reproduce
If it takes me less than 5 minutes to read your ticket, this is probably the correct response.
How are your tickets taking so long to read?
Link to the issue -> 3 to 5 steps to reproduce (total reading time like 10 seconds)
Alternatively, just write an AT
Now show garbage can filled with tickets that you put them in….
That's not fair.
You always close a ticket with (at least) one of the following perfectly reasonable explanations:
- Closed: Cannot reproduce
- Closed: Fixed in latest version
- Closed: Wontfix
No ticket no problem
Create a ticket. Actually add the necessary information to the ticket. No, I don't want to immediately discuss the ticket after you click on create. When I ask a question for clarification, consider if you can write me the answer and if getting me on Teams or whatever is really necessary. Once I am actually working on your ticket, please don't make me wait a week for an answer to a (written) question. After I am done with your ticket, you have a window where you can actually respond. If that window passes, the ticket gets closed. Don't come to me to complain that your ticket was closed and you couldn't be bothered to actually check if everything is exactly as you wished for. Reopen the ticket or make a new open, I really don't care, just make sure whatever you want is in a ticket.
The very fact you are basically avoiding direct realtime communication would automatically discourage the other side from giving you prompt, detailed answers, and being quick to respond. I'd hate working with you.
Don’t worry, I am not in a role that works with tickets, so chances are low you’d have to work with someone like me!
I was more describing what I’d want the ideal scenario to be when I have to work with any sort of help desk. Because too often, for example with MS, they immediately want to jump on a call when I have provided them with very clear reproduction steps etc instead of simply providing me with possible solutions I can try async. So I am forced to jump on these calls which 9 times out of 10 end up wasting my time. And theirs. Because the first few solutions usually don’t hit - I wouldn’t have opened a ticket for something simple - but I still have to dance and pretend.
Having to work with a system like that sounds like a horrible experience. Sounds like you eventually will be having people that give up on the ticket and blame it on your department. You really need someone who can streamline that kind of communication if you are strict like that.
Open the ticket to their TL, CC my TL, put minimally required info inside, forget about it until actively reminded about it, cause duck this. Glad we don't have people doing this inside the team.
It indeed sounds like a bad place to be in.
Not too long ago, someone was debating with me, saying email without a ticket to "a different team" is how they operate and shall continue to do so. I was like, you nuts?
"I'll write a ticket, I swear" "You are so much faster than the support hotline" (never give people your number, when you're job is to help them!)
We have a chat system. It really irks me when people open a chat. Then follow up with. Call me. No duck face call the help line if you want a call.
I know there’s a reason for this but this my blood fucking boil. I have to work in production systems directly with clients and have 0 access to certain systems on the servers and all I fucking need is some information at the SaaS teams fingertips and they WILL NOT do anything without a ticket and will wait WEEKS to respond to any ticket, meanwhile the client is getting absolutely furious and we look like huge assholes dealing with angry clients constantly while losing revenue because of it and the cloud team never has to deal with the customer once.
I love those loops where you wanna get some sort of integration/dependency done with another team, but you don't know exactly what yet without a discussion with said team, but said team completely road blocks you at every turn because you're unable to tell them exactly what you want. So then you spend however fucking long trying to convince these people that you need to have some sort of discovery session with them.
It's always the blokes that have been part of the same team managing the same platform for decades that are bitter and disgruntled and it's utterly insuffereable.
But also I get it.
I'm a bit new to programing and everything, what is a ticket? What's it used for?
"Tickets" or "issues" are the IT/SWEng domain term for "a lack in the system I would like addressed." They typically fall into either the category of "bugs" (unintended behavior) or "features" that one would like to see added.
The problem is that many users are incompetent at communicating these, and on top of this, many IT/SWEng have their performance based on how many tickets they close.
If used properly with effective ticket/issue tracking software (this is a whole other topic of discussion: ticketing software, and how many of them suck total balls, either for users, IT/SWEng, or both), searching for previous solutions, or even recognizing trends can become possible. A well organized (i.e., containing tickets that are well-communicated) ticket/issue collection, and low friction software can be a very powerful tool for organizations of all sizes.
when you care a lot about the management of work you implement methods to track it. over time these methods become more important than the actual work.
I alway reference the ticket number in my commit message to git. Using the "Autolink" functionality in github it will automatically link the commit message to a Jira ticket. This is making the git commit message a summary and the link will guide me to the whole context.
When the IT help desk finally asks for your ticket number
Because when you don’t get a ticket and address the issue the same asshole who would ask you to do something will say you didn’t create a ticket for this
When you got paid by tickets. /j
But seriously, using tickets is actually really helpful for tracking anything that happens in the system, instead of chat. So, if someone has a complaint, they can simply be told to refer to that number.
Tbh I hate the people who demand I create a ticket for them to review a PR.
At my previous job our platform team would release a code with a bug in it. I'd report the bug and even include a PR to fix it, sometimes with a unit test, and it would still take 2 weeks to get prioritized. By that time the PR would have some dumb merge conflict, so they'd send it back to me to fix their shit again. God forbid if you had an actual feature request, even if you had 3 tech leads requesting the same thing you'd still have to go through multiple arguments because the platform lead doesn't think it's necessary.
Back in the day when I was working desktop support my coworkers and and I talked about how the employees didn’t realize the power of a ticket. Once a ticket goes in the clock starts ticking. You can walk up and ask for help but you’re not getting any until the que is cleared.
If it's not documented, it didn't happen.
This is also good for your weeklies (and monthlies, and quarterlies . . . ) to show what you've been working on.
It's also for your own sanity to keep track of the dumpster fire(s) you are in charge of, and also so you can answer the question at the end of those days of "WTF did I do today?"
And yeah, being able to search for solutions to something that occurred years ago, to save yourself time and frustration.
Life would be easier if everyone just accepted that all other departments are only there to support IT first line service desk.
Trying to take away my credit on jira?!?! Hell to the nawwwwwww 🤣🤣🤣
what is this meme template from and why do i hate both characters?
Cristiano Ronaldo’s Wife was getting interviewed, and she was lying about how wealthy her childhood was. Ronaldo came in and called her out on her bullshit.
thanks
Not sure if you're kidding, but that was David Beckham (and his wife).
In my company, you create a ticket, wait a week, then contact the manager of IT. Very efficient system.
Apparently another way is going to the office to their “open hour” to push your ticket directly face to face. But since I don’t go to office…
'thats not what i asked for'
we had a bug that the devs didnt want to fix. so when the ticket turned a year old we threw a surprise birthday party for the bug with cake and invited all the devs and management.
next year, just before the next birthday, they fixed the bug
Okay, this one might actually be worth keeping for future replies / bots
This looks like IT joke
Based on my experience with my corpo's IT, the obsession over tickets is really just a vehicle for dismal service.
Create opaque, undocumented ticket system
Refuse to talk to anyone unless they submit a ticket
Never get any tickets and so never have to actually do anything
The ticket categories and fields were truly impenetrable. On multiple occasions I tried to reach out to the teams to get some sort of clarity on their categorizations. After getting nowhere I just decided to submit multiple tickets across multiple categories until some frustrated BA sends me an email for clarity.
Play stupid games win stupid prizes.
This was me. Then I'd close the door to my office, that was actually a closet with no windows they converted into the "IT" room. 😅
my favorite are when the just email you a whole ass change request. at least an incident I get reaching out to see if anyone else has submitted one
And then the moment they want help from legal and have to go through a ticketing process, they complain about how slow legal is
brandi is in programming?
Ticketing systems are good for keeping track of requests/things that need to be (or are being) worked on. THAT'S IT.
As soon as you start trying to use a ticketing system to determine how hard people are working, or how good they are at their job, you have failed.
People are hired to do a job. Having them continuously *prove* they are doing their job, is a stupid waste of time.
In nearly 30 years of working IT, I have never worked somewhere where *everyone* wasn't PAINFULLY aware of which people were good employees, and which people weren't. And I've also never seen a ticketing system that was ever used anything but the "stick" part of the "carrot and stick" method.
Hire people that are good. Let them work. Let them prioritize their own tickets/projects (not possible all of the time). Let them fill out tickets as they work on them, with whatever data they think is relevant. And then *ignore the tickets* as anything but a general idea of what is being accomplished. Stuff is either getting done, or it's not. It will be very obvious when it isn't.
The problem, of course, is that every business wants every employee to do as much as possible, as quickly as possible, all of the time. This is idiotic and unsustainable., and just means everyone is more concerned about keeping their job than making things work.
I have a quick question
oh fuck you. I know what that means.
I had a manager that'd come to me with all these specific and sudden changes. Since I had just started I was eager to please but it eventually became so bad that I was only ever working on her sudden ideas and never my actual assigned tasks. I started telling her to create a ticket every time she had an idea.
She quickly stopped having ideas after she told me she was spending half her day just creating tickets. Suddenly my productivity skyrocketed too. Hm, I wonder why...
look inside
empty description
It's getting to the point where I never answer calls from teams and if the phone number on my caller ID isn't a number in one of the tickets logged I don't answer it
I know this isn't specifically about programming but it's adjacent and it hits home.
Got a minute to read the FAQ first before raising that ticket?
this is why my work lets IT make tickets
'Puter says ticket
not this fucking meme format bro
LOL, every interaction with tech support ever. 😂💀 "Got a ticket?" is the new "Hello, how can I help you?”
As users from an R&D department we once had a joke.
"If you don't have a ticket number we will not help you. If you have a ticket number, we can't help you."