Write Junior Code

There is the theory that 5 highly skilled developers can do the job of 10 average developers, but in practice this often doesn't pan out. I'm not saying it never works, but it just doesn't seem to be a sure-shot strategy.

Part of the reason is that "soft skills" such as getting along with the team, writing well, understanding likely user behavior and the domain, making smart trade-offs, etc. also matter, and often times the technically "elite" lack these. Software development should be viewed as making tools for humans, not really for machines, and understanding humans is part of this.

Regarding your debugging edit: If one wants to spread the use of functional, perhaps finding a making a good guide and tutorial on debugging it would be helpful. I seem to be applying my imperative debugging thinking to it, and it doesn't fit well. I need to overhaul my debugging mind, not just my code mind.

Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that starting from first principles allows one to end up with an elegant solution, regardless of whatever errata is present in a language. A good framework is the elucidation of an idea with the edge cases covered so that you don't have to reinvent the wheel. It should give you the tools you need to integrate with your code and then get out of the way.

Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development.

Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something.

What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm.

Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it.

This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.

Funny, I've done my best work in PHP. But, I have a semester of Scheme under my belt and have been doing object-oriented programming (or more precisely, moving away from it) for decades.

I really, really wish there was a rapid application development language like PHP or Go written over a functional language like LISP.

I've thought about writing one, and get all the way through it in my head until I come up to the inevitable problem with monads. I believe I can make it work by treating the monads as imaginary numbers with hidden contents and never really solve the problem of mutability, but I don't know what that would look like in practice yet. The language itself would basically be Javascript without mutable variables. There would be no async/await, instead, everything would be synchronous blocking with message-oriented streams in place of messages. Like the Actor model but executing immediately as a graph so it's fully deterministic.

Facebook kind of made one called Skip, although I feel like they might have been working on another one with a "z" in its name, or maybe someone else was, can't remember:

http://skiplang.com

The same goes for Scala in my opinion. A company using Scala should restrict themselves to a easily comprehensible subset of Scala.

It's not just laziness, though that helps. It's also bunch of other idioms and features. (I've programmed in a strict variant of Haskell for a while.)

Ideally, a language like Haskell would actually be total by default; ie all computations are finite. For those computations, the compiler can freely choose evaluation strategies without affecting semantics.

For potentially infinite calculations, you'd go into a mode that's somewhat similar to how IO is segregated in existing Haskell.

(There's some more complications about things like infinite event-loops, that can be solved very similarly; and for some things you might want the user to provide proofs that they are indeed finite, instead of just overriding the compiler's judgement with an unsafe cast.)