The worst kind of programmer

This whole article reeks of imposter syndrome. Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad, and that the author's inability to understand technologies like Rx, validation and testing frameworks is actually a hidden strength because it makes him some perfectly interchangeable lowest common denominator developer. I hate/hated working with Rx, but it is fundamentally not challenging or complex.

This story is common because the types of people who are capable of single-handedly building large parts of a software product in a short time are naturally the ones who are "hyper-productive" and leveraging a tonne of different technologies and paradigms. The unexceptional "slow and steady" devs are usually not capable of having that kind of impact. When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce.

Ultimately, the onus is on businesses to avoid crutching themselves entirely on a single developer's output. But there are a heap of shitty businesses that have no method for delivering software other than to let singular, highly motivated and passionate developers "go HAM" on the codebase with no oversight. These businesses deserve to fail, and the unmaintainability of the code base after the departure of their key players represents the correction of a market anomaly.

>Then suddenly, the frontend lead quit for greener pastures

What does this even mean? Key personnel do not "suddenly" quit.

Looks like your FP zealots didnt learn how to compromise on that point or how to work with constness in general.

They told or were willing for their leads to start building stuff out on their own. The rest of the team were "slacking off because business requirements were in the works".

They had no review of what the leads were doing. They did not involve the rest of the team in the design and build of the frameworks. The leads, also in the absence of firm business requirements produced highly abstract systems that could cater to many different requirements. The rest of the team couldn't understand it and it was bug prone (and presumably hard to debug).

I assume that these frameworks had to be ready by the time the fabled business requirements were finally produced, so there would be some time pressure to deliver them.

I have no idea whether the leads bear much responsibility here from what was written. I do know that the way they write software is very likely to produce this kind of result.

Go was designed to specifically address many pragmatic issues at Google, such as slow compile times, engineer ramp up time, language complexity causing hard to understand code, ease of writing automated tooling, and more.

https://go.dev/talks/2012/splash.article