Thanks MIT_Hacker for the article.<p>I'd like to extend your ideas a little and make the point that:<p>1) When you combine the two extremes of programmers you can get more than just harmony, you can gain synergy, and<p>2) As "new-found learner" I believe that the idea of 'good programming' can be abstracted to be 'good creative problem solving and communication.'<p>About the first point:<p>As I said I fall in the "new-found learner" category, for my start-up I've been fortunate enough to have a 'veteran' developer on my team who is astounding. Every time I watch him code or he explains the architecture I learn something new and useful. Best of all, we have a high synchronization ratio.<p>However even though he's been working for nearly 10 years as a developer for some of the best financial institutions in the world it's clear that he doesn't have the entrepreneurial thought patterns necessary to gestate and birth a start-up. The other day we were talking about this very thing and he's said that he's tried, and with others just like him, to dream up the next big "Facebook" opportunity, yet inspiration keeps eluding him. He told me a 'cautionary tale' about a colleague who quit his job to start-up a Golf Scorecard mobile app which got funding and then later tanked. From what he said to me it seemed that this newbie entrepreneur had no intimate knowledge of the the customer's needs, too much customer inertia and not enough market pull. I would be so bold as to say it over engineered the problem. These issues seemed obvious to me, but only through the lens of my own entrepreneurial experience... gained the hard way.<p>The point is that the "new-found learner" probably comes from a place where their life experiences add a 'je ne sais quoi' to the mix when combined with the technical experience of your "5th grade coders". This makes for synergy.<p>About the second point:<p>I'm absolutely certain that the time I spent as a finance and economics consultant has been applicable to my approach to programming. Why? Well I was lucky enough to be taught how to logically 'think' my way to an optimal client solution and how to communicate the solution in the clearest possible way. I would roughly call it the "McKinsey's Approach To Problem-Solving." When I say that I mean approaches like 'understanding the question', 'hypothesis driven solutions', 'issue trees', 'mutually exclusive and collectively exhaustive (MECE)', and the '80/20 solution search.' Looking back I'm certain that what set the consultancy I worked for and the others was the ability to communicate the solutions. Often economic or financial questions have complex answers. Even if the answer is simple it is often put forward in a complex way. By taking complex ideas and putting them forward in an simple way, and keeping simple ideas simple, the consultancy was extremely effective and profitable. The secret to this effective communication was our Plain English approach to writing. The CEO of the consultancy was fanatical about it, even to the point of reviewing as many client reports before they were delivered.<p>I find that by adapting these problem solving 'thinking patterns' to my programming, while keeping in mind that I need to communicate clearly I'm at least productive enough to keep up with the "5th grade coder" in my team.