C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.

It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.

It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task

What I mean to say is that with a monorepo, you leave the door open to essentially passion-driven contributions made by the other half of that 2%. In non-monorepo environments, the barrier to uniform adoption is too high for someone that isn't full-time assigned to the task to justify.

Some people are genuinely passionate about this stuff, and want to take on the task of migrating the entire code base, because it's a fun challenge and it'll improve their day-to-day work every day for the remainder of their employment. They're very rare, but they do exist, and with a monorepo those people are better-equipped to drag the company forward.

I have some news - passion is not enough, and there are more than 2% of people working on things they are passionate about - it only 2% get lucky.

I can think of a few instances in my recent career at large monorepo company where I have built something on the scale of "passionate, could improve our working lives"

One died because ... well I gave up, two are used locally by my team and those I could persuade, whilst other solutions built by others for the same fix have gone on to be blessed officially, (ie replaced by grassroots competition) and one was replaced by a fully mandated and funded project that spotted the need and just steamrollered over all the local fixes.

One is still outstanding and I think well worth pushing still.

But I don't dream of the big win where suddenly the Board says "why, without your glasses Miss Moneypenny you look ravishing".

I get paid, I work, and I try and make the world a bit better where I can. I am passionate about it. But i don't write blog posts about how passionate I am.

Maybe I should :-)

As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)

It's been used at every workplace I've been at, sometimes well, sometimes not so well, just like any language. No idea what the point of blanket statements like this is.

https://w3techs.com/technologies/details/pl-php claims ~79% of websites whose backend is known use PHP.

https://w3techs.com/technologies/details/pl-ruby shows Ruby has grown from 2.5-3.5% over the last year.

Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.

But now that I'm older, I appreciate things being more descriptive and orderly, including strict use of semicolons, functions that say what they are doing (e.g. to_string), or being explicit about converting (e.g. static_cast<type>)

I think it's because I find trying to make everything as succinct as possible ends up trying to be too clever.

Long-term memory is similar, while it's not bounded in the same way it takes time and effort to develop. I'd rather type `git new-branch` than have to remember `git checkout -b` and I certainly don't alias it to `git nb` or something: I can type `git n<TAB>` and let that complete it.

I find myself more annoyed by dynamic languages, because the tooling just isn't at the same level. All sorts of 'hints' that I rely on in java simply aren't there in other languages, and the ide throws up it's hands and is like '...? I guess this is right? Godspeed sir', and I wind up having to go lookup documentation rather than ctrl clicking into underlying functions and code. It's really annoying, and it's made me be more appreciative of staticly typed languages.