Comment by datadrivenangel 12 hours ago
Unless you work on a dysfunctional team and any non-tracked work is forbidden, and any work you try and get tracked requires 6 pages of justification and takes 10 weeks to get prioritized enough for someone to work on...
I’ve been on both sides of this equation. If someone is dinging you for doing extra work, it could be a sign that your priorities are not aligned.
Like, if you’ve got a tight deadline coming up, it’s not the time to spend a week making CI slightly faster. On the other hand, if someone is telling you to not do work (right now), then they also need to help be responsible for finding time to do that work and understanding the impacts of that work never gets done.
I explain this to people as the tension between important urgent work. Some work is important but never（rarely) urgent. And if you ignore important work (like maintenance) it might become urgent at a very bad time.
Also there is value in having an audit trail of who did what when and why, both for operations and system evolution, and for all the compliance junk. Not so much value that a tiny bit of cleanup needs a huge amount of overhead though.
If you want a trail, there is already the PR. It has description that explains why the change makes sense, code changes, reviewers, if relevant screenshots and videos.
If you want small PRs that contain one meaningful, easy to review change, and that change only concerns the development team, there is no reason to create a ticket for the sake of creating a ticket.
Also, in some dysfunctional teams creating a ticket means it requires prioritization and you will most likely never work on it and ticket will be deleted five years from today when nobody you know with at the company anymore.
Believe me, no sane CFO (or include any person not in the dev team or product team) will look up your Jira ticket explaining why you wanted to refactor the GitHub actions because you had to update 10 files whenever there’s is a new version of a tool used in your pipeline.
Also, usually these changes are so small and straightforward, arguing about putting it in a ticket takes longer than reviewing it and merging it.
The most important properties of real audit trails are that they are side effects of the actual work, created during or after the fact without interfering with how the work is done.
The thing about work tickets is that they have none of those properties. Besides almost every developer insists on working with a complete audit trail that is just ignored because people don't want to look at it.
Compliance guarantee is a different beast, that isn't improved in any way by work tickets, but may need more work than the audit trail.
Except then you can get your wrist slapped for starting work on a ticket without prioritization. A rigid enough process slowly kills everything.
I use MCP for this now.
A crappy form filled ticket by an AI is slightly better than no ticket.
Doesn't that work against you? Like, I imagine that at some point you want to get a raise, so your manager has to sell your work to other managers... and they are not gonna pass around links to your pull requests/commits. They most likely want to see epics/tasks in Jira or something similar.
I mean, finding a Jira epic/project where to fit my ticket is not the hardest part of the job tbh. Also, depending on the team and your experience, loosely fixing things here and there can be a red flag or totally the opposite (e.g., I've seen how juniors or people in general with less than a decade of experience get punished when they start fixing random things here and there. On the other side seniors or staff engineers get kudos for fixing also random things but in less volume and usually more tricky ones).
Having a ticket to back up your work is never going to hurt you, though.
why do you want to do work and not get credit for?
One of the biggest career mistakes is doing things on your own that are not aligned and approved with the management chain. Even if makes 100% sense.
They might look past it once or twice but you will get managed out eventually. Doesn't matter how good you are.
You can either laugh or cry about it. Laughing is more fun.
This is nearly the norm for ENTERPRISE software development, and it's such a tragedy.
Wait, is your question serious, and people talking about it being in jest directed at my comment and not the one above it?
How often do you think the OP's "functional" team fixes small problems with their code before they become large problems? How often do you think they discover small features that lead to huge gains but need a developer's understanding of sized to discover it's small? And also, how often do you think they get stuck creating nearly impossible features that can be worked around with a small amount of work from the users that they would rather not do?
And none of those is the large issue anyway. The large issue is that teams working like that can barely create any software, for much more complex reasons than fits in a comment.
My team isnt dysfunctional but I always get hit on the head for doing work and not making a ticket. I don't get it, if I see something bad I'm not going to search which ticket would best fit this issue. Just reviw my PR !
Also, so far most of our projects start simple but end in chaos and deadlines on the minute. I feel like we could always do better.