4 ms·

As an outsider of Big co's. I always felt that if youre not on one of the 10-20 awesome product teams. Eg, Google maps, aws lambda, windows core os. Something a

• nunez 9mo ago
  Couldn't be more on the nose. Big companies are significantly better to work in when you're either (a) in sales with a clear path to hitting/exceeding quota, (b) a strategic revenue generator, or (c) a super hot and extremely well funded corporate initiative (basically all AI projects right now). The money tap is always on, you get all the cool toys, travel perks are great, and you get to work on amazing stuff without as much red tape.
  • tombert 9mo ago
    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.
    • jmalicki 9mo ago
      You're complaining about resume driven development in the same thread you're upset they wouldn't let you rewrite everything in ZeroMQ? That is a very inconsistent position, and reflects extreme confirmation bias, and by itself justifies that you may need to look in the mirror.
      • tombert 9mo ago
        I didn’t want to rewrite everything in ZeroMQ. I wanted to rewrite one 2000 line service with ZeroMQ because the service was already broken and I was the only person who was dealing with the consequences because I was the only person who got paged for that particular service. Usually I advocated for doing things a more boring way, and I certainly don’t agree with making every damn thing an “initiative”, which was my biggest issue at BigCo. I don’t think it’s inconsistent. I wanted to use the right tool for the right job. Usually I can get by with Java’s built in tooling, and that was my initial attempt at a rewrite, but I ended up trying to re-invent a bunch of concurrency patterns with BlockingQueue and I found that literally everything I was spending a lot of (my own free) time was handled in like four lines of ZeroMQ. I have a single line on my resume for ZeroMQ as a keyword, despite having used it in many, many projects, so it certainly wasn’t using explicitly to pad my resume.
      • FourierSerious 9mo ago
        If @tombert worked for me at BigCo, I'd give them a big raise for doing the exact right thing. This is Employee of the Year performance. @tombert recognized that the homegrown tech was awful (*) and proposed a mature, reliable, well documented and supported, low-cost, utterly mainstream and mature replacement. That's not resume packing, that's pragmatic, rational software design. @tombert also knows that every tech professional must routinely learn new things, otherwise they'll be unemployable dinosaurs long before retirement age. Tech dinosaurs aren't a pretty thing in the workplace. (*) Especially awful because these are mutex and concurrency bugs, and @tombert knew that nondeterministic bugs cost expensive resources to investigate, find, and fix, simply because these bugs are unreproducible. Unlike straightforward deterministic bugs, concurrency bugs are open-ended tar pits that managers and engineers despise. These kind of bugs can eat up a project's schedule and energy. edited: formatting bug. Fortunately it was reproducible!
  • 8n4vidtmkvmk 9mo ago
    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.
  • locknitpicker 9mo ago
    > 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.