3 ms·

Not everyone finds BigCorp problems to be the interesting problems. Not everyone wants to live in the Bay Area. There's a lot of jobs in the world that aren't a

by cwyers 7y ago

Not everyone finds BigCorp problems to be the interesting problems. Not everyone wants to live in the Bay Area. There's a lot of jobs in the world that aren't at FAANG, and it's okay if the right job for someone is at a place whose entire dev shop is smaller than the team at Google that maintains Blaze. If you find yourself in a job like that, it is absolutely the right call to invest in the best commodity tools you can (where best is a local, not a global, maxima) and focus on the things you can do that add value to your org.

paulie_a 7y ago
There seems to be an elitism when it comes to working for faang. there are a ton of people that have zero interest in building advertising engines or living in the Bay area. Quite frankly my min salary for having to live there sacrifice working on something interesting with be mid to high 6 figures so I could save and move the hell away after a few years. I'd consider it a life sacrifice to endure the bay area and culture.
- hashhar 7y ago
  I agree with your points but just want to add my anecdotal experience here from India that not all companies with great internal tooling are unicorns. They generally tend to be the slow but steadily moving companies who take their time and think about sustainability rather than 10x growth.
  - lifeisstillgood 7y ago
    Yes. And I might suggest that the unicorns with great tooling just lucked out and has engineers who built great stuff irrespective of management
- Youden 7y ago
  I feel similarly but I find it to be the Bay Area that's the problem rather than FAANG. All those startups and unicorns being in one place makes people see the Bay Area as some kind of software engineering Mecca and I think engineers based there subconsciously see themselves as superior for being a part of it, especially given the high pay. If you go to another city or even better another country, even in the same company, things are very different. Having done so, I would never return to the Bay Area except for the reason you mentioned: to pile up enough money to leave it again.
geofft 7y ago
I get the argument, but one of the reasons Google has a bigger-than-a-whole-startup team to maintain Blaze is their build tool needs to do a whole bunch of things. At a startup, your build tool just needs to build your product, not a thousand different products in fifty different tech stacks that all use them slightly differently. Sometimes, your product will look close enough to an existing internal Google product that you should just use Bazel and call it done. Sometimes it won't, and maybe it makes sense more to write some really good build tooling than to coerce your product into being shaped like someone else's so you can feasibly write glue code. At the 50-person company I worked at 6-8 years ago, my team's product was custom Ubuntu-based OS images that booted appliance-style on customer hardware and ran our product full-screen. We had some very nice tooling based on the live CD creation stuff that would a) build our cross-platform code into Debian packages b) patch and rebuild a couple of Ubuntu packages, or fail the build c) generate a nice OSS compliance bundle and d) output a .iso as well as a directory of .debs for internal interactive testing (so you could upgrade a machine you'd already installed without reinstalling it). We wrote some small custom tooling to snapshot the Ubuntu repo metadata periodically (https://github.com/mokafive/apt-mirror https://github.com/mokafive/apt-mirror) and build using the snapshot as of the time the SVN branch was created. Keeping this system running, once it was built, took very little time - that project was briefly down to one engineer and I could keep writing code and trust the build system to work fine. If I needed to implement that today using the best commodity tools I could, I'd probably be in some sort of Dockerfile hell, and in fact I'd probably be strongly inclined to design the customer system on top of Docker somehow, even though it would be absolutely the wrong fit, simply because that's what everyone else's OS-image-building problems look like these days. I guess the flip side is that there are probably few startups building products like that, and many more startups where you're building a CRUD app in Rails^WNode.js and your value to the customer is that you're just doing a really good job of writing a CRUD app. That's fine and valuable, and there's an interpretation where it's my personal failing that I'm not really excited by that, even if it's delivering business value / helping the world / etc.. But it is how I feel (and my guess is the author feels the same way), and I once did leave a company because I felt, for lack of a better term, bored - I was having to invent my own opportunities to grow as an engineer, and it was made clear to me that I would get better performance reviews if I worked on less ambitious projects. And when I've been interviewing people at my current place, I've heard enough stories of people being equally bored at their current jobs at large companies. So - this isn't a BigCorp vs. startup argument, I think. It's an argument that different companies have different levels of appetite for build-and-encourage-internal-tooling vs. buy-and-conform-to-the-outside-world in their culture, and if you're an engineer who's going to be frustrated by the latter, look for a company (of any size) that believes in the former.
Youden 7y ago
Just want to point out that you can work at FAANG without working in the Bay Area, or even the US. Amazon of course has headquarters in Seattle and both Google and Facebook have large engineering offices not only outside the Bay Area but outside the US. I've found there to be a pretty huge difference in those offices, particularly the European offices. The staff is far more diverse (e.g. I'm on a 40 person team and the largest number of people from one country is 4) and the culture and attitude to work is completely different. Much less koolaid-drinking and much better work/life balance. People actually use their (much more generous) vacation time!
- SZJX 7y ago
  That's just the cultural difference between Europe and America in general. Nothing particularly related to the big corps. But you'd also have to consider that the pay is considerably less if you work in Europe compared with working in the US.

by cwyers 7y ago

paulie_a 7y ago

There seems to be an elitism when it comes to working for faang. there are a ton of people that have zero interest in building advertising engines or living in the Bay area. Quite frankly my min salary for having to live there sacrifice working on something interesting with be mid to high 6 figures so I could save and move the hell away after a few years. I'd consider it a life sacrifice to endure the bay area and culture.

hashhar 7y ago
I agree with your points but just want to add my anecdotal experience here from India that not all companies with great internal tooling are unicorns. They generally tend to be the slow but steadily moving companies who take their time and think about sustainability rather than 10x growth.
- lifeisstillgood 7y ago
  Yes. And I might suggest that the unicorns with great tooling just lucked out and has engineers who built great stuff irrespective of management
Youden 7y ago
I feel similarly but I find it to be the Bay Area that's the problem rather than FAANG. All those startups and unicorns being in one place makes people see the Bay Area as some kind of software engineering Mecca and I think engineers based there subconsciously see themselves as superior for being a part of it, especially given the high pay. If you go to another city or even better another country, even in the same company, things are very different. Having done so, I would never return to the Bay Area except for the reason you mentioned: to pile up enough money to leave it again.

geofft 7y ago

I get the argument, but one of the reasons Google has a bigger-than-a-whole-startup team to maintain Blaze is their build tool needs to do a whole bunch of things. At a startup, your build tool just needs to build your product, not a thousand different products in fifty different tech stacks that all use them slightly differently. Sometimes, your product will look close enough to an existing internal Google product that you should just use Bazel and call it done. Sometimes it won't, and maybe it makes sense more to write some really good build tooling than to coerce your product into being shaped like someone else's so you can feasibly write glue code. At the 50-person company I worked at 6-8 years ago, my team's product was custom Ubuntu-based OS images that booted appliance-style on customer hardware and ran our product full-screen. We had some very nice tooling based on the live CD creation stuff that would a) build our cross-platform code into Debian packages b) patch and rebuild a couple of Ubuntu packages, or fail the build c) generate a nice OSS compliance bundle and d) output a .iso as well as a directory of .debs for internal interactive testing (so you could upgrade a machine you'd already installed without reinstalling it). We wrote some small custom tooling to snapshot the Ubuntu repo metadata periodically (https://github.com/mokafive/apt-mirror https://github.com/mokafive/apt-mirror) and build using the snapshot as of the time the SVN branch was created. Keeping this system running, once it was built, took very little time - that project was briefly down to one engineer and I could keep writing code and trust the build system to work fine. If I needed to implement that today using the best commodity tools I could, I'd probably be in some sort of Dockerfile hell, and in fact I'd probably be strongly inclined to design the customer system on top of Docker somehow, even though it would be absolutely the wrong fit, simply because that's what everyone else's OS-image-building problems look like these days. I guess the flip side is that there are probably few startups building products like that, and many more startups where you're building a CRUD app in Rails^WNode.js and your value to the customer is that you're just doing a really good job of writing a CRUD app. That's fine and valuable, and there's an interpretation where it's my personal failing that I'm not really excited by that, even if it's delivering business value / helping the world / etc.. But it is how I feel (and my guess is the author feels the same way), and I once did leave a company because I felt, for lack of a better term, bored - I was having to invent my own opportunities to grow as an engineer, and it was made clear to me that I would get better performance reviews if I worked on less ambitious projects. And when I've been interviewing people at my current place, I've heard enough stories of people being equally bored at their current jobs at large companies. So - this isn't a BigCorp vs. startup argument, I think. It's an argument that different companies have different levels of appetite for build-and-encourage-internal-tooling vs. buy-and-conform-to-the-outside-world in their culture, and if you're an engineer who's going to be frustrated by the latter, look for a company (of any size) that believes in the former.

Youden 7y ago

Just want to point out that you can work at FAANG without working in the Bay Area, or even the US. Amazon of course has headquarters in Seattle and both Google and Facebook have large engineering offices not only outside the Bay Area but outside the US. I've found there to be a pretty huge difference in those offices, particularly the European offices. The staff is far more diverse (e.g. I'm on a 40 person team and the largest number of people from one country is 4) and the culture and attitude to work is completely different. Much less koolaid-drinking and much better work/life balance. People actually use their (much more generous) vacation time!

SZJX 7y ago
That's just the cultural difference between Europe and America in general. Nothing particularly related to the big corps. But you'd also have to consider that the pay is considerably less if you work in Europe compared with working in the US.