Hmm - dangerous line of thought, friend. One of the things I've learned through the years is, that people learn very differently, as they are creative in different ways. Some love to spill ideas back and forth, others stare blankly into a white wall for a few hours.
I prefer to learn like you do, some books, the net within reach, some good music on the stereo and Warp 9: Engage...
But.
Some people need to have the same stuff explained verbally. Or demonstrated through code. Or.. Or...
To put people on the To-Be-Fired (Preferrebly-Throgh-A-Cannon) list just because they learn in other ways would put you on my endagered specied around list - I prefer a broad range of personalities and qualities in the group. The "My way or the Highway" attitude won't go very far, I believe.
Instead of trying to judge their learning abilities through the lenses of your own preferences, I try to find out how each individual wants to learn new stuff, and then take it from there.
It is (very) true, that some learn faster that others, yes. But before lighting up the fire with those people, perhaps it would be a good idea to check, if they have interests or talents you never thought of.
Who knows, they might even love to write documentation, and you might be the one who discovered the Mozart of the Manuals from the pool of hopeless newbies.
I'm a developer who spend a good part of my time training, both pure technical stuff and more soft stuff like project management and team coaching.
Whenever I'm to go to a new organisation for technical purposes, I always ask for all the internal documentation on standards, code guide lines, code scheletons and so forth. If I'm to train people from the organisation I also ask for one day with one of the lead architects so I can learn how the ropes are, do and don'ts, homegrown tools and tricks.
If I can get that, I can give so much more to the people I'm supposed to train. If I don't know anything about how things are (supposed to be) done, I have to give the "standard song and dance". Which is not nescessarily bad, but if I'm teaching EJB (I'm primarily a Java Buff) and teaching "You should always use getter and setter methods, or I shall kill you in your beds", it's a bit unfortunate, when it turns out that the internal guide line is always to use Session Beans which returns complete Data Objects --- and never use getter and setter. (That's one from the real world, btw).
So I would suggest, that the person who shall perform the training should spend time getting familiar with the organisation the people works in.
This assumes, of course, that all people attending a course come from the same company, which may not always be the case. It is mostly for me, though.
The surpricing part is, that even though I explain that if I get 1 day with the lead architects or programmers, I can give a much better course, I'm often turned down. "He/She can't spare the time" or "that's to expensive, we won't pay for that extra day. Just go with the standard materiale, we will explain the differences when they get back."
I belive, that if we can get a process, where the people who are to train others are first themselves trained in ways of the organisation they are to train in, the result would be of a much higher quality.
Slashdot Mirror
Hmm - dangerous line of thought, friend. One of the things I've learned through the years is, that people learn very differently, as they are creative in different ways. Some love to spill ideas back and forth, others stare blankly into a white wall for a few hours.
...
I prefer to learn like you do, some books, the net within reach, some good music on the stereo and Warp 9: Engage
But.
Some people need to have the same stuff explained verbally. Or demonstrated through code. Or.. Or...
To put people on the To-Be-Fired (Preferrebly-Throgh-A-Cannon) list just because they learn in other ways would put you on my endagered specied around list - I prefer a broad range of personalities and qualities in the group. The "My way or the Highway" attitude won't go very far, I believe.
Instead of trying to judge their learning abilities through the lenses of your own preferences, I try to find out how each individual wants to learn new stuff, and then take it from there.
It is (very) true, that some learn faster that others, yes. But before lighting up the fire with those people, perhaps it would be a good idea to check, if they have interests or talents you never thought of.
Who knows, they might even love to write documentation, and you might be the one who discovered the Mozart of the Manuals from the pool of hopeless newbies.
I'm a developer who spend a good part of my time training, both pure technical stuff and more soft stuff like project management and team coaching.
....
/Sverre
Whenever I'm to go to a new organisation for technical purposes, I always ask for all the internal documentation on standards, code guide lines, code scheletons and so forth. If I'm to train people from the organisation I also ask for one day with one of the lead architects so I can learn how the ropes are, do and don'ts, homegrown tools and tricks.
If I can get that, I can give so much more to the people I'm supposed to train. If I don't know anything about how things are (supposed to be) done, I have to give the "standard song and dance". Which is not nescessarily bad, but if I'm teaching EJB (I'm primarily a Java Buff) and teaching "You should always use getter and setter methods, or I shall kill you in your beds", it's a bit unfortunate, when it turns out that the internal guide line is always to use Session Beans which returns complete Data Objects --- and never use getter and setter. (That's one from the real world, btw).
So I would suggest, that the person who shall perform the training should spend time getting familiar with the organisation the people works in.
This assumes, of course, that all people attending a course come from the same company, which may not always be the case. It is mostly for me, though.
The surpricing part is, that even though I explain that if I get 1 day with the lead architects or programmers, I can give a much better course, I'm often turned down. "He/She can't spare the time" or "that's to expensive, we won't pay for that extra day. Just go with the standard materiale, we will explain the differences when they get back."
I belive, that if we can get a process, where the people who are to train others are first themselves trained in ways of the organisation they are to train in, the result would be of a much higher quality.
And then the dime ran out
Best Regards,