Et Tu, Grammarly?

I passed this along to the engineering team.

thanks!

You bet!

This is fairly unrealted, but it irks me when one-line fixes like this sit for ages in backlog hell. I want a company where developers go "might as well fix that now, it's faster than writing a ticket for it".

I see people where I work not do this, and it drives me crazy. Our director of engineering will literally add tickets for himself to do things that would take less time to just do. At least I hear "I took a page from your book and messaged the person instead of adding a ticket for myself to message them" often, which is a good sign.

> Our director of engineering will literally add tickets for himself to do things that would take less time to just do

I've done this. It irks me too, but sometimes I'm in organizational mode, and sometimes I'm in execution mode. :)

Also, I work in an environment[0] where all work is required to go through the formal tracker documentation flow (and all code changes must be approved by a second party).

So the ticket step is non-optional, and in fact required before work can begin -- we name branches with the ticket ID, so that Pivotal[1] can track the GitHub lifecycle.

[0] PCI-DSS, SOC 2, etc

[1] RIP :(

Yeah, I guess if you're in a regulated environment, you have no choice. Most companies have no excuse, though!

To be clear, I'm answering this purely from a personal standpoint and not talking about any particular employer, and this doesn't relate to this specific issue at all.

Yes, I totally agree. The point of processes is to enable a company to manage huge amounts of potential work. Sometimes, processes can get in the way of just doing the simple thing we all know needs to be done.

Buuuut, I've been on the other side of that, too. Someone asks me to make some change. Sure! That's a reasonable idea and it would improve things. Making the change would take about 20 minutes. However, 437 different systems expect that thing to have its current behavior, and updating them to use the new behavior would be quite the project. In a vacuum, the change is simple and shouldn't take long to implement. Not many things operate in a vacuum, though.

For example, it would take like 5 minutes to do a "find all" in the Nginx source code and fix the misspelling of "referrer" as "referer". It would take a lot longer to update the standards with the correct spelling, and every client and other server to use it, would be slightly more challenging.

Sure, but that's not what I'm talking about. That's not a change that takes 20 minutes, that's a change that takes years.

I'm talking about things like fixing a typo, where it literally takes multiple times the work to write the ticket than to grep for it, fix it, and push a PR.

Yeah, I hear ya. Sometimes people seem to do bookkeeping just for the sheer joy of bookkeeping, or something.