Yeah, I was working on more of an infra thing (involving caching and indexing). Certainly important given the size of the company, but not something that gets lots of hype or sexiness.

There were occasional bits of ambition to occasionally work on interesting stuff, but it was mostly a “keep the lights on and then figure out how to make yourself seem important”.

One of my biggest pet peeves is when engineers say that we can’t do something because we would have to learn something new. I got into several arguments because I wanted to rewrite some buggy mutex-heavy code (that kept getting me paged in the middle of the night) with ZeroMQ, and people acted like learning it was some insurmountable challenge. My response would usually be something to the effect of “I’m sorry, I was under the impression that we were engineers, and that we had the ability to learn new things”.

As I said, complaints about my attitude weren’t completely unfounded, but it’s just immensely frustrating for people using their unwillingness to learn new things as an excuse to keep some code in a broken state.

I think i found something even better. I'm just adjacent to the big money maker. We keep folks on the page a little longer but don't need to concern ourselves with revenue and ads. Just make it good so folks stick around but important enough that we won't get axed.

> Big companies are significantly better to work in when you're either (...)

You're basically stating that people who are hired to staff projects that are superfluous secondary moonshots are more likely to be fired than those who maintain core business areas. That's stating the obvious. When a company goes through spending cuts, the first things to go are the money sinks and fluff projects that are not in any key roadmap. This is also why some companies structure their whole orgs around specific projects and even project features, because management limits the impact of getting rid of entire teams by framing that as killing projects or delays in roadmap.