MOTS is over and tomorrow morning I’m flying back home to OOW.
This was my first conference where I presented as a Pythian employee. Its been a good experience. People would ask me who I work for, and when I answer “Pythian”, their eyes would light up, and they’d say something like “Wow! So, what’s it really like working for them?”. I never got this reaction when I worked for HP.
I just spent two days telling people how awesome it is to work for Pythian. Some time was also spent talking about Networks and NoSQL, but not nearly as much.
My favorite part of the job is that I learn a lot. Starting from the big topics – RMAN, ASM, DataGuard (remember when I was complaining about not knowing those basic technologies?), but also little things – how to find specific information I need from Oracle, solve specific problems, work around specific error messages.
The reason that I don’t blog about all the wonderful things I learn all the time, is that most of the time I assume that everyone else knew it all along. Occasionally I tweet my new findings, and the replies show that I may be over-estimating common knowledge.
The problem with learning at the rate of one new technique per hour over six month is that very little of the knowledge sticks. At the end of a long day, I don’t really remember what didn’t work at first, what I learned solving it and why is it interesting.
Being at Pythian, all the commands I used are recorded – and at first it seemed to be adequate. But its not enough: First, solution to a single problem can be spread over 5-6 separate updates. Which make it hard to distill the important insights. Second, even if I can later go on and find what I did back then, it feels a lot like copying a script off the network – there is no integration of the knowledge into my existing understanding and work habits.
I’ve been interested in the topic of how to improve learning for a while now. But I find that my focus has changed – I used to worry about the process of learning things that you do not routinely encounter on your job. Learning topics that you don’t normally encounter on the job is difficult – because deep learning always involves problem solving, and following Oracle manuals on test systems rarely create interesting problems to solve. Without troubleshooting and debugging, there is no real understanding of the system. Being able to figure out what the system is doing when it does something unexpected is the true test of learning.
But it turns out that learning things that you do a lot is not that simple either. I think part of the problem is the pace of my work. When I solve a problem, I immediately book my time and jump on the next problem to solve.
If the problem involves a long running process such as an export, install script or index building, I’m likely to keep jumping back and forth between two or more problems – fix an issue, start the long process, move to another issue and check back later to try another solution if needed. Not to mention task switches caused by emergency paging. This is very efficient use of time, but it means that I’m not taking time to reflect – what did I try, what didn’t work, what did and why. Ideally get some reusable scripts or bloggable insights from the experience. Maybe going somewhat slower will be more efficient in the long term, reducing the time spent looking for a solution for an issue I know I saw before.
During MOTS I attended an excellent presentation by Alex Gorbachev on the Battle Against Any Guess. I was thinking that if you are guessing, you are not learning. The only thing you can learn by guessing is to memorize the guess that worked. Which means you’ll not understand the problem and the solution and you’ll need a lot more memorization in the future. On the other hand, full understanding of problems is not always 100% possible, due to lack of documentation or time constraints. Making educated guesses, testing them and reflecting on the results can lead to more understanding and less memorization.
Funny enough, writing blog posts and giving presentations help a lot. Trying to explain what I just did forces me to figure out which parts are important and usually highlights anything I don’t understand completely. If writing the thing didn’t complete the learning process, I can always count on readers and audience members to help.
Interested in working with Gwen? Schedule a tech call.