Tools you’d miss if you left a company

Isn't the point that they often don't need those tools? I've lost track of the number of "I replaced Hadoop with Excel!" blog posts I've read.

A previous employer had an all-proprietary stack: language, IDE, version control, deployment system, database, job scheduler. It was, frankly, amazing. The most productive environment I’ve ever worked in. Time-to-market was this company’s competitive advantage and this stack let them leave their competitors in the dust, scrabbling for a distant second place.

everyone has access to the best tools,

It’s 5 years since I left there and the FOSS tooling we use at my present company doesn’t come close, and it never will, because choices are driven from the basic assumption that FOSS is always best, and it just isn’t true. We are at least 5 years behind where the previous company was when I left it and they won’t have stood still in that time.

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) 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.