Friday, July 2, 2010

School Learning and Real Learning

A fresh graduate with a Master's Degree, I took an entry-level job in technical support at a software company.  I spent a little over a year in this position, answering questions about over 80 products, most of which I had only a passing familiarity with.  I always preferred getting customers "off the phone" as quickly as I could so that I could research and provide help through e-mail.

I found the position stressful and was happy to transfer into a non customer-facing position, but I gained more technical expertise in that year than any other year of my career, and probably more than my six years of collegiate education put together.

What sticks out to me now is the manner in which this learning took place.  On our first day, we were not put in a training class or lectured to, but given a project to develop.  We were given two days to complete it, and coding it required that we would learn a wide swath of our flagship program.  After a couple of token orientation classes, we were put on the phones within a few weeks.

Each support case presented an excellent opportunity for learning.  A real person had a real need that had to be met in a time-sensitive manner.  In turn, I had various resources to help the customers: a database of "solutions", other support engineers, and most importantly, the products themselves.  Occasionally, I would even have to disturb a grumpy developer.  Some cases were trivial or easily answered, but most represented a little project and challenge.  Given the motivation to learn an area in order to satisfy a customer, the right resources, and clear, attainable goals, I served many cases and learned more about 80 products than I could have imagined possible.

But even when I transferred to a new position, I was still stuck in a school frame of mind with respect to how to learn.  I had just experienced a year of incredible learning, and I should have thought more about why that was, and how it was different than school.  I wanted to learn about our internal software systems that I had not previously used, and how did I go about this?

By reading text.  I printed out the 200-page user's manual and committed myself to the mental drudgery of reading it cover to cover.  This was, after all, how I had been taught for more than ten years prior to my job: plod through mind-numbingly boring textbooks and hope to retain enough "material" for later use (in the case of schools, for tests).  There is no real justification for learning the material and no reason to think any part of it is more important or relevant than other parts.  There is no goal to strive for, and no hope for real satisfaction (perhaps other than having reached the end of the book).  I continued in the face of these obstacles because I believed learning has to be painful, and that I must be doing something useful through this work.

I am thankful that this attitude did not last the full 200 pages.  Given that there would be no real "test" like in school for whether I retained any of the material, I eventually gave up on the endeavor, frustrated but wiser.

There is certainly a place for reference and textbooks, but it is not as the primary vehicle for learning.  It is a failure in the school system that led me to think otherwise.  Textbooks, exercises, lectures, homework, and tests: whoever thinks this is the best model for real learning must think of the brain as a passive slate to be filled with endless facts at the discretion of teachers.  But when there is no real motivation or interest, and no hope for satisfaction on the part of the learner, the brain functions more like a sieve.

No comments:

Post a Comment