It's been a good week, thus far. I attended a really cool Wing Chun class yesterday evening and I managed to solve several design and interaction challenges for a series of courses that we're migrating from Moodle to Canvas. As WOLWeek is in full swing, I got myself to thinking about how I learn to do certain things. And for most things, but perhaps especially technical skills, I like to apply a blunt force learning approach. What does blunt force learning look like? It's built on a solid foundation of aversion to asking others for help until I'm at the end of my rope (whether or not that's a good thing is another question). So when I have a problem—for example, a JavaScript problem, like I did this week—I attack the problem from as many different angles as I can. A former co-worker of mine called this "working the problem."
Step 1: Articulate the Problem
You ever come up against a design problem or a technical issue but, even though, you've been trying to tackle it for a while, you find that you still can't really pinpoint what the problem is? I've been in that situations many times. That's why step 1 is indispensable. Before you do anything, certainly before you ask anyone for help, you need to be able to think clearly about the problem you're experiencing. You need to be able to articulate it. I'll admit that sometimes, I jump to step 2, only to be redirected back here when I figure out that I can't even think about the problem. One method that helps me a lot is talking through the issue and options out loud. (If you walk by my office on any given day, you'll probably see me talking to myself, pacing, and throwing and catching a ball). This method is also known as rubber duck debugging and, though the story is centered on software engineers, the method can be useful for problem solvers of all ilks.
Step 2: Google It, as many times as it takes
If I don't have any prior knowledge, I Google it. However, I've noticed that this is not a quick solution (so don't expect it to be one). Many times, the problem with searching for a technical issue is that you need to use a specific vocabulary. I always operate under the assumption that someone, somewhere has had the same question, but I need to know how to talk about it. So that takes time of patiently exploring the links I receive back and refining my vocabulary, refining my understanding of the problem.
Step 3: Iterate
Another thing that I've always found very important is to be able to try out any solutions I think might work. Iteration is key. Everytime, I think I have something that works, I try it out, see what happens and learn from it.
Step 100: Ask, but only if you have to
Now this is my personal approach. I save asking until I just can't think of another thing to try. I think the reasons for this are many. Firstly, I hate to be the person that interrupts someone else's work to answer my question. Secondly, while a community like the Storyline community is super welcoming and supportive of any and all questions, the coding community can be... not that way. If you ask a question on Stack Overflow and the eyeballs that be don't feel that you tried on your own, you will be downvoted and attacked. Thirdly, there's a lot of merit in the rubber duck approach I mentioned earlier. Sometimes, you're all it takes to solve your problem.
Step 101: Document Your Solutions
Documenting your solution is also really important, especially if you had to ask someone. Don't be afraid to make you're own job aids. I've made or found cheat sheets for any number of things. When I'm exploring a new system or software, I tend to try and create a sandbox or a document where I lay out the things I encountered and their solutions. If it's a series of steps, like in a program, I might record a quick screen capture. Do everything you can so that you don't have to ask the same question twice. Documentation also has the added advantage of turning into things that you can share with others on your team, helping you to help others quickly and easily. This is the essence of working out loud.
Final Thoughts
As an ID, I think sometimes, our job is as much to help others (our colleagues and our clients) develop a personal methodology for learning when they need to figure something out as it is to provide them with learning resources. How do you work out loud?