Old Age and Treachery....

...beats Youth and Skill any day....

So goes an old saying that I like to repeat when one of the young guns at The Job starts ragging on us older programmers.

The key thing is that there is a great deal of accumulated knowledge that good programmers can use that just can't be taught.  There are patterns in bug behavior that you learn to recognize, weird interactions that only happen once every decade (or longer), and paradigms that cycle around with Halley's Comet to crash systems - and it's damned hard to teach such things, both in what to look for, and how to generalize them.

That's not to say that young programmers are bad - they've got energy, enthusiasm, and just as much a chance to be truly smart as us codgers.  And the lack of experience can lead to pushing an idea hard enough to make it a success (Twitter, anyone?)  But most times reinventing the wheel is just wasted effort.

So as I scan the Web for interesting things to blog about, I run across three articles about the cultural differences in two other countries (vis-a-vis the USA):  India and Japan

First, India:  This one notes that in India, there is very much a belief that programming is the lowest rung of the corporate ladder, and that one's career will advance away from programming.  This other one notes that there is also a very strong cultural pressure to rise in a company to achieve "success" within 5 years of starting formal work, in order to marry well.

Similarly, this article notes that Japan has a similar, if somewhat less severe problem, forcing its programmers into management after 13 years, although it hints that there is enough of a vein of monastic dedication that may give the truly determined programmers a chance to excel, at the cost of renumeration.

Now all this makes me look askance at outsourcing to such places - if the developers you get in India are, for the most part, novices, how are they going to learn the experiential things?  They aren't experienced enough themselves, and there are no experienced programmers in their companies to teach them, should they be aware of the need.  And if your outsourcing company is fortunate enough to be able to keep individuals on staff long-term (instead of them going elsewhere for better salaries), you still will lose them as a developer in five years!

I can't speak for anyone else, but I know that I've learned a great deal in the years since I hit 27 - I'm better at finding abstractions, much better at determining the cause of a bug, and much more likely to put logic in the data instead of the code.  I know that my code will need to be refactored, but also that I'll need tests to be sure I don't miss a detail in the rewrite.  I also know that any code that has been in production for years probably has dozens of special cases that make it hard to use the obvious abstractions, so I'd better look at it from the bottom-up as well as top-down.

---