[ethanwillis]

I can agree with the spirit of #1 but also I think it has a subtle bad implication. You do want your juniors to talk to you and you should want to talk to them. You should also want to push them out of their comfort zone (slightly at least) so they can grow.

For #2, I don't think it's fair to say complexity is always equivalent to "experimental." We're getting close to conflating code that takes skill to write with code that has no benefits or will be buggy/experimental. The OP doesn't really deny that his engineers can write this code without failing at it or that it wouldn't improve the product in a measurable way. The post in regards to complexity is really more about the spirit of your first point in which he thinks some subset of his team can't easily deal with this type of code.

I would say that "complex" code that provides a measurable benefit and that some of your team can "wrangle" isn't necessarily a bad thing. If you want your product to be differentiated and better versus your competitor's product you're going to have to do this. If we all program (100% of the time) solely to lowest common denominator on a team(and I don't mean this disparagingly) then the company's product can only be as good as its "worst" engineer.

Otherwise, we can all get off of this site and build the same todo app from the same step by step tutorial :)