Most businesses don't need "great" developers. They just need to get the work done.

Getting someone who is really skilled can of course be beneficial but it certainly has the problems of retention, things like providing interesting challenges, high compensation. Not all businesses have deeply interesting technical problems. That's fine. There is plenty of use for the wide parts of the bell curve fpr both businesses and developers.

Yep. I once worked at a manufacturing company. Their clients sent order information via an FTP server. The orders were formatted as flat files, aka just simple text files. I had to create code that painsakingly looked through each format and imported it into the new ERP system. Every vendor was different in each flat file. I'm sure some had similarities, but abstracting the logic was more dangerous in this case.

A lot of business software is boring. It does not take skill to do. It only requires someone to know a handful of tools and be willing to put in the time. So my advice to non-FAANG developers: if you want to make development your career, learn to be bored. Still work on marketable skills, learn new languages, etc. But remember that not every task will be an interesting new technical issue, it's probably going to be something you've seen a hundred times before.

> A lot of business software is boring. It does not take skill to do.

I guess it depends on your definition of "skill". ERP systems are complex, full of problems, inflexible and managed by bean-counters with "battle-axe" personalities. If you look at the work holistically, it does take skill and experience. There is a lot of room for improvement in these systems but the problems involve people as much as they involve technology.

>So my advice to non-FAANG developers: if you want to make development your career, learn to be bored.

is life at FANG really that different tho? Can't imagine that everyone is working on exciting stuff all the time. Would appreciate if someone could enlighten me.

I can speak for only one of the FAANGs, but the work I do there is definitely the most exciting to me personally from all the companies I've been at. There are challenging technical problems that require discussion with other engineers to design a solution. In most companies I've been before the challenges were mostly organizational and I had to deal with all of the "agile" crap to please PMs and managers, while the actual technical work was boringly easy.

It's not always rainbows and butterflies here either but I do feel much happier with the work I do here.

Well somebody has to be the one to annotate a million private and public SDK’s with @nullable !!

And once you’re done with that, there’s a whole load more refactoring for the latest language update!

The only difference at (most of) Google is that you would use grpc instead of ftp and protobuf instead of txt.

Maybe if you have a lot of money lying around. But in my experience this enterprise forms of development leads to ballooning team size and mediocre software.

The same software build by a small team of experts would cost both less, and lead to a high quality result.

I agree with this. It's probably better to have an average, good developer who is reliable and consistent, than a brilliant developer with risks of overengineering a product or system, burn out, poached, or seek new pastures.

It might also relate to intellectual satisfaction. A "great" developer could be hungrier in that sense, that they need worthwhile projects to challenge their skills - and may get bored more easily.