May 2008
« Apr   Jun »




Learning to Learn.

It wasn’t until I was actually done with my undergraduate years at college, and had already gotten my self a job, that I learned the most valuable lesson of life:

The programmer that wants to advance himself cannot afford to rely on formal training and the grace of his manager to get the education he needs. Neither can he depend on pure “experience””, for experience doesn’t necessarily teach anything. If a programmer is going to make something of his experience, he must learn how to learn.
The first step in learning how to learn anything is to learn your own assets and liabilities — “know thyself.” The person who is his own teacher has one major advantage over the classroom student — he can tailor the lessons precisely to the needs of his one and only student.
— Gerald M. Weinberg in The Psychology of Computer Programming.

Douglas Engelbart (inventor of the computer mouse, which originally had 3 buttons) thought along the same lines in his On-Line System for augmenting the human intellect. His insight was to recognize that spending time developing more efficient learning habits will compound. With the more efficient habits, you can learn more things, which can be used to develop even better habits, etc. etc.

But the real issue with self-directed learning is that of objective assessment. While learning on your own is certainly the most enjoyable, rewarding, and practically useful method, it yields very little in the way of formal, standardized paperwork (grades/certifications), that employers use for estimating the skills of prospective employees. And so the effort and time spent in learning on your own is hardly ever recognized by employers. In the programming business, it’s becoming more and more widely known that screening programmers is difficult. Admittedly it’s a fledgling field rife with problems:

  • vast ever-changing sea of Technologies, Frameworks, and Languages
  • explosive range of fundamental concepts. Ex: closures, threads, hashes, sorting/searching, graph algorithms, security, etc.
  • principles of systems engineering: Windows Registry vs. Unix $HOME directories.
  • the variance of programmer skill: the really good coders can be 100 times that of the mediocre.
  • difficulties of measuring productivity. Lines of Code, Hours worked, Algorithms used, Time NOT spent putting out fires, etc.

While I can certainly say that schooling doesn’t give one an education, and have no suggestions to employers beyond “Just test your applicants” and then drawing a complete blank because of the above problems. I can at least say that learning is its own reward even if your employer doesn’t recognize that (or can’t measure it).

Leave a Reply