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.
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.
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.
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 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.
You get credit for fixing the issue, avoid giant fix-along-the-way PRs, and future credit for people (maybe even you) understanding why you those changes were made.
To put it a different way: it's better to ask forgiveness than permission. Creating a ticket is like asking permission (as the project managers will see the ticket and start asking questions about why time is being spent on low-priority things). Just going ahead and pushing code is asking forgiveness - sure, someone might notice after the fact that you did some work that you weren't assigned to do, but by that point it will be considered irrelevant, as long as your other responsibilities were handled on-time.
If you've never worked at a company where these political games are necessary - count your lucky stars!
The adult thing (hard but responsible) to do, is to create a ticket, then allocate time for feelings of the manager.
(including cost-benefit ratio comparison between “this dealing with the manager” vs “fixed thing” might be tempting)
I've worked at several places that use Jira, and none of this stuff ever happened. I've helped make sure that's the case, of course, but I don't think I've had anyone I've worked with question an individual ticket's priority.
A crappy form filled ticket by an AI is slightly better than no ticket.
i’ve seen so many random prs of engineers that thought this was the time to go on a rabbit whole and fix some random error they found. worse, i’ve seen regressions introduced on random “fix” PRs that had no description, no ticket, nothing. this is not team work. if you see an issue and you know how to fix it, by all means, fix it. but create a bug ticket with explicit current and expected behavior that people can read and test. if you don’t have time to create a ticket, then you don’t have time to fix random bugs
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.
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.