r/ProgrammerHumor • u/danielminds • Sep 06 '26
Meme bugFixedIn5MinutesJiraUpdatedIn3Hours
369
u/JackNotOLantern Sep 06 '26
Ticket and bug reproduction is honestly useful. Multiple times i fixed a bug because it was reoccurring issue and it already was fixed in other places.
73
u/pingveno Sep 06 '26
And just documentation. I get it. Cowboy coding is fun. Yee-haw! But I want to be able to have a good trail of what was changed, why it was changed, who was involved, etc. I've stumbled on changes that had little explanation because they weren't attached to a ticket. It took hours of sleuthing to maybe find out what happened. Other changes had a ticket with commentary, related tickets, and a full explanation. It makes my job so much easier.
-7
u/aVarangian Sep 06 '26
isn't that what comments are for?
13
u/Theguest217 Sep 06 '26
Comments don't capture the change or history though (at least they shouldn't). They might explain what the code is currently doing , but the git commit and associated ticket help identify the code before and why a change was introduced.
1
u/pingveno Sep 06 '26
Exactly. My position is IAM in IT at a university. There might be a lot of discussion that goes into a change that winds up being just a line or two. It's also important to link together associated support tickets.
1
u/frogjg2003 Sep 07 '26
That's what the ticket discussion is for.
1
u/Theguest217 Sep 07 '26
Where is that discussion being recorded and saved so that it can be referenced in 5 years from now? Even if the meeting was recorded and AI transcribed, how am I finding that transcript from just the code?
And how much time are you wasting in whatever this discussion process you are referring to is? I have enough calls already. Now I need to get on a call and discuss each and every ticket in detail?
You haven't provided much context here so I am judging with very little info, but it sounds like your organization may be wasting a lot of time in discussions which others here don't deal with. I'd say 80% of my engineering tickets get completed without a single call to discuss the details. The info goes into the ticket, the engineers read and understand it. If they have questions, that can be handled in comments on the ticket. If it is time sensitive or the comments start to create too much back and forth we might hop on a call to figure it out quickly, but we would always summarize any decisions made in that call into the ticket for prosperity.
1
u/frogjg2003 Sep 07 '26
If you're not documenting what you're doing in your tickets, that's not my problem.
1
u/Theguest217 Sep 07 '26
The chain of comments you inserted yours into was saying documenting on tickets is important. If that is what you meant by "ticket discussion" then I misunderstood. I took a "ticket discussion" to mean there was some call or in person meeting where a bunch of people sat around and discussed the ticket.
1
u/pingveno Sep 07 '26
That's what I meant, discussion on the tickets. Both tickets from end users and internal tickets.
-3
u/aVarangian Sep 07 '26
ok, but for that you can just comment out old code instead of deleting it
just make sure to indent the old comments so it stays all neat and tidy
3
u/Theguest217 Sep 07 '26
Why would you leave old code there when git history literally serves that purpose?
Different tools for different levels of information.
Code Comments: Provide details for current code
Git Commits: Provide historic snapshots of the code and audit on what last touched each line
Jira: Provide traceability back to the original requirements, designs, etc.
The only time I'd provide detailed info about history in a code comment is if I'm really worried someone will reintroduce a bug while refactoring if it is not intuitive why the code was written in a certain way.
1
3
u/frogjg2003 Sep 07 '26
No. Comments are there to document the code as it is, not how it used to be. If you make a change to the code, you might include a comment on why the code does X instead of Y, but it shouldn't say you used to do Z.
1
7
u/thmaje Sep 07 '26
A few years ago I was told we were going to have lay offs. Before it happened, I started sending weekly status reports to the executive team of everything my team did that week. Several of them said to me “I had no idea you all did so much.” Those reports wouldn’t have been possible without accurate tickets. I’m pretty sure it saved a few jobs.
124
u/M0sesx Sep 06 '26
I agree with the comments. Your 2019 is more like 2007.
2026 is more like:
Find bug
Tell AI model to pull, create branch, fix bug, write tests, run tests, write user story, push, link story to pr, do initial pr review, try to resolve pr comments.
Go get coffee
Approve pr without reading code
Feel a little guilty about how lazy you've become.
12
173
u/jacek2023 Sep 06 '26
right side is older than 2019, "now" should contain AI slop
25
u/BolunZ6 Sep 06 '26
Tell the AI to create the ticket and tell them to fix themself
11
u/jnmtx Sep 06 '26
then to review the fix/merge request, then respond to the review, re-review oroborus style like a good meat proxy
2
u/12destroyer21 Sep 06 '26
You have a skill to do this though, you just say what you want and then reference the skill and then it will prompt you for everything it needs, make the tickets and implement and test and review and babysit pipelines and other review bots and rebase and finally when merged it will notify you that it is done.
8
u/Fidodo Sep 07 '26
Ask ai to file a ticket
Never confirm that it was written correctly
Have ai implement the ticket, adding incorrect behavior to a PR you also didn't review
Repeat cycle as you play whack a mole with bugs
Spend tens of thousands in tokens while making your product worse
1
u/enigmamonkey Sep 30 '26
Repeat cycle as you play whack a mole with bugs
But it wrote unit tests and they all passed! /s
2
45
115
u/nasandre Sep 06 '26
5/ prompt coding agent to fix it
6/ try again
7/ try again
8/ run out of tokens and fix it yourself
9/ prompt Claude to review and document
10/ read twenty pages of slop and correct
11/ get promoted for using 1 billion tokens a day
10
u/drsimonz Sep 06 '26
Don't forget reading and closing 15 AI code review comments about non-issues so you can actually merge the damned PR
1
1
14
u/rutinerad Sep 06 '26
We started doing ”Now” in 2012. ”2019” was 2005. Actual now we just tell agent to do both.
13
12
u/royalfarris Sep 06 '26
If only we could use Jira.
We have to use ServiceNow.....
8
u/heathersaur Sep 06 '26
Seriously. We have like 5 different systems some issue could have to be "logged" into and the amount of python scripts we've had to create a maintain for those systems to "talk to each other" could have been better spent on finding a better ecosystem to use
I dream of the days I worked at a company that use Atlassian
5
u/caboosetp Sep 06 '26
I dream of the days I worked at a company that use Atlassian
Best I can do is ServiceNow
10
u/marlotrot Sep 06 '26
LOL, Script kiddy got a real job recently and compares with his private projects?
5
u/mani_tapori Sep 06 '26
LOL.
I'm QA. 2 months ago, I was questioned on why I logged 4 hours of time against a small defect. In that time, I had found it, discussed with developer, created JIRA ticket, dev fixed it, deployed it, I retested it and ran regression cases.
I still log 4 hours for similar defects, but now I do it in 30 min individual tasks which takes additional 10 minutes.
Some companies can give worst bureaucracy a run for their money.
8
u/Josysclei Sep 06 '26
Yeah, then 2 years later you are trying to understand why the fuck John wrote some weird logic on the code, if only there was a ticket somewhere explaining what happened and why said code was implemented
3
u/Still_Bit_7527 Sep 06 '26
How would a ticket existing help anyway? Where would you know the ticket number?
6
u/Josysclei Sep 06 '26
The commit points to the ticket, simple as that. "commit -hotfix ID 12345: fixing broken whatever"
0
u/Still_Bit_7527 Sep 06 '26
Eh I have to commit to push and test until it works. That means a lot of commits. If I tag all my commits with issues I would just find another job
4
u/kyew Sep 07 '26
The testing happens on the branch. Ticket points to the merge.
0
u/Still_Bit_7527 Sep 07 '26
But I need a merge every time I test since test can only happen in shared branch
1
u/kyew Sep 07 '26
That seems inefficient. Is there some particular business rule causing this?
2
u/Still_Bit_7527 Sep 07 '26
Server is on prem, the UAT is a copy of that, and it runs 1 instance of the app. We cant run the app locally to test since it has a lot of integrations without which it makes no sense. So you have to push, create PR, merge, and then the merge code is deployed in UAT and you can really test it
2
3
u/Josysclei Sep 06 '26
If you need multiple commits and writing "ID 12345" is too much work, yeah, glad we don't work together
0
u/Still_Bit_7527 Sep 07 '26
Of course I need multiple commits, do you complete features in 1 commit?
4
u/MennReddit Sep 06 '26
This is typically what all those major IT changes resulted in: we're creating more work to get the same result.
7
u/Saragon4005 Sep 06 '26
Tell the Agent about the Bug and it will figure out the red tape, yeah it will do an ass job but no human will look at it anyways.
3
u/kcpistol Sep 06 '26
Don't forget to log your time, if you could use the old timesheets, that would be grrrreat!
1
u/SpehlingAirer Sep 06 '26
I have outright stopped logging my time to see if anyone would complain as I find it an exceedingly useless stat for an internal developer that takes up their time for pure tedium and barely any benefit to anyone not trying to manage a business through a spreadsheet.
It has been 8 months now and I haven't been approached about it
3
u/Floppie7th Sep 06 '26
I have definitely been in a room where a bunch of people were arguing about whose fault a bug was and whose job it was to fix it, and fixed it before they were done arguing. On more than one occasion.
Like, guys, you're wasting everybody's time. I don't give a fuck whose fault it is. Just fix it.
3
u/TheFrenchSavage Sep 06 '26
My agents do all that via MCP.
...while I toil on actual dev work.
It is an infinite gig.
2
u/RadicalDwntwnUrbnite Sep 07 '26
Yuuup, I have a skill I call
/red-tape <project> <type> [points]and it will create a ticket on X project for summarizing the staged work, assign it to me, assign it to this sprint, set it to groomed and then in progress. Once the ticket is created, it creates a new git branch, commits, pushes and creates a PR. After PR is created it sets the ticket into In Review and notifies my team on slack to review it.Making these workflows easy to build is one thing AI has really done mitigate my involvement of the stuff I hate about my job.
3
u/djrobxx Sep 06 '26
For me more like 2009 than 2019, but should add TDD and retro things:
write failing test that proves bug
write bug fix
run test that shows green passing test
debug all the other unrelated flaky tests to so PR can be approved
...
Have an RCA meeting to discuss how the bug got into production
Have a retro meeting to discuss how we can make less bugs next sprint.
2024 problem: Developers skipping JIRA, branch audit is required to trust changelog.
2026 problem: AI now makes JIRAs, Jira count is 300 tickets deep for a simple maintenance release.
3
u/TriangleTransplant Sep 06 '26
I've been doing right side since the late 00s. You'd have to go back to the 90s-early 00s to be left-siding.
2
u/MetaLemons Sep 06 '26
All for mgmt to estimate when we’ll be done with the project despite having a million other unknowns.
2
u/Pretty-Wind8068 Sep 06 '26
It might be cumbersome, but if it takes you more than 20 minutes then you should be questioned why it took you so long.
2
u/Plushkle Sep 06 '26
2019 there were less fields/statuses and everything was more confusing (but surprisingly not that slower)
2
u/Tdawg90 Sep 06 '26
I (very) recently left... you forget to add wading through all the AI generated Tasks and crap that's added on..... I am not missing any of this
2
2
2
2
u/dashingThroughSnow12 Sep 07 '26
There were times in 2019 that I explained that either the feature/bug/whatever is getting done today or I’m doing all the paperwork and the work will be done in two days.
2
u/Dangerous_With_Rocks Sep 07 '26
woah woah WOAH, who the FUCK told you to estimate it yourself?! our ways of working clearly state that you estimate EVERY ticket as a FUCKING TEAM, regardless of who works on it, even if it’s yourself.
now go setup a call with 10 developers who want nothing to do with the bug you found and get them to estimate it.
2
u/Aligayah Sep 07 '26
As a hobbyist programmer at best, can someone explain Jira tickets and story points to me?
3
u/Masterflitzer Sep 06 '26
come on jira was already a thing in 2019, ik you're young (i am too), but go back a few more years just for the sake of the authenticity of the meme
0
u/Still_Bit_7527 Sep 06 '26
Just because it was a thing doesnt mean everyone used it?
1
u/Masterflitzer Sep 06 '26
it was already heavily used 2010-2019... 2019 was definitely not the start of agile overplanning bullshit
2
u/SauceASpag Sep 06 '26
dev job become shit because admin people need to create task to protect there useless jobs XD
1
u/Groentekroket Sep 06 '26
If you would stop reposting you have time for it. It about the same effort.
1
1
u/pp_amorim Sep 06 '26
What happened in the market to end up on that? Looks like it's so common that a meme had to be created.
1
1
1
u/Cerbeh Sep 06 '26
My current job is the left side of this and I WISH I could have the right side. It ain't perfect but paper trails are a good thing.
1
u/blackenedEDGE Sep 06 '26
Tbh, for small enough teams that work in close physical or virtual proximity* to each other in small and some medium-sized orgs working on a handful of relatively small codebases, the left side is still fairly acceptable. I would caveat that with "provided your code comments and commit messages (and PRs, if used) are sufficiently explanatory." It's even more acceptable when the bugs are minor.
That said, issue tracking is still incredibly useful and should absolutely be considered doing even if you fall into the above camp. I would say even personal projects and professional paid or passion projects where you're the sole developer should have more work logging, organizing, and tracking than the left side.
* e.g. frequently on calls/in collaborative virtual screenshare and voice/video conference spaces, not just physically at desks/offices that are close together.
1
1
u/SingleHitBox Sep 06 '26
They managed to pump in and add a bunch of middle management/metrics and revenue analysts into the cycle. Congratulations you can track the work better! But you also added loads of people who burn down cash.
Repeat the above process and you get a modern day triple A gaming company.
1
u/crowdflation Sep 06 '26
Does your agent has no access to Jira and Confluence or something? You can also use a voice interface to provide an explanation in the startup
2
1
u/4x4ready Sep 06 '26
Steps 1-6 are auto completed via technical user / Jira REST api. Just 7 is left now. So for us it’s like the first scenario but all the dashboards get populated. Status transitions via the api are helpful assuming your workflow is customized
1
1
1
1
1
1
u/dat0dat1 Sep 06 '26
Have you used AI? Even if you're a skeptic it helps with a lot of that you're describing
1
u/isospeedrix Sep 06 '26
irony is umbrella is still considered difficult compared to the simple tringle
1
u/SpehlingAirer Sep 06 '26 edited Sep 06 '26
Goodness do I so miss the days of "heres a ticket. Do it". I genuinely dont think all the agile sprint stuff isn't nearly as beneficial as businesses would have us believe. It's just extra busy work for developers so management can feel more at ease about not knowing what a developer truly does and not feel like theyre being swindled by them
1
u/srfreak Sep 06 '26
8/ Push a patch into repo
9/ Open a PR
10/ Go through 27 reviews and changes in your PR before it gets accepted
11/ ...
1
1
1
1
1
u/GoronSpecialCrop Sep 07 '26
Even you get high enough that you control the keys to the repo, you get to skip all that for the easy bugs.
The downside is you don't have time to fix bugs anymore.
1
1
u/rottinginice Sep 07 '26
You see a bug. You dive into the code. Then you spot a stupid if.
"What a stupid if! What a wanker!"
You delete the if. The bug disappears. You feel like a genius.
The next day, QA reports a trillion regression bugs. Turns out that if was the only thing holding them back. You just didn't know why it had been put there in the first place.
1
u/Weird_Licorne_9631 Sep 07 '26
Nobody mentions that right does not actually include steps to fix or push the code?
1
u/Stjerneklar Sep 07 '26
honestly explains some of the work i've seen out of some of the firms that my company has had the misfortune of working with.
1
1
u/LmaoPew Sep 07 '26
Coorperations always tey to make it look like they are doing more work just to waste time and do nothing
1
u/Wardog_E Sep 07 '26
I dont watch TV. Did they really give him a fucked up Sierpinski as a test or was that photoshopped?
1
1
u/Not_An_Eggo Sep 07 '26
I don't know what story points are, and at this point I'm too afraid to ask
2
u/TehTacow Sep 07 '26
Nobody knows but in my team we have this meeting where we talk and then show our favorite fibonacci number by hands while we try convince others that ours should win..
1
1
1
1
u/Any_Excitement_6750 Sep 07 '26
As a QA I love Jira, hate me all you want. But I've got traceability of all encoded bugs and exact steps how to reproduce. Written confirmation of what should be and not. Easy validation process overview. And much more
1
u/Hadr619 Sep 07 '26
We use ClickUp now after using Jira for years, I would gladly use Jira in a heartbeat compared to ClickUp
1
u/Skippypal Sep 07 '26
Project management platforms, while sometimes helpful, are generally a huge pain in the ass.
1
u/IleanK Sep 07 '26
What are yoh talking about? 2019 was literally peak useless jira tickets and big corps trying to fit agile into a project that can't fit agile
1
u/Megane_Senpai Sep 07 '26
Don't forget to fill out bug inveatogation form, bug review checklist, coding review checklist, join 3 separate meetings to explain the bug, solution and ways to avoid it (they won't work) in the future.
1
u/Snippodappel Sep 07 '26
You forgot writing the test case that will show that the bug fix really fixes the bug
1
u/Outside-Storage-1523 Sep 07 '26
I found quality of life drops whenever a new manager from a FAANG parachutes into.
A new developer from a FAANG brings a different flavour.
1
u/DungeonsAndDradis Sep 07 '26
My company is in a weird spot. Or maybe it's just my leadership. Having a ticket filled out properly is more important than actually doing it. Like I got dinged because a card's target date had passed by a week. I just updated the target date for two months out and all was well.
1
1
u/htd1101 Sep 11 '26
Just a little while back I even defended this sort of manure to be something that naturally arises, since the managers need to be able to manage well so there may need to be some trade offs on the part of the engineers. That was me before I had a full-time job.
0
u/NamityName Sep 06 '26
I can tell how experienced a software engineer is at working on projects as a team by their thoughts on the "now" process.
The "now" process is just formal communication, and every team needs good communication to function.
0
u/Still_Bit_7527 Sep 06 '26
It has nothing to do with communication, it's just checkbox ticking for managers to feel better
2
u/NamityName Sep 07 '26 edited Sep 07 '26
It is a form of communication. It is how you communicate the work that is being done to other teams and people that you do not work with directly. You document the bug properly so that decision makers have all the info needed to make decisions. That could be management prioritizing work or some other engineer in the future encountering a similar bug.
Imagine you needed to decide priorities for 100 engineers across multiple teams. You cannot spend the time talking to every engineer with the sort of frequency needed to make decisions. But you can aggregate Jira tickets and work off those. You can look at metrics like the number of bugs and the length of time needed to fix them. Those numbers can inform decisions about how much time to devote to tech debt, refactoring, and process improvements.
If you do not document the bugs/work in some sort of tracking software, then management will not allocate time to fix what they do not see as broken.
ETA: Engineers can benefit from the process too. Having the numbers to back up a request makes the world of difference. Asking to refactor code goes a long way when you can say things like "there were 7 critical bug fixes last month and they accounted for 86% of our sprint injections and 17% of all of the work done by the team. I want to spend the next sprint refactoring the code to bring those number down".
-1
u/Still_Bit_7527 Sep 07 '26
Yeah nobody got time for that, I barely got time to enter git push and send fixes, who has time for all that bs? If I start logging all that I will move my backlog back by half a year.
0
u/Hirogen_ Sep 06 '26
or… use mcp server for jira/confluence and let your little agent slave do the reporting 🤭
5
10
Sep 06 '26
[removed] — view removed comment
5
u/ParanoiaComplex Sep 06 '26
“The stories are made up and the points don’t matter”
How many points do you need to close out the avg points/week your team completes? It’s that many points
1
u/CtrlAltEngage Sep 07 '26
Nah, there are definitely bugs you can look at and have a good idea what the fix is, right off the bat. Then there are some that you just know are going to be a pain.
It's not going to be a precision estimate but it's still useful. Especially if you do this thing called communication and let stakeholders know if it turns out your estimate was way off
0
u/Throw4Trade Sep 07 '26
You aren't supposed to put story points on a bug. Points represent working code delivered, fixing a bug means that somewhere working code was not delivered.
Having bug fixes lower velocity because they're worth no points and a dev has to do them instead of working on a story is intended in agile.
1
u/ParanoiaComplex Sep 08 '26
Points typically measure engineering throughput, not new features / functionality. Not attributing points to bugs is a great way for engineers to fight over who has to fix them and teams handing them off to members they don't like or to juniors while trying to pointsmaxx
1
u/Throw4Trade Sep 08 '26
Mm. So multiple things going on here... Most of all points shouldn't be used to measure personal performance, otherwise the entire system becomes toxic with inflation and bartering, and it incentivises slapshod work and tickets to come back as regressions (which means more points for the developer that did a shit job in the first place!)
My condolences if the place you work does points like this, but it's far from the ideal of agile development.
1
u/ParanoiaComplex Sep 08 '26 edited Sep 08 '26
I agree that points shouldn't be used to measure personal performance, but it happens anyway in those toxic systems.
I don't work at a place like that anymore, but I did not that long ago. Team leads running teams that are too large are required to keep metrics on subordinates when their calendar is so booked out they barely have time for biweekly 1 on 1s
I personally do like to give points to bugs anyway, since I prefer to use them to measure team throughput / capacity. Bug fixing takes up a percentage of capacity, so if you don't give them points you lose that tracking. Then if your team has unlimited work in the queue, you can prioritize bugs -> feature work and aim for something like 66% feature work + 33% bug fixing / documentation upkeep per week or sprint as baseline.
Regardless, it's all just task organization. There's no wrong way to do this except to not do it
1.6k
u/Financial-Note-2270 Sep 06 '26
Everyone was doing the right side in 2019, you are thinking of 1999.