Just fill out a ticket. More data about problems gives your team more tools to work with when developing solutions. If there's a regular problem, but you fix it yourself every week instead of submitting a ticket, then it will remain an unknown problem and no permanent solution can ever be developed. It will also not be taken into account when developing new procedures or new products.
Just fill out a ticket, please.
Kind of the same comic as this, just less abstract:
😅
I feel like the guy on the right while everyone around me vibe codes things.
It doesn't pay (literally) to be too anti-AI, today.
I'll accept my trophy and bonus later, but I will feel slightly bad about it.
The fact that it’s the same artist makes this even funnier
But you should actually make those tickets because it allows you to track common issues and fix greater problems with the system. Those tickets are NOT meaningless "bureaucracy", they are a fundamental part of efficient development.
I once had a manager who didn't like me because, right after he joined my team as the new manager, we were at a meeting discussing a new software service, and I said that we didn't need to create that service because we already had a service that did the exact same thing.
It was our main service that we supported. Every non-new person on the team knew this was a ridiculous idea.
The manager didn't propose the idea. It was a different new person that the manager had brought with him from his previous team. So, I shot down the obviously bad idea. But it later turned out that the new manager had already supported the new service.
So anyways, he hated me because I unknowingly contradicted his judgement. I would have directly contradicted him had I known he supported it, anyways, because it was the wrong choice. I'm just making it clear how ridiculous the situation was and how terrible this manager is.
So, as a result, this manager decides to work against me and gives me a lot of operations work, knowing that our metrics are biased towards commits in the code base, and that this will make me look bad come review time.
I left his team shortly afterwards, but I can't say that his abhorrent behavior didn't bother me. I liked that team before he joined. Fuck that guy. And fuck metrics that don't show the whole picture.
The new guy who proposed the service ended up implementing it. By the way, his coding ability was worse than most of the interns we had, as well. I'm guessing that he and my manager were lovers or something, because nothing else would make sense. But at any rate, I'm sure his metrics looked awesome. Lots of commits making a completely redundant and useless service.
I’ve never received a satisfactory explanation what the difference between pro-active and active is. Like, every single example usage in the dictionary you could swap in “active” without changing the meaning.
The emphasis is distinction from reactive. Proactive means you act before something has occurred (for example to prevent it or to prepare for its occurrence), as opposed to reactive, which is acting after the fact. If you're fixing issues proactively, that means you anticipate that something is going to become a problem and change it, rather than waiting for it to become a problem and (reactively) fixing it.
Of course, the difficulty with appreciating the impact of proactivity is that it changes what happens and thus makes it harder to see what might have happened otherwise. If I (proactively) replace some machine part that was close to breaking, the result (business as usual) is less visible than if I had let it break (interrupting business) and (reactively) fixed it.
The "pro-" is derived from Ancient Greek and means "earlier" or "prior". So, "proactive" means to become active before something (typically bad) happens. It's the opposite of "reactive", which means to become active after something (bad) happens, i.e. in response to it.
An example: To help with fighting fires, you can proactively remove flammable materials or buy fire extinguishers. But if a fire breaks out anyways, then you have to deal with it reactively, a.k.a. react to it, by then making use of the fire extinguishers.
In both cases, you become active, but one time you become active before something happens (proactive), the other time you become active after something happens (reactive).
Well, and the things you do in those situations are generally also different. Proactively, you try to prevent a catastrophe from happening and prepare remedies in case it still happens anyways. Whereas reactively, you use those remedies to condemn the damage and try to get things back into working order as quickly as possible.
So it’s exactly the same as if you’re actively working on fire prevention, as I suggested.
And of course if you fix things proactively (before they happen) then that's likely to be expenditure which will be seen as unnecessary if/when it doesn't happen. So:
a) the best way to do it
AND
b) management will hate you for it.
