Thursday, August 07, 2008

Learning curves: from FORTRAN and COBOL to OOP's, and then some

I know I’ve touched on this before, but I keep coming back to the question, why was making the “switch to client-server” in 2000 and 2001 difficult, with such a rocky learning curve.

I can recall the steady experience of learning FORTRAN in government (civilian Navy department) summer jobs in the 1960s, and the ease of learning COBOL procedural programming in the 1970s. When I went to work for Univac in 1972 in site support, I was originally the processor support point person for FORTRAN. I was assigned for a time at the account at Public Service Electric and Gas in downtown Newark, NJ, which at the time used a lot of FORTRAN. That’s where I started the switch to COBOL. When I went to NBC (in Rockefeller Center in New York) and worked in general ledger, I found COBOL very easy to pick up. It took longer, however, to learn the proper coding techniques and practices. At the time, the concepts of “structured programming” (GOTO-less) and “top down design” were just evolving. The accounting system that we purchased, from Infonational, had source code with lots of GOTO’s (particularly the general ledger year-to-date merge).

I didn’t get exposed to Object Oriented programming and java until 1999. I started with an off-job-campus course in suburban Minneapolis from one of the many training companies in the area. A week isn’t quite enough to immerse you in it. When I started working in the area, it was mainly in support. We also had in-house courses in UML (Unified Modeling Language). There was also an off-site week-long course in Powerbuilder, which managed the GUI layer. But the way to learn this, like learn anything, is to develop and implement a project and be responsible for it afterwards.

But we learn that teenagers seem to sop this material quickly. Modern “open system” skills, as they developed in the early 1990s, seem “non linear” when you learn them. It seems that learning them is like learning to play a musical instrument. When do people learn music skills? Usually as kids. This sort of thing is easier to master before your brain finishes its biological pruning process (making itself more efficient) at around age 25. So, just as you find early teens with phenomenal abilities in music, some of then accomplish phenomenal feats before age 20, inventing (in C++ or java code) whole new business concepts like Napster or Facebook, not always aware of the social or even legal consequences of what they will deploy (that takes more maturity and “consequence judgment”). Someone in his 50s might invent a conceptually new way to handle the news (like my “do ask do tell”) but will not be able to code a whole P2P music download application in 60 hours alone with a laptop.

Career coaches and outplacement counselors sometimes say that much younger people are very quick and getting things done, but sometimes it’s the wrong thing. Older workers may have more judgment as to the appropriateness of what is to be done. That’s an interesting balance in the job market.

One other rambling comes to mind here. That is, how quickly java became a standard production environment. Java was invented in 1991 but not implemented for public use until 1995. Yet, by 1999 the financial services company for which I worked was writing a mid-tier data access layer in java, fully confident. (I didn’t get to work on this until 2000, and then just in support – I remember the controversies over “thread death”.) By 2000, Sun had developed its certification programs fully, with textbooks hundreds of pages long, demanding that programmers master arcane skills probably not used in a lot of shops. It’s amazing that this developed so quickly.

No comments: