Training - it can be a dirty word to some; learning by doing is all very well but what do you actually learn?

On my daily commute to work, I have 90 minutes on the train to read, digest, and think about how to implement these new practices into my programming. I don't know how much audio training exists for Java, but if you can listen to tapes in the car, you have, in effect, a mobile library of information (I learned this from Brian Tracey, a sales mentor; getting into the brain of a salesman is really interesting, and it also means you can play their game a bit when they suggest new features for your software). Preparation is also key, and reading on the train or listening to tapes will help. I know a lot of you spend many out-of-work hours brushing up on Java, design patterns, and everything else the industry sends our way.

I've learned more from books than from blogs, as the latter tend to be based more on opinions than anything else. Blogs are great for catching up on what's going on with recently released software and libraries. If you want to seriously start learning though, you'll have to dig deep and be prepared to sacrifice some time. Let me tell you a short story by first asking a question.

How well do you know your compiler? It sounds like a silly question, doesn't it? But I think only about 40% of Java developers know of the Javac compiler options. To be honest, we try to get away with using only what we have to and don't bother with the rest. If you are using an IDE, you may never really know what is going on under the bonnet.

What got me into all this? Bruce Eckel, yes, it's all his fault! Traveling on the train, I started reading odds and ends from Thinking in Java (3rd edition) and stumbled on memory profiling. I don't have a huge interest in the subject, though I have to admit that I'm currently using Rational Purify Plus for a future review in JDJ so I didn't even consider that the SDK would have one. My eyes lit up when I saw:

java -Xrunhprof:heap=sites,cpu=samples,depth=10,
monitor=y,thread=y,doe=y ClassToProfile

It's worth noting that the X options are nonstandard and liable to change, but still worth investigating. I had a quick look at Jikes as well, and build 1.17 didn't have it. Running -Xrunhprof is an adventure in itself (searching Google will produce some more meaningful information, as will the Sun site). The memory profiler produces a text file with a lot of information about thread usage and which objects are hogging all the allocated memory. The only downside is that in the commuter trains everyone within a meter radius is reading the finer art of object inheritance and memory profiling.

Another aspect of learning is tutoring or one-to-one help. We've all had times when we thought we knew something, then we met someone who basically blows our ideas out of the water. It happened to me not so long ago; in fact the person in question has written a couple of times for JDJ. He got me into some basic design patterns, especially the use of the Factory pattern and using abstract classes as interfaces; this actually changed the way I program. What was in error was my logic and thought process. It's worth taking the time to talk, read, and, most important, listen to your peers. Your way of doing something may be correct, but I can guarantee that there are three other ways to do what you're doing. Try them all and learn from them, good points and bad.

Right, I'm off to find a new book to take on the train with me. Something on design patterns to get Alan fired up.