Like I mentioned above. If I want quality, then I alone make this decision. If anyone wants to join, they join on my terms. I will make my terms uncompromising and uncomfortable for people who want consensus deliberately because I don't want to work with people who want consensus -- they suck at programming.
For my day job, I work with people who want consensus, an easy way to slack, pretend to work, hit the lowest bar available to pick the paycheck and go home, watch TV, play guitar, whatever. They don't produce anything that resembles quality work. Never will. That's not their goal, nor do they feel bad for not accomplishing that.
> Who's going to maintain that? Why wasn't this discussed?
Whoever knows how to program will.
It wasn't discussed because I wouldn't care about an opinion coming from someone who doesn't know how to program. Same way how I don't ask the neighbor's cat when I make programming decisions.
> Have you even considered code reviews? ... if no one else knows the language and _knows it well_?
Yes. I considered. This is their problem, not mine. If you want to be a programmer, it's your job to know your tools well. If you want a fat paycheck and be a useless blight on the bloat of the corporate world... well, make up the rules that are even more convenient to you...
> in love with tech
This has nothing to do with being "in love with tech". This is about the quality of output of people who are employed as programmers but aren't. One can be "in love" and suck, while other can "hate" and be very good at what they do. The reason why the situation the way it is that that human nature which pushes everyone towards a place where they can be lazy and ignorant meets no resistance.
While in many other professions there's a market for high-quality products, like very expensive and very high-quality watches, cars, photo equipment, clothes, food... in programming there's no market for anything that's trying for quality rather than time to market, price or reach. There's no niche, when it comes to programming market that would pay tenfold or hundred times more for a higher-quality product. That's why in industrial setting nobody is trying to make high-quality products, even though some, naively, come with this idea into the trade, they are quickly shown the reality where nobody cares.
1)
Whenever a new framework is introduced this usually requires broad consent, clear scope, and agreement on committing to this new direction, doubly so when it's introducing a new language. Do you embark on working on these projects without discussing what you'll be doing?
If I was managing a RoR project and someone went off for a week or two and came back with projects written in Prolog I'd be livid. Who's going to maintain that? Why wasn't this discussed?
Have you even considered code reviews? How are you going to have useful code reviews if no one else knows the language and _knows it well_?
I understand writing one-time use tools in whatever language you want if you're the only one who's going to be using it, but otherwise, it makes the most sense to stick to the team's strengths when in a commercial project.
2)
It took me time to come to terms with the fact that not everybody working professionally in software is passionate about tech/software/languages. Some people just view it as a dayjob and prefer to stick to the known, well-trodden paths rather than exploring the field (an old boss would often make the distinction between dayjobbers and technologists aka people that are in love with tech).
Often great is the enemy of good enough and the most important part of working professionally in dev, for the vast majority of cases, is hitting the mvp and ensuring maintainability. Sometimes the time investment is better used elsewhere.
Channel your passion towards your personal projects and/or open source projects, not at work (unless the environment is conducive to that).
Now, startups are a wonderful place for mixing passion with work and a big exception to the above, usually there's a lot of room for experimenting and coming up with clever/complex/out-of-the-box solutions to problems.