In this article, I'll describe the process I use to learn a new skill, attempt to configure a new feature or peripheral for my computer, or learn about some issue. (By the way, enter the title phrase, "How I Learn", into a Google search form and browse the results. I found it fascinating.)
A number of years ago, I frequently volunteered at my computer users group to give presentations for new users. I found at that time, as anyone in a teaching capacity will tell you, that I learned much more about a subject in the process of teaching it. In preparation for my presentations:
A useful, concise, and entertaining look at the process of giving a presentation is available in the online article Conference Presentation Judo by Mark Jason Dominus. He compares the often-recommended "tell them what you are going to tell them..." structure with a really successful plan for presentations.
Another resource, especially for academic learning, is the book Study Smarts: How to Learn More in Less Time. I used a similar book when I returned to school awhile ago. It covers assembling an outline, taking notes, budgeting time, getting help, how to skim material, etc.
Steve Litt's Troubleshooters.Com has a Web site on learning and troubleshooting. (The site provides lots of information for the technologist.) I purchased two of his self-published books, Rapid Learning, and Troubleshooting Techniques. Both proved invaluable in changing and focusing my approach on learning new technical material and troubleshooting problems.
A number of years ago, I helped a friend install a solar panel system on a garage roof for pre-heating the water of a in-ground swimming pool. In discussing how we approach learning a new skill, I mentioned having the right tools makes a big difference. He countered that the right book made an even bigger impact on his learning. Internet research could qualify in the book/reference category but you need to be wary of author credentials. (See the step-by-step Evaluating Information on the Web tutorial.) Find several sources of information and compare. A consensus on best practice should appear along with a list of expected problem spots.
In thinking about the conversation with my friend years later, I found I would add "available mentor" to that short list of items needed for learning a new skill:
The mentor could be a knowledgeable friend or tech support person available by phone or face-to-face consultation. It could be a class, workshop, or presentation. It is often very useful to see someone that is comfortable with a skill performing the task, rather than simply listening or reading their description of the process. Their description might miss some detail and/or their execution of the task might prompt you to ask a question that would better clarify it for you.
I read a business book awhile back about W. Edwards Deming's approach to quality in manufacturing process. Being a visual person, rather than verbal, I found the Shewhart/Deming Cycle for continuous improvement something I could incorporate into my approach. Here are the details:
Following this outline in working on a problem, or attempting a new skill, I would:
Prepare by defining the problem or goal, and then read the documentation I had assembled, and sketch out a possible plan of action or test case. I keep constantly revised notes during preparation and research in a computer text file as I grab relevant excerpts, and reorganize information. [Plan]
Keep notes as I go in a binder, or spiral notepad for a dated/sequential activity log as I work on tasks. (For computer configuration and software installations, I keep a log in one of those black and white copy books that are easy to recognize and locate.) [Check]
Execute the test case in my plan of action and note the results. [Do]
Review the log and notes if a problem occurs to see what I've tried and adjust my course of action in another test case. [Act]
When troubleshooting my computer, or setting up a DVD/VCR, etc. I work in a step-by-step procedure, logging as I go. I also remember reading about a programming method that built on small successes as it worked its way to the full program specification. After each successful test, the code was saved to the source repository. This allows rolling back to a previous successful state as well as focusing on the only thing that changed since the last success. If you change too many things, troubleshooting can be quite frustrating.
This is great advice from Tweak Home PC (a Web site for Windows 95/98/ME users)
Should you be unsure of your ability to correctly, and safely, implement any alteration, then you SHOULD NOT make that change. Get the assistance of a user who is both experienced and competent. Please remember that you alone are responsible for the consequences of any changes you make to your computer hardware or software.
A similar approach can be taken in any project. In carpentry and woodworking there is a saying "Measure twice, cut once." Everyone has a handy quote on work: "Haste makes waste"; "The hurrier I go, the behinder I get." It's also a good idea to have your own "lessons learned" session after a project. Have fun!