[einhverfr]

I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time.

When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive.

Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves.

In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well.

This being said, I have a few very minor disagreements with you ;-). These may be split hairs though.

First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft.

What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less.

Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess.

But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.

[agentultra]

> When you are 20 you are pretty much at the height of your mathematical abilities.

Is that really true?

There are many examples of people who came to mathematics late in life and did good things:

http://mathoverflow.net/questions/3591/mathematicians-who-we...

I think you only get better with time if you keep yourself sharp. What has changed for me is that I can't sit still and pound back Redbulls for six-hour coding sessions and then hit the gym. My process is also more methodical.

But mathematics is certainly one area I've only improved in with time.

[einhverfr]

And also see this: http://www.massey.ac.nz/~rmclachl/overthehill.html

However, I wonder if there is something else going on here. What I noticed in the list (and in the article I am linking to) is that the early peak seems less obvious from a historiography perspective than it does from a contemporary perspective. So I can't help but wonder if there is a qualitative difference in the sorts of contributions that younger and older mathematicians make.

Thinking more in terms of fluid vs crystalized intelligence here, but wondering if there is something else. I know my fluid intelligence is not where it was ten years ago, but part of that is a greater understanding of the problem domain. I can see more possibilities, and I see different ones than I would have before.

So I don't think it is as simple as we might want to think but I do think that thinking patterns (and abilities) change qualitatively as we age in ways which are favorable for important contributions when viewed through the light of history. Whether a thesis review board would agree is a different matter.

[gajomi]

>Is that really true?

It's almost certainly not true, at least among those that would be called mathematicians. This follows if for no other reason than the fact that it takes years to get up to speed with the forefront of any particular branch of mathematics, which is the prerequisite for testing out one's mathematical abilities (in the context of research). While you occasionally have a few teenage prodigies, most mathematicians won't get started on their career until much later.

[shubb]

I can see how it would be true of normal programmers though -

Computer science courses usually teach something very different from every day programming. You learn linear algebra, AI, dynamic programming.

Then you go to work and spend 10 years mostly not doing those things. They are generic, and there are libraries for generic things - you just need to understand how they behave.

A decade later, most people will only retain the specific techniques they use in their domain. Maybe you know more than you ever did about indexing algorithms, but the math behind the deep learning algorithm you wrote at college is gone.

[tel]

I feel like a big force that changes programming style is the gradual transition from guess-and-check to gradual bricolage, exploration, creation. I feel in my perspective like that explains at least a bit of the difference between "young" and "old" programmers here.

Guess and check programming tends to optimize around fast reset cycles so that many, many solutions can each be tried with little investment. This is the programmer who loves to refresh their window every second to see how their changes impacted the product. It's high energy and exciting. It also lends itself to prepackaged solutions—be they existing frameworks of specific transliterations of known algorithms. I also find that it tends to generate spaghetti code more quickly (all styles do, but GnC does so more quickly) and to fall flat on tasks which have either slow reset cycles, long dependency chains, or are difficult to visualize.

"Slow" programming, for the lack of a better word, orients itself around a deep understanding of both the domain and the natural "seams" in the problem space. It involves a lot of quick drafts that are perhaps never even observed—the mere act of trying and failing to express the problem elegantly is highly informative. It tends to find less "obviously optimal" solutions because it's in search of novel optimal solutions. It also tends to be more easily guided by high-level goals such as business value or elegance. Finally, programming slowly requires great reasoning skills and thus is more amenable to tools and processes which enhance reasoning. It can take stabs at deep, difficult domains because it happily uses great domain modeling or mathematical skills to break those challenging domains into clever, interlocking, and simple pieces. For all this though it suffers from having a design aesthetic and becomes less willing to "just dive in there and try all 500 solutions" in case one of them works.

I think this cuts broadly across several stylistic differences in coders. I think that age and experience pushes one toward the latter style. I also think that they both have strengths and weaknesses—so I strongly agree that mixed style teams are valuable.