hal helm's logo  
home Home

training Training

writing Writings

code Code

tutorials Tutorials

newsletters Newsletters

consulting Consulting

Hal Helms logo
hal.helms

What Students Say...

"Excellent, excellent class! You rock. And thank you for the long lunch break. I thought you were crazy at first, but having that break let me really digest what you were teaching." - Paul R.

"My boss has sent every one of us through your FastTrack to Fusebox class and says it's the best investment in training he ever made. (And I agree!) Thanks, Hal. Really a great class. Great CDs, too." - Jennifer M

"As a trainer myself, I thought you did a fantastic job making sure that the advanced students got what they needed without leaving the more junior ones adrift. Well done!" - Martin B

newsletters section

At the bottom of this newsletter is some training news, but first...

To Train or Not To Train?

In Hamlet's famous "To Be or Not To Be" soliloquy, the Prince of Denmark ponders if the burden of existence may be too great. Odd as it may seem, I've been pondering something of the same question in regards to training. I say it's odd because I do a lot of training. Clearly, then, training is a Good Thing™. But is it? Or, at least, is it always? Hmmm...

The issue was really brought home to me on reading Meilir Page-Jones wonderful book, Fundamentals of Object Oriented Design in UML (http://www.amazon.com/exec/obidos/ASIN/020169946X/teamallaire) The first hundred pages or so are a breeze; Page-Jones writes wonderfully with great clarity and enough humor that I found myself laughing aloud. But you know what they say: it's all fun and games until somebody gets hurt. The next 350 pages gets considerably harder as the author discusses issues of cohesion, coupling, conasence and contranasence and I found my pace going through the book got slower and slower and slower...

Unlike some authors, who I'm convinced invent terms simply to make simple concepts hard and thereby sell books to explain those terms, Page-Jones is a wonderful educator and gifted writer. And many of the terms and concepts he employs are, when investigated, not foreign to the kind of common sense that we all try to use when designing and writing applications.

What I found interesting was that by naming and categorizing that "common sense", a barrier was introduced. I had to map his terms and concepts to the things that were somewhat unformed and nameless and yet existed in my vague sense of "best practices". It was, in short, work.


Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

Like many people, I've found that a combination of laziness and creativity to be the perfect attributes for programmers, so why would I willingly undertake work? Well, I find the book worth the work because formalizing those somewhat fuzzy concepts allows me to apply my new understanding to future situations. I then have a way of heading my fuzzy thinking off at the pass by asking myself questions like, "Does this model I'm creating apply proper levels of abstraction?" Without a thorough understanding, that question is just an exercise in buzzwords; by taking the time to deeply understand the subject matter, it becomes a tool I can use to do better work.

So, I'm willing to endure some present pain for anticipated gain. The pain is not just the time spent reading the book (as opposed to playing) but the work involved in learning new concepts and new terms. It involves a sense of uncertainty and mental confusion while this mapping takes place. Unfortunately, there's very little I can do to make the connections happen, which is part of the uncertainty I mentioned. I hope that the murkiness will crystallize into new insights. But the pain is definitely there.

Pick up a book on a complex subject and thumb through it. It can often be daunting: you have to learn a new vocabulary, learn new concepts, learn how those concepts can be applied, and learn how to integrate those new concepts into the ones you're already trying to master. And yet for many things, you can get by without learning the new stuff. If I need to write an initialization file, I can struggle to learn XML and XPath-or I can just put things into a structure. If I want to write a module, I can labor to understand CFCs-or I can just use a custom tag.

Which brings me (in a round-about fashion) to training. In learning something new, we volunteer to go through a process of pain in the hopes that if/when we emerge from the process, the fuzzy things will become clear and that we will become better at what we do. Instructor-led training is one of the least painful ways, probably only bettered by one-on-one mentoring. But is such training always a good thing?

Surprisingly, to me at least, I find myself answering, "No". The benefits of learning a formalized system must be weighed against the costs. Training involves costs in terms of real dollars spent (course costs, travel, lost productivity).

There's no right answer to this, although in our industry the presumption seems to be that anything older than 6 months is positively ancient. There are just too many new technologies to learn them all. Some triage needs to occur; we need to say "yes" to some technologies and "no" to others. The decision about learning x (where x = something new) needs to be thought through by asking questions like:

  • If I learn x, will I use it very often in my daily work?
  • If I do use x in my daily work, will it provide any benefit to us (us being defined as developer, employer, and customer)?
  • Will learning x make me more valuable in the marketplace?
  • What are the ramifications of not learning x? Can I live with those?
  • Will others be able to leverage what I've learned so that many can benefit?

I'm sure there are many others, but it just struck me that the answer to the question, "To train or not to train" involves more than a canned answer.


And speaking of training (!), there are still some seats left in the Java for ColdFusion Programmers class in Las Vegas. If you want a (relatively) painless way of learning what can be a very intimidating subject, and you can convince your boss to send you, then meet me in Sin City. Details at http://halhelms.com/index.cfm?fuseaction=training.javaDetails. And if you buy me a beer, I just might tell you with the story of how I almost became a professional gambler...


"What about Fusebox training?" Several people have asked me that and I'm putting together a 3-day Fusebox training session January 13-15 in Atlanta. Take Fusebox, by far the most popular framework for building ColdFusion applications. Then apply the Fusebox Lifecycle Process, which helps ensure not only that we'll get good code but a good project - and you've got the FastTrack to Fusebox course. Details at http://halhelms.com/index.cfm?fuseaction=training.ftfbdetails.

©copyright      designed by in-tuition.co.uk
hal helms' personal site Updates

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

teamallaire.com v 4_3