Wax In Wax Out Method
We are in the beginning of another year and it’s time to plan the new year ahead. I think it’s a very good time to share the methodology that I use when I decide to learn any new technology or computer language by myself. It’s very simple and effective. I cannot guarantee that it will be quick or effortless, but it’s very helpful to guide your study, planning and to follow your progress.
First of all, I choose a book or any other guide for the desired subject and follow all examples and exercises. Without exceptions. It’s very important to follow the “no exceptions” golden rule. It’s good to measure your progress and help you define goals and sprints to follow the plan.
Then, I applied the “Five Rules” method and it will define my behavior for the rest of my trip. Lets go to the rules:
Rule #1: “Wax on wax off”
Write. Do not copy. Never copy. Never.
Do you remember Karate Kid movie from 1984? The story is very similar of 2010’s version. Cobra Kai academy pupils spank Daniel san. Mr. Myagi try to talk to Cobra Kai master in defense of Daniel. Willing to bring peace to Daniel, Mr. Myagi challenge Cobra Kai for a Karate tournament. If Daniel san win, nobody should mess up with him any more. Otherwise his live will become a hell. As Daniel does not know Karate and Mr. Myagi decides train him.
During the training sessions, master Myagi order Daniel execute several strange tasks for a formal training in Karate, like paint the fence or wax a bunch of cars. Check out the very classical scene where Daniel argue with his master why he needs to do such task:
My point is, what ever you need to replicate, transcript. Do not just copy & past. Transcription the example or exercise looks like you are just painting the fence for free, but you are becoming familiar with new tool and technology. If you just copy & paste you will loose the opportunity to feel some syntax details. Why that comma is there? Open close parenthesis, namespaces correctly placed etc. are such thing is not easily learned when you copy & paste the code. Remember: “wax on wax off”. Transcript, not copy & paste.
Rule #2: Always Use “The Three Steps”
Never move to another example or exercise without execute it without error. Even you spend some hours or days!
I usually tell follow story to my students:
When I was studying for the college acceptance exams, several times I spent hours to solve two or three very difficult mathematic problems. It didn’t make sense for some people, because they think it was a kind of wast of time. However, during those time solving the problem, I dove very deep in the problem trying many ways to solve it. I learnt a lot. By the way, I still remember some solutions, even after 20 years!
In case you are trying some example, do not copy, write it (Rule #1). After you transcript it, you may do some typos that you need to correct. It’s a great opportunity to learn troubleshooting and debugging tools.
I always feel the temptation to just copy the code from the web and go to the next exercise. When it happens, remember that you are not solving some production issue. You are learning and it takes time.
Besides that, nothing better than the taste of victory after solve something by yourself.
What about the “Three Steps”?. It’s the problem solving method from my high school teacher:
Follow those steps when you face a very difficult problem:
- Step 1: Cry.
- Step 2: Dry your tears.
- Step 3: Solve the problem.
Rule #3: RTFM (Read the F****** Manual)
Open the API/documentation for each new class/command/control/etc. Understand in detail why the author use it in that example or solution.
You could say that it’s obvious, but it’s not. We tend to accept the solution presented without think too much about that. Check and try new possibilities beyond the author’s solution.
Avoid at any cost the “Stack Overflow Oriented Program”. I didn’t follow that rule when I was learning Objective-C and Cocoa Framework for iPhone programming. I just copy solutions from Stack Overflow and solve the problem. It worked well to solve the issue, but my knowledge remain superficial.
Rule #4: Do Not Rush Your Learning
Try other possibilities not showed by the author.
When I apply the Rule #3, often I see another way to solve the problem beyond the one presented by author. The best thing you could do for your knowledge is implement and test it.
Again, you are not solving a high priority issue in production, but learning. Enjoy the learning process.
Rule #5: “If you didn’t see, it’s not happened”
Use debugger as much as you can. Only consider the problem finished if you executed all steps through debug tool.
My very first answer to my students during ABAP classes was “did you debugged?”. Not because I don’t want to help, but I want to foster them so use the debugging tools. It worked. After some time during the class, they only ask my help after several tentative trying to solve by themselves using debug.
During the training class (or self-studying) is the perfect time to learn how to use debug tool, not “on the fly”, in a real situation in front of customer or manager.
When it happens, you train you brain to get used with “on the fly” learning and the fake feeling that you capable to learn what you need only when need it. There is no incentive to you looking for more deep knowledge. Because that it’s very rare ABAP programmers that have knowledge in debugger tool beyond “/h” and “F’s commands”.
I’m sure you will feel so good after finish some technical book using my methodology, you will think it’s worth to put it as graduation item at LinkedIn! You will feel that you just accomplish a very difficult mission. It looks hard, but we all know the famous quote “no pain, no gain”.
This text was originally publish my (Portuguese) blog, ABAP101.com. If you are in the begging of your ABAP learning, you could try that methodology in our e-book (in English), ABAP 101 Exercises – Beginner – Starting from scratch. Probably it won’t transform you in a senior ABAP developer, but at least in a junior above the average.