Yeah, I've run into all of those at times. There are some problems that are just inherent to working at a big company.
Most of the really frustrating ones are fairly avoidable if you (or your tech lead, if you're not leading the project) are reasonably adept at playing the big-company game. My usual reaction to deprecation of critical infrastructure is to complain loudly and persistently, and I can usually get a stay of execution for 6 months to a year, enough for someone else to be the early adopter and work out the kinks of the replacement, then move my own project over to it once it's stable. I've saved many hours for my team by continuing to use deprecated software until the replacement has been deprecated, and then switching straight to the replacement's replacement once it's stable.
The massive codebase is reasonably easy to navigate once you become adept with CodeSearch. Build performance problems are persistent, but I solve that by getting a new machine every time the opportunity presents itself and using them headless for builds & demos. I also open them up to my team so that other frontend engineers I work with can use them...I've got a mini server farm under my desk.
The legal/political/PR stuff can't really be helped, but I find that exhilarating in its own way, since you get to see how those systems work. I've learned to hate the Chinese government since working at Google, though.
BTW, all of these are potentially problems at a startup using open-source software and doing interesting things. It's just that there:
1.) Instead of worrying about your OS libraries being deprecated, you pull the version you want into your own source tree and never touch them, at least for several years. Any attempt to upgrade to a new version is met with intense pain, and so you push the problem off and hope that either your company will go bankrupt or you'll get bought by some big company and the programmers there will rewrite your software entirely.
2.) Instead of complying with the legal problems, you ignore them. If somebody pays attention to you, you're sued out of existence and all look for new jobs. If they don't, you go about your merry way and hope nobody looks too closely at you.
3.) Instead of your dependencies growing out of control....aww hell, every company I've worked at that's more than 6 months old has had dependencies that were out of control.
4.) Instead of being on a misguided project that in practice failed but didn't die, you're on a misguided project that will fail and die spectacularly. And then you get to do it again for the next startup.
Startups can be a lot of fun too, but understand, you're screwed regardless of what you do. :-) Engineering is hard. Let's go shopping!
Most of the really frustrating ones are fairly avoidable if you (or your tech lead, if you're not leading the project) are reasonably adept at playing the big-company game. My usual reaction to deprecation of critical infrastructure is to complain loudly and persistently, and I can usually get a stay of execution for 6 months to a year, enough for someone else to be the early adopter and work out the kinks of the replacement, then move my own project over to it once it's stable. I've saved many hours for my team by continuing to use deprecated software until the replacement has been deprecated, and then switching straight to the replacement's replacement once it's stable.
The massive codebase is reasonably easy to navigate once you become adept with CodeSearch. Build performance problems are persistent, but I solve that by getting a new machine every time the opportunity presents itself and using them headless for builds & demos. I also open them up to my team so that other frontend engineers I work with can use them...I've got a mini server farm under my desk.
The legal/political/PR stuff can't really be helped, but I find that exhilarating in its own way, since you get to see how those systems work. I've learned to hate the Chinese government since working at Google, though.
BTW, all of these are potentially problems at a startup using open-source software and doing interesting things. It's just that there:
1.) Instead of worrying about your OS libraries being deprecated, you pull the version you want into your own source tree and never touch them, at least for several years. Any attempt to upgrade to a new version is met with intense pain, and so you push the problem off and hope that either your company will go bankrupt or you'll get bought by some big company and the programmers there will rewrite your software entirely.
2.) Instead of complying with the legal problems, you ignore them. If somebody pays attention to you, you're sued out of existence and all look for new jobs. If they don't, you go about your merry way and hope nobody looks too closely at you.
3.) Instead of your dependencies growing out of control....aww hell, every company I've worked at that's more than 6 months old has had dependencies that were out of control.
4.) Instead of being on a misguided project that in practice failed but didn't die, you're on a misguided project that will fail and die spectacularly. And then you get to do it again for the next startup.
Startups can be a lot of fun too, but understand, you're screwed regardless of what you do. :-) Engineering is hard. Let's go shopping!