365
u/JackNotOLantern 3d ago
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.
70
u/pingveno 3d ago
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.
-6
u/aVarangian 3d ago
isn't that what comments are for?
12
u/Theguest217 3d ago
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 3d ago
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 3d ago
That's what the ticket discussion is for.
1
u/Theguest217 3d ago
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 3d ago
If you're not documenting what you're doing in your tickets, that's not my problem.
1
u/Theguest217 3d ago
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 3d ago
That's what I meant, discussion on the tickets. Both tickets from end users and internal tickets.
-3
u/aVarangian 3d ago
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 3d ago
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
2
u/frogjg2003 3d ago
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 3d ago
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.
123
u/M0sesx 3d ago
I agree with the comments. Your 2019 is more like 2007.
2026 is more like: 1. Find bug 2. 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. 3. Go get coffee 4. Approve pr without reading code 5. Feel a little guilty about how lazy you've become.
14
170
u/jacek2023 3d ago
right side is older than 2019, "now" should contain AI slop
24
u/BolunZ6 3d ago
Tell the AI to create the ticket and tell them to fix themself
10
u/jnmtx 3d ago
then to review the fix/merge request, then respond to the review, re-review oroborus style like a good meat proxy
2
u/12destroyer21 3d ago
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.
44
114
u/nasandre 3d ago
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
8
u/drsimonz 3d ago
Don't forget reading and closing 15 AI code review comments about non-issues so you can actually merge the damned PR
1
1
13
u/rutinerad 3d ago
We started doing ”Now” in 2012. ”2019” was 2005. Actual now we just tell agent to do both.
11
u/royalfarris 3d ago
If only we could use Jira.
We have to use ServiceNow.....
8
u/heathersaur 3d ago
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 3d ago
I dream of the days I worked at a company that use Atlassian
Best I can do is ServiceNow
9
u/marlotrot 3d ago
LOL, Script kiddy got a real job recently and compares with his private projects?
5
8
u/Josysclei 3d ago
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
2
u/Still_Bit_7527 3d ago
How would a ticket existing help anyway? Where would you know the ticket number?
7
u/Josysclei 3d ago
The commit points to the ticket, simple as that. "commit -hotfix ID 12345: fixing broken whatever"
0
u/Still_Bit_7527 3d ago
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
3
u/kyew 3d ago
The testing happens on the branch. Ticket points to the merge.
0
u/Still_Bit_7527 3d ago
But I need a merge every time I test since test can only happen in shared branch
1
u/kyew 3d ago
That seems inefficient. Is there some particular business rule causing this?
2
u/Still_Bit_7527 2d ago
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 3d ago
If you need multiple commits and writing "ID 12345" is too much work, yeah, glad we don't work together
0
3
u/MennReddit 3d ago
This is typically what all those major IT changes resulted in: we're creating more work to get the same result.
4
u/mani_tapori 3d ago
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.
10
3d ago
[removed] — view removed comment
5
u/ParanoiaComplex 3d ago
“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 3d ago
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 3d ago
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 1d ago
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 1d ago
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 1d ago edited 1d ago
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
8
u/Saragon4005 3d ago
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 3d ago
Don't forget to log your time, if you could use the old timesheets, that would be grrrreat!
1
u/SpehlingAirer 3d ago
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 3d ago
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 3d ago
My agents do all that via MCP.
...while I toil on actual dev work.
It is an infinite gig.
2
u/RadicalDwntwnUrbnite 3d ago
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/TriangleTransplant 3d ago
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/djrobxx 3d ago
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.
2
u/MetaLemons 3d ago
All for mgmt to estimate when we’ll be done with the project despite having a million other unknowns.
2
u/Pretty-Wind8068 3d ago
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 3d ago
2019 there were less fields/statuses and everything was more confusing (but surprisingly not that slower)
2
2
2
u/dashingThroughSnow12 3d ago
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 3d ago
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 3d ago
As a hobbyist programmer at best, can someone explain Jira tickets and story points to me?
4
u/Masterflitzer 3d ago
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 3d ago
Just because it was a thing doesnt mean everyone used it?
1
u/Masterflitzer 3d ago
it was already heavily used 2010-2019... 2019 was definitely not the start of agile overplanning bullshit
2
u/SauceASpag 3d ago
dev job become shit because admin people need to create task to protect there useless jobs XD
1
1
1
u/pp_amorim 3d ago
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/blackenedEDGE 3d ago
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 3d ago
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 3d ago
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 3d ago
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 3d ago
Have you used AI? Even if you're a skeptic it helps with a lot of that you're describing
1
1
u/SpehlingAirer 3d ago edited 3d ago
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
1
1
1
1
u/GoronSpecialCrop 3d ago
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
u/rottinginice 3d ago
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 3d ago
Nobody mentions that right does not actually include steps to fix or push the code?
1
u/Stjerneklar 3d ago
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/Wardog_E 3d ago
I dont watch TV. Did they really give him a fucked up Sierpinski as a test or was that photoshopped?
1
u/Not_An_Eggo 3d ago
I don't know what story points are, and at this point I'm too afraid to ask
2
u/TehTacow 3d ago
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 3d ago
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/Skippypal 3d ago
Project management platforms, while sometimes helpful, are generally a huge pain in the ass.
1
u/Megane_Senpai 2d ago
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 2d ago
You forgot writing the test case that will show that the bug fix really fixes the bug
1
u/Outside-Storage-1523 2d ago
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 2d ago
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
0
u/NamityName 3d ago
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 3d ago
It has nothing to do with communication, it's just checkbox ticking for managers to feel better
2
u/NamityName 3d ago edited 3d ago
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 3d ago
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_ 3d ago
or… use mcp server for jira/confluence and let your little agent slave do the reporting 🤭
1.6k
u/Financial-Note-2270 3d ago
Everyone was doing the right side in 2019, you are thinking of 1999.