Having come from Etsy and witnessed the success of this type of thinking first hand, I think you missed the point of the article and I think you are using a tiny engineering organization (4 people) in your thinking, instead of a medium to large one (120+ engineers).
The problem isn't "we are starting a new codebase with 4 engineers, are we qualified to choose the right technology?" it's "we are solving a new problem, within a massive org/codebase, that could probably be solved more directly with a different set of technologies than the existing ones the rest of the company is using. Is that worth the overhead?" and the answer is almost always no. Ie: is local optimization worth the overhead?
Local optimization is extremely tempting no matter who you are, where you are. It's always easy to reach a point of frustration and come to the line of reasoning of "I don't get why we are wasting so much time to ship this product using the 'old' stuff when we could just use 'newstuff' and get it out the door in the next week." This happens to engineers of all levels, especially in a continuous deployment, "Just Ship" culture. The point of the article is that local optimization gives you this tiny boost in the beginning for a long term cost that eventually moves the organization is a direction of shipping less. It's not that innovative technologies are bad.
> But if you know what you're doing, you choose good technologies
No, if you know what you are doing you make good organizational decisions. It matters less what technology you use than that the entire organization uses the same technology. Etsy has a great engineering team and yet the entire site is written in PHP. I don't think there is a single engineer working at Etsy who thinks PHP is the best language out there, but the decision to be made at the time was "there is a site using PHP, some Python, some Ruby etc., how do we make this easier to work on?" Of those three python and ruby are almost universally thought of as better languages than PHP, but in this case the correct decision was picking a worse technology because more of the site was written in it, the existing infrastructure supported it more completely and so as an organization and a business we could get back to shipping products more quickly by all agreeing to use PHP. Etsy certainly does not think of its engineers as monkeys, quite the opposite.
This optimization may as well become global when it'll come to hiring in the future. Quote from the post:
[...] what it is about the current stack that makes
solving the problem prohibitively expensive and difficult
Etsy, as a very successful PHP shop, surely understands that PHP codebase itself presents an expense in a form of non-hired smart engineers that pass on the company because they won't work with this language.
Plus, there are examples when the local optimization (i.e. staying with whatever legacy stack because it's proven) may lead to a global failure because of the unmaintainable "spaghetti blob" codebase with duck tape everywhere.
To me, that explains why Etsy has trouble with new tools and languages - they can't hire the developers it'd take to successfully run a project outside of the tools they are used to.
Analogously, if you promote by external hiring, you hemorrhage the kind of employee you'd want to promote internally. If you always stay in a particular sandbox, you lose the kind of employee that can work outside it.
If PHP is a deal breaker then that person isn't the type of person you want to hire, since they obviously care more about incidental issues like language choice than solving real problems. That's not to say people can't groan about it (like any other workplace annoyance) but I'll still go work somewhere doing amazing things even if the cafeteria food kind of sucks.
Anecdotally, it usually turns out that good engineering practices can be brought into any medium. PHP comes with a higher than average number of foot guns, and there is a lot of terrible PHP code out there that is unfortunate to find when you Google something, but it's self evident that a good engineering organization can build solid systems in PHP. (See also: the diligent use of a specific set of C++ features in shops building cutting edge graphics/game technology.)
It's not incidental -- choice of language has a massive impact on your developers' day-to-day experience as a human being, and many of the best programmers will find themselves incredibly frustrated by using a language like PHP (not because of ego but because PHP has properties which makes it frustrating to work with).
Of course, from a certain mindset I suppose anyone unwilling to sacrifice their happiness on the altar of your corporation's profit might be dubious... the question then becomes whether this affects recruitment and retention, and if so, whether you can still accomplish the things you want with mediocre talent and high turnover...
You see C++ used in graphics/game because it strength is low level memory/cpu control needed for cutting edge work. PHP is optimized for "time-to-market" not cutting edge, so chances are the "real problems" you want to hire for are not that interesting. Heck, a big advantage is PHP is that most of the problems you encounter are already solved for you.
Most of the time, "use of PHP" correlates to "not really interesting problems", so is a good proxy to use when deciding where to work :)
The truth is that even at great companies there is plenty of "crud work" to do. It is important work and you are solving real problems but there is little personal/professional growth or learning.
One way to keep that kind of work interesting and to provide growth and learning is to use new/different tools and technology to do it.
I totally agree, that's why I said medium to large. My main point is that you are solving radically different problems with even 20+ engineers than you are with only 5 or so.
Both Facebook and Google (!) aren't really large-scale by the standards of tech companies gone by. Facebook has about 9000 employees. Google has 50,000. By contrast, Microsoft has 128,000, HP has 300,000, IBM has almost 400,000, and DEC had about 300,000 at its peak.
In the startup world, we (rightly) focus on growth, but it's worth remembering that there are giant companies out there using really, really boring technology. In some segments IBM mainframes, DB2, and COBOL are still the technologies of choice.
To add to what you're saying there are also government departments and giant companies out there that do your tax, pay for the roads, handle your insurance and handle your banking where somebody 20 years ago chose a technology that wasn't boring.
These entities are now having huge problems trying to get off 1980s or 1990s non-boring non-standard technologies that are no longer supported.
There are places that have bought the company that was going insolvent that built their non-standard database or framework....
"Nobody ever got fired for buying IBM" had good reason behind it.
A lot are consultants, at least at HP and IBM. (Microsoft and DEC are much more engineering-heavy; I've heard that Microsoft has the structure of 1 engineer, 1 PM, and 1 tester per team.) Remember that out of Google's headcount, only about 20,000 are engineers. When I was on Search, Bing had more engineers working on it than Google Search.
> By your measure, Facebook is still not a large-scale engineering organization
"9,199 employees as of December 31, 2014" -- that's probably close enough to his metric to call it a large-scale engineering organization.
Of course, there's the real question of why Facebook needs to be a 10k+ engineer organization. For a minute it looked like they'd grow past their MySpace 2.0 roots. That becomes less convincing every day.
Ah nice catch, I misread the quote as 9k engineers. That said, after seeing their new offices, I'm not sure I can retract the general sentiment of my previous post.
The problem isn't "we are starting a new codebase with 4 engineers, are we qualified to choose the right technology?" it's "we are solving a new problem, within a massive org/codebase, that could probably be solved more directly with a different set of technologies than the existing ones the rest of the company is using. Is that worth the overhead?" and the answer is almost always no. Ie: is local optimization worth the overhead?
Local optimization is extremely tempting no matter who you are, where you are. It's always easy to reach a point of frustration and come to the line of reasoning of "I don't get why we are wasting so much time to ship this product using the 'old' stuff when we could just use 'newstuff' and get it out the door in the next week." This happens to engineers of all levels, especially in a continuous deployment, "Just Ship" culture. The point of the article is that local optimization gives you this tiny boost in the beginning for a long term cost that eventually moves the organization is a direction of shipping less. It's not that innovative technologies are bad.
> But if you know what you're doing, you choose good technologies
No, if you know what you are doing you make good organizational decisions. It matters less what technology you use than that the entire organization uses the same technology. Etsy has a great engineering team and yet the entire site is written in PHP. I don't think there is a single engineer working at Etsy who thinks PHP is the best language out there, but the decision to be made at the time was "there is a site using PHP, some Python, some Ruby etc., how do we make this easier to work on?" Of those three python and ruby are almost universally thought of as better languages than PHP, but in this case the correct decision was picking a worse technology because more of the site was written in it, the existing infrastructure supported it more completely and so as an organization and a business we could get back to shipping products more quickly by all agreeing to use PHP. Etsy certainly does not think of its engineers as monkeys, quite the opposite.