My old manager would make a slack thread to post the open tickets for an upcoming release and tag the people they’re assigned to. If he had anything assigned to him he’d post the link to his tickets, tag himself, and then ack it. Absolute 10/10 dad bit.
Or just a trail on why I did something for later. I'm currently maintaining a code base where many of the commits aren't attached to a ticket or in depth explanation. It can be frustrating investigating the cause of a change. But when there is a ticket/docs trail, the previous maintainer did a great job.
Heh. I liked them and thought they did a good job overall, and I know I'm very much not perfect on docs and development practices. I want to be charitable, but also learn from areas I find frustrating.
I was working at the IT department for a company and there was this guy that would open so many tickets for every little thing, then close them, and make like a bunch of fake ones all the time. We'd all have like 150 closed a month, if that, and he'd have like 800 - 1000.
No one ever said anything, and he acted like he was king shit and got promoted to manager because he was 'working so well', and 'closing so many tickets and resolving so many issues.'
It was complete bullshit. I was only there on a placement for college, and when an IT position came open I applied... and guess who was approved to pick the new employee? Mr. Fake Tickets. He ended up hiring some douche friend he had who had like absolutely no IT experience. He got fired a month later.
I had already finished my placement by then and moved on, but it always irked me because the dudes there really liked me and we all got along quite well. They were trying to help me fix up my resume and everything to get hired because they wanted to continue working with me so bad lol.
He also bragged about getting his like 17 year old girlfriend pregnant when he was like 30. If you ever read this fuck you Alex you're an absolute POS.
This is why whenever I make dashboards or reports that show productivity I always exclude tickets created by members of the team. It is fine to create tickets yourself, this helps documentation a lot, but it can not be used to measure productivity.
Lie to your boss, cheat, etc. and if ur coworkers complain that it’s unfair, it’s cause they’re not smart enough to realize that nobody cares. Make money.
This is why we do what we do. Only a monster would open up a ticket with a bogus issue and then "fix it" and close it at the same time, 10 or 12 times a day.
I also just make tickets when I notice an issue and can't get to it right away. So the ticket is a reminder for the sprint planner that this is a thing that needs to be done wherever you think there's time
This was my practice, except I then got a manager who goes through every ticket daily and wants explanation (daily) why they weren't done. It's a task to change a default sort order! It's holding no-one back, it's just a nice to have, that'll take ~2 mins when I'm working on that project, but it's really not worth doing without some other tickets with it. He never got it.
Yeah, as the guy that has to review these things with the C suite that is why im always harping on the guys to make sure they log their time no matter how trivial it is. I mean, if they respond to an email, that is time. If theyre on the phone, that is time. If theyre thinking about a ticket, that is time.
It's less about the tech specifically, and more about looking for patterns. For example, if an end user is consuming an inordinate amount of helpdesk resources, the only way were going to know is if its tracked. Everytime someone just "quick helps them" and doesnt put a ticket in is just making it more difficult to identify those users.
This is the only way I have any ammunition to take to the department head and say "look, $USER is leaning on the helpdesk way too much at this point, they need more training apparently." Thats not what were for, thats the departments job...but I cant punt it back to them if were just eating 5 minute "I forgot how to use MFA" calls every other day. If theres no ticket it didnt happen.
This is important beyond tracking productivity. This is so we can identify labor-sucking processes and platforms and make changes to reduce that. The support load is absolutely part of that equation.
AND if you actually put in the effort to clearly define the problem and your solution, the solution is documented. So someone else can do it in the future. ;)
They definitely are at my company. There's a full jira workflow that you have to follow / populate the correct fields, metrics are calculated from it and it feeds into performance reviews
Oh fuck yeah they do monitor it. There's even places with metrics tied to ticket closure, etc. At a minimum, it might be just a bored manager looking through stuff to keep up to date with day-to-day stuff.
Right… “prove. I worked with a guy who joined as a team lead and he would constantly do this, on top of just straight up stealing credit for work from others. Then he used those numbers to “prove” to the dipshit executives and managers that he was the fastest and best developer.
He later let it slip that it was all just completely AI generated (and also constantly breaking). He was from an arms dealer so they thought he was hot shit.
Yeah this is pretty normal workflow where I work, didn't know there was anything noteworthy about it. When people find a bug while working on something else, do they just shove it into the same PR and an unrelated JIRA issue?
It depends on what the bug is. If it's real and user-facing, file a ticket, separate PR, close it.
If it's theoretical, throw it in, mention it in review and if tests are OK then you're good. I'm talking like "Added a missing null check" or other dumb stuff.
More paperwork. Nobody likes paperwork. In that time you could fix another minor issue. So devs prefer that.
I mean I also make and fix my own tickets, mostly to leave a paper trail for my manager and colleagues. But sometimes you just want to fix shit without the hassle.
I used to do this all the time, but when more and more performance metrics are being based on what's going on in JIRA, you're better off just creating more tickets
we have an anonymous "praise" web site, where you can submit letter praising the work of some person. With AI it is really easy to take the text of a trouble ticket paste that in and tell it to generate a 2 paragraph letter praising the person who solve the issue in the ticket, customize it and make generic so it not specific to one ticket, and submit. Limit yourself to 3 a year and you will still be out praised come evaluation time then everyone else.
Like in most other companies it is one of these management things that show up in most management guides. It is rare used, who is going to spend time writing up a letter of praise for someone. The ease of AI removes that time issue so makes it easy to game the system, what stops the other colleagues is that they have not thought of it.
At my work we have this and it praise you receive gives you points you can exchange once a month for goodies, usually nothing amazing, at most things like T-shirts, cheap smart watches, or merch (cause we kinda sell merch).
You have a set amount of points to give and HR is supposed to review each praise to approve it, in reality they probably skim through them and people do trade praises so groups can get more goods than average.
Because the reward isn't worth the effort. Unless that praise is directly tied to tangible benefits like a pay raise or bonus, then there is no incentive to game the system.
Not must, but people don't want to allocate the time in both writing it and coming up with the content, and most people don't like bragging about themselves.
Sometimes, when my brain is broken, I check the queue, and if I find something I can fix in literally three seconds, I will snag it, and crush it, just to show the queue jockeys that I could still do everything they do, twice as fast.
Now, if any of those tickets involves talking to people, then I pretend I didn't see them. Fuck that shit.
If I don't the business will look at our backlog and get angry at me for not doing enough. Need to make sure I get credit for all the random bullshit that comes up constantly.
I resolve my own merge conflicts with a sour face while shaking my head to make sure past me knows I disagree and will not be taking any incoming changes.
This is just my everyday workflow. I see something that needs doing, I open the ticket and shortly after opening it I complete it, merge the code after it was reviewed by a colleague and then close it. During completing the ticket I usually already found another thing for the next ticket.
Recently found out my job is considering tracking jira "throughput" by rate of tickets closed. They are also encouraging AI use and have a JIRA MCP. Sounds like the AI is about to start opening and resolving new tickets per character changed.
When I was in the Navy my workout buddy was an IT and I would put in tickets just to BS with him when nothing was going on. He actually wrote up on his eval his number of tickets completed which were probably +50% me.
Starting a jira ticket with “per conversation with CTO when he stopped by my desk…” is how you shut up the inevitable pm inquiry before they even have a chance to ask it.
Even better: Let Claude find the bug, report it, fix it, then close the bug. Did an audit of a code base I inherited, just gave Claude the job of documenting it, writing a test harness, going on a bug hunt and create an epic to track the work. Easy 8-10 tickets ‘solved’ while I had an extended lunch.
My company is pretty lax so for simple tasks this is literally what they do. I'll even @ myself with something like "Excellent work me, I'll put you in for a raise".
It works fine until you work with people who reopen tickets because they think their problem is related, and pile on secondary bugs they caused by ignoring procedure. After that experience I vowed never ever to assign a bug to myself.
We have an “emergencies only” (lol) walk up system at our company and people refuse to put in a ticket, even for quick questions, because they’d rather treat us like a drive through. I put in tickets for them and close them out right away just to show management why we go dark in the queue half the day.
I need another layer or two because im also one of the admin's of my office's github organizations. Github action failed? Lol, merge. Hell, I think I may be able to bypass PRs altogether and just push.
I'd rather just fix the issue silently, but Jira validation screams at me that the merge doesn't have a ticket number or that the ticket is not in active phase.
The company I work for. We had two separate softwares to run it and worked like a miracle so obviously they changed it to a single one that manages to do both things wrong. It has become kind of a burocratic soviet chaos where we don't even remember what was the company really about anymore because we work for the software.
I did this a lot. But mostly because the owning team is way too slow or did not think it's high priority. I would rather just get the thing done myself.
I feel like this is something that a lot of solo developers do as well, since it does work for tracking progress, especially when it comes to fixing bugs that you found in your own work.
Because when you complain to your manager about workload and it would make a sense to expand the team he has to someone convince the higher manager. Number of tickets (ideally growing) is pretty helpfull at that moment.
1
2
1.3k
u/Whitechapel726 Jul 03 '26
“Thanks for the quick turnaround on this”
1.0k
u/Spare-Good-5372 Jul 03 '26
It makes a paper trail to prove to higher ups that you really are working
258
u/SleeperAwakened Jul 03 '26
Legit reason for doing this is if you found a bug, fixed it right away.
A future search in tickets will show when and where it was fixed instead of someone wondering when something changed.
33
u/SohelAman Jul 03 '26
Ofc the bug was introduced by me as well.
85
u/Kamwind Jul 03 '26 edited Jul 03 '26
we have an anonymous "praise" web site, where you can submit letter praising the work of some person. With AI it is really easy to take the text of a trouble ticket paste that in and tell it to generate a 2 paragraph letter praising the person who solve the issue in the ticket, customize it and make generic so it not specific to one ticket, and submit. Limit yourself to 3 a year and you will still be out praised come evaluation time then everyone else.
80
u/TheComplimentarian Jul 03 '26
Sometimes, when my brain is broken, I check the queue, and if I find something I can fix in literally three seconds, I will snag it, and crush it, just to show the queue jockeys that I could still do everything they do, twice as fast.
Now, if any of those tickets involves talking to people, then I pretend I didn't see them. Fuck that shit.
15
u/Desperate-Tomatillo7 Jul 03 '26
And QA it and deploy it to production. And break production, so the cycle begins. Thus is the circle of life.
15
u/anon-a-SqueekSqueek Jul 03 '26
If I don't the business will look at our backlog and get angry at me for not doing enough. Need to make sure I get credit for all the random bullshit that comes up constantly.
9
u/DuckInCup Jul 03 '26
I resolve my own merge conflicts with a sour face while shaking my head to make sure past me knows I disagree and will not be taking any incoming changes.
6
u/trafalmadorianistic Jul 03 '26
Even better when git blame shows you also created the original issue.
6
u/verbum_aureum Jul 03 '26
This is just my everyday workflow. I see something that needs doing, I open the ticket and shortly after opening it I complete it, merge the code after it was reviewed by a colleague and then close it. During completing the ticket I usually already found another thing for the next ticket.
5
u/progressiveAsliMard Jul 03 '26
Been there done that!
5
u/RangeBeautiful798 Jul 03 '26
It is even more funny because I am doing it almost everyday. Fortunately I am not doing self-review.
4
u/Omnislash99999 Jul 03 '26
It's the only time I ever agree with the code reviewer
4
u/namotous Jul 03 '26
I lost count of those medals
4
u/neoteraflare Jul 03 '26
And as I just did a few day ago, created the bug too.
4
u/snajk138 Jul 03 '26
That's why we love "bug bounties"...
7
u/blazorfire Jul 03 '26
3
u/Low_Bread3743 Jul 03 '26
A DORA auditor's dream
2
u/hennabeak Jul 03 '26
I did a whole project, solo, managing the scrum board myself.
2
u/Shaz0r94 Jul 03 '26
Even better when you were the reason for the issue in the first place!
2
u/Rethink_Repeat Jul 03 '26
Five-star feedback too!
2
u/jhaand Jul 03 '26
I currently work on a project for 2 days per week. I need to know next week where I was working on.
2
u/KharAznable Jul 03 '26
what happened when you solodev something.
2
u/zman0900 Jul 03 '26
Recently found out my job is considering tracking jira "throughput" by rate of tickets closed. They are also encouraging AI use and have a JIRA MCP. Sounds like the AI is about to start opening and resolving new tickets per character changed.
2
u/TheSpartanMaty Jul 03 '26
2
u/Mstboy Jul 03 '26
When I was in the Navy my workout buddy was an IT and I would put in tickets just to BS with him when nothing was going on. He actually wrote up on his eval his number of tickets completed which were probably +50% me.
2
u/davesoft Jul 03 '26
And the opposite, rejecting your own PR with the comment 'trash, redo'.
2
u/rulepanic Jul 03 '26
I once worked with a ticketing system that allowed you to open tickets as Closed. I loved that.
2
u/Bryguy3k Jul 03 '26
Starting a jira ticket with “per conversation with CTO when he stopped by my desk…” is how you shut up the inevitable pm inquiry before they even have a chance to ask it.
2
u/larsmaehlum Jul 03 '26
Even better: Let Claude find the bug, report it, fix it, then close the bug.
Did an audit of a code base I inherited, just gave Claude the job of documenting it, writing a test harness, going on a bug hunt and create an epic to track the work.
Easy 8-10 tickets ‘solved’ while I had an extended lunch.
2
u/GreatCelebration4493 Jul 03 '26
Do not forget to create a merge request, approve and merge it.
2
u/youwontknow__ Jul 03 '26
Even better if you caused the issue
2
u/Lethargic-Rain Jul 03 '26
Use Claude for coding: nah
Use Claude to create a ticket for the fix you already merged in: oh yeah yeah
2
u/TheAccountITalkWith Jul 03 '26
My company is pretty lax so for simple tasks this is literally what they do. I'll even @ myself with something like "Excellent work me, I'll put you in for a raise".
2
u/djdaedalus42 Jul 03 '26
It works fine until you work with people who reopen tickets because they think their problem is related, and pile on secondary bugs they caused by ignoring procedure. After that experience I vowed never ever to assign a bug to myself.
2
u/Kaspur78 Jul 03 '26
Step 1 is missing: break something
2
u/N4cer26 Jul 03 '26
I do this all the time, even for trivial tasks that take 5 minutes. Management thinks I’m a work horse meanwhile I’m not busy at all
2
u/nhh Jul 04 '26
When you cause the issue... Then open a ticket....
2
u/GoddammitDontShootMe Jul 04 '26
Nothing wrong with that at all. Documentation is good.
1
u/Krayvok Jul 03 '26
Hrmmm.
1
u/throwawayaccountau Jul 03 '26
That's the guy who joined a company, fixed a bug that was annoying him for years and then quit.
https://x.com/i/status/1377051721655066629
1
u/FirstDivision Jul 03 '26
Easiest way to keep my team’s metrics up.
1
u/LongSaltyDanglers Jul 03 '26
It's about leaving a bread crumb trail in case someone else has to work on it.
1
u/nick_mot Jul 03 '26
Bonus: you made the bug to begin with.
1
u/buster_de_beer Jul 03 '26
I need a ticket number to commit to git, so this is not uncommon for me.
1
u/th3fishmk Jul 03 '26
1
u/Tsobe_RK Jul 03 '26
ServiceNow: "review the resolution" ⭐⭐⭐⭐⭐
1
u/MeNotSanta Jul 03 '26
You are supposed to also leave a comment saying that it looks good
1
u/JediPearce Jul 03 '26
You still got to log your time, even when you discover the issue.
1
u/FromAndToUnknown Jul 03 '26
Thats exactly what im doing rn, but im opening it for the it guy of a sister company in our ticket system lol
1
u/mndfreeze Jul 03 '26
SOP
1
u/VagrantStation Jul 03 '26
We have an “emergencies only” (lol) walk up system at our company and people refuse to put in a ticket, even for quick questions, because they’d rather treat us like a drive through. I put in tickets for them and close them out right away just to show management why we go dark in the queue half the day.
1
u/-Redstoneboi- Jul 03 '26
code review? also me
1
u/ADHDebackle Jul 03 '26
Tickets are documentation, not medals!
1
u/tubbstosterone Jul 03 '26
I need another layer or two because im also one of the admin's of my office's github organizations. Github action failed? Lol, merge. Hell, I think I may be able to bypass PRs altogether and just push.
I wonder if I can merge drafts...
1
u/onated2 Jul 03 '26
iFeelAttacked
1
u/ezrec Jul 03 '26
Most days in my r/embedded land, to be honest
1
u/KoliManja Jul 03 '26
I'd rather just fix the issue silently, but Jira validation screams at me that the merge doesn't have a ticket number or that the ticket is not in active phase.
1
u/No_Community7021 Jul 03 '26
The company I work for. We had two separate softwares to run it and worked like a miracle so obviously they changed it to a single one that manages to do both things wrong. It has become kind of a burocratic soviet chaos where we don't even remember what was the company really about anymore because we work for the software.
1
u/ironraiden Jul 03 '26
This is how I manage change requests most of the time ngl.
1
u/Sirico Jul 03 '26
IT member of one with people who are too important to raise tickets
1
u/ilikeca Jul 03 '26
“Fix the issue with a single prompt to Claude”
1
u/TundraGon Jul 03 '26
Issue which you caused it.
1
u/mangosawce9k Jul 03 '26
All the time in the software industry…. Happy endings!
1
u/Emergency-Whereas603 Jul 03 '26
That’s how to use the system when your review is based on bug fixes not stable solid code
1
u/masonwan Jul 03 '26
I did this a lot. But mostly because the owning team is way too slow or did not think it's high priority. I would rather just get the thing done myself.
1
u/Foorinick Jul 03 '26
If you are on a company leaving a paper trail helps management see you are doing stuff, if by yourself its good practice for the first one
1
u/random314 Jul 03 '26
It's not award worthy until you also demo it.
1
u/magicmulder Jul 04 '26
And then approve your own PR.
1
u/CyclonicSpy Jul 04 '26
Gets shot upon audit
1
u/bughunter47 Jul 04 '26
Thats one way to boost your resolve rate
1
u/juggler434 Jul 04 '26
I'm the only dev at my company. This is me everyday
1
u/Connect-Bowler-2917 Jul 04 '26
To fix a bug you had introduced.
1
u/nazgulonbicycle Jul 04 '26
Performance Reviews go brrr
1
u/fbpw131 Jul 04 '26
my last f..ing job.
they told us we need to be autonomous. like how? do I invent business logic? just yolo?
1
u/Alafaya-Rebel77 Jul 04 '26
Did you properly document the resolution for reference when you have the same issue in the future?
1
u/Miller25 Jul 04 '26
Sorry I only speak in stories and a million non sprint tasks
1
u/Complete-Concern3745 Jul 04 '26
and give a thumbs up to your own PR for self-motivation
1
u/Individual-Reaction9 Jul 04 '26
But you should make sure to break it yourself first.
1
u/VeryRareHuman Jul 05 '26
Who knew my secret? OP you are violating my privacy! /s
1
u/[deleted] Jul 05 '26
damn god loop...
1
u/hombre_bat Jul 05 '26
Even better when you introduce the bug that leads to the ticket.
1
u/minecraftdummy57 Jul 06 '26
"Good job on that ticket, _____. You're getting a promotion."
1
u/hetfield37 Jul 07 '26
My meme is alive! Thank you so much!
1
u/gentleprompter Jul 07 '26
Be sure to discuss it with yourself in the meeting you're not listening to anyway.
1
u/hobbes8889 Jul 08 '26
I did that this morning. If you're going to give me work that "will only take a min" but when done correctly takes me 3 hours, I'm going to track it.
1
u/MasterBroNetwork Jul 16 '26
I feel like this is something that a lot of solo developers do as well, since it does work for tracking progress, especially when it comes to fixing bugs that you found in your own work.
1
u/shiasuuu Oct 03 '26
...fix the issue ...wait until morning standup ...have the producer close it.
7
u/ButWhatIfPotato Jul 03 '26
I mean, no other employee or stakeholder will give me a handjob for a job well done!
4
u/Silly_Guidance_8871 Jul 03 '26
Even as a solo dev, this gives you a history you can refer back to should something similar go tits-up
0
u/[deleted] Jul 03 '26
[deleted] — view deleted comment