So – I could summarize your argument as follows:
– Advanced techniques take time to learn
– They are harder to understand for those who haven’t mastered the topic yet
– Nonetheless, they save time and overall make the code better
– Thus, complex code is worth it, even if it has a “learning curve” or looks “nasty” to the uninformed.

If you agree with my summary, are you ready to reconsider your opinion regarding regular expressions? Because I know you have decided to avoid regexes.

Your same logic applies to regular expressions, i.e. they have a learning curve and look nasty, yet they to save time and are easier to maintain, at least for those who are not ‘junior regular expression programmers’!

I started developing after years of being in system support, and I was never referred to as a junior.

I guess to summarize you have “Developers” and “Senior Developers” within a company, the difference being “Senior Developers”, apart from having more development experience, are senior only through promotion/company experience/procedures etc?

Further, even though I have developed for 5 years, I can always feel happy enough to ask a developer of 3 months for advice etc. In todays development/programming world, with huge resources/info through the internet etc, we cannot all be expected to know everything, there’s just not the time for this. So if I think it’s worth asking, whatever their experiences, I most certainly will.

Designing code right the first time means applying design patterns, where appropriate and following best practices. Doing so will lead to fewer lines of code, fewer bugs and code that is generally easier to maintain. Less code means less for the junior developer to have to jump into and learn. Less ramp-up time means that you can get them in there sooner being productive members of your team.

Breaking old habits is difficult. Start them off early.

Senior dev/ architect/ teamleader is promoted due to longevity of tenure.

This person likes playing with new stuff, is an uber-techo, dislikes spending time on other people who slow him down. May also like to hoard their skills and superiority, rather than share them.

Consequently takes as little part in coaching, mentoring, explaining as he can get away with, and complains lots about how much of his precious time is being eaten up by these thicko’s. Delivers no presentations or courses on technology approaches to the team.

Stays in his office coding up a storm of un-maintainable, out-of-control brilliance.

Forms a network around himself of cognoscenti who ‘get it.’ Everyone else complains that they don’t get the support that they need, and continue writing not-very-good code…

Conclusion? This team is broken. This organisation has a problem. and techos who don’t like people so much, don’t believe in teamwork, don’t understand that the more you coach, the happier and more productive everyone becomes, should never be put in any sort of leadership position. Including technical leadership!

I’ll take 2, every-single-time.

Lambdas are not a cure all, but when half of the methods in the generic list call for them, I see that as a reason to know how to use them.

Wow, what a VERY POOR practice. You just give your jr developers the concept in less than an hour and they are off throwing lambda expressions around? So you feel comfortable with a jr developer throwing delegate based expression around, which is what lambda expressions are?

I agree with the concept of having smaller teams of higher paid professionals over a larger team of varying skills. This way there is no one left behind.

kenroy