I like to fix things. Sometimes it might be a bug (the weirder, and seemingly impossible, the better). Sometimes it might be reconciling a disagreement across teams. Sometimes itās a bad process.
Sometimes tracking something down is harder than expected. Sometimes follow-through can be arduous and exhausting. While I generally feel worn out and lacking capacity, sometimes these sorts of wild goose chases are energizing.
A few of these came together for me today. One came up while I was reviewing a CL. I have a habit that may be bad or may sometimes be helpful where I tend to write out a lot of example code when reviewing. Itās often āwhat do you think of this?ā, or demonstrating a neat library function that saves a bunch of boilerplate, or whatever. That was off-topic, it happens. I got to one file in the CL and there were 184 informational messages about some existing annotations in unchanged lines. There was maybe like, one line added to this file, but finding it was super hard because there would be this informational message with 15-20 lines of context around it over and over. You would be right to think that this is not an optimal setup for a single source file. Thatās true, and should be addressed, but maybe tomorrow.
I finished my review, left comments, but then went searching. I found the custom lint rule, then started looking to see if I could change it to only apply to changed or added lines. It wasnāt obvious, so I looked at the commit history and messaged the two people who had worked on it. There was a bit of back and forth, but we were all in agreement that this wasnāt the desired behavior. There was then meta discussion about how to fix this (should all the checks for this analyzer default to hide on unchanged lines?), but ultimately it is getting fixed (and I was able to step back from it). Keeping a useful rule, but only bothering people actively when they make a mistake versus having to wade through dozens of messages you likely wonāt be fixing now, feels like a big win. While we were discussing it was also determined that there was another instance of the same check being run in a different analyzer, which was wasteful (it did seem to be suppressing on unchanged lines, though!), so thatās a bonus fix!
Another case is that there is a document thatās been sort of foundational for a certain posture our org has taken (until now), that is often linked and quoted. This may be shaken up soon, but this document is still a monument to the old approach. Iād like to add a caveat/warning so folk donāt keep quoting this as the one eternal decision on this matter. The document is owned by someone who is long gone. Their last manager is gone. Everyone is gone. No one is an editor. We have shortcuts at Google called āgo/ linksā, which are vanity, shortened URLs made to look pretty in chats and documents, but are rarely memorizable. I have recovered ownership of the go/ link, but not the document itself. Pointing the go/ link to a copy of the doc or something could work, but people could still access and quote the original and not know thereās an updated version. So I want to get control of the backing doc. I donāt even want it myself, I just want someone still at Google to have it and get a few people edit access again. I reached out to anyone credited at the top of the doc, none were editors. I filed a request to have ownership transferred, which is now sitting at a VP because no one lower in the chain is still at Google. I have now followed up with the Admin Partner (EA) for this VP to explain the plight and see if she can get eyes on the request this week. I will get control of this document, get editors added, and hand ownership off/put it on a shared drive, but it has required way more follow-through than expected.