> The pipeline didn’t record many metrics. The ones it did have made it look like things had gotten worse. My bug discoveries caused the overall bug count to increase. The pipeline’s failures increased because I made it fail fast on anomalies instead of silently passing along bad data.
I understand why the author might think this is better, but all software have bugs and a lot of data is tainted by those bugs. Was fixing the pipeline an actual priority? Was it critical? If so, how were the downstream internal customers dealing with the new exceptions? Why were they not raising a ruckus about it? Why was the author allowed to move on to a different project if there were so many bugs in that pipeline deserving of a promotion?
I have met more people in life that made a big deal out of ultimately unimportant details than the opposite. Internal pipelines usually have a lower bar and the downstream consumer may not even care about 75% of features that are just there and unused. Being a senior engineering is also knowing when to leave good enough alone.
> My other work didn’t look so good on paper either. On several occasions, I put my projects on hold for weeks or even months at a time to help a teammate whose launch was at risk. It was the right decision for the team, but it looked unimpressive in a promo packet. To the promotion committee, my teammate’s project was the big, important work that demanded coordination from multiple developers. If they hornswoggled me into helping them, it’s evidence of their strong leadership qualities. I was just the mindless peon whose work was so irrelevant that it could be pre-empted at a moment’s notice.
Is that conclusion really wrong? It's a bit uncharitable for sure but that is indeed what happened not just how it appeared to have happened. If your project was such a low priority that dropping it for several months does not flash a red light in someone's dashboard, then I am sorry but that does not seem promotion worthy.
The little comic also has good examples that things that imo are not "senior" work. Writing E2E tests for a product that is already shipped is worthwhile, but unless it's something very special it's not complex enough, does not require enough design to be considered "senior work".
Again I don't know the guy, maybe he did get an unfair read on his body of work, but reading the entire blog I mostly get the vibes of "I worked 2 years at Google and then wanted to be a senior so I rushed my promo packet without a cornerstone project" and the committee refusing that is just the system working as intended.