Are You Getting Enough Say In Your Training?

DrEducator asks: "Has your company ever contracted external instructors to train its programmers? Have you been satisfied with the lecturer's level of expertise? I think we all have a good grasp of how vital the role of training is to both a corporation and its employees, but given its importance should you have more of a say in selecting or evaluating instructors before they deliver training? I firmly believe in the tenet that 'geeks should train geeks'. Moreover, I think that the geeks themselves have to take a more active role in the whole process. So, I'm curious - do you think you have enough say in your training? Do you actively refer instructors that you've seen at conferences or previously taken courses from (university, college, or adult ed)? If not, have you had the opportunity to interview an instructor, or at least review their qualifications? Share your experience - how much input do you want/need/have?"

Comments

While "Geeks should train geeks" might seem ...

[burgburgburg]

obvious, there is a fundamental flaw within. Just because someone understands something does NOT mean they in anyway have the skills to relay that information to others. "I know it" does not mean "I can make you understand it". Teaching is a skill that comes naturally to very few people. The trainer should know the stuff down, but also needs to know how to instruct it to others.

If you alter your phrase to "geek teachers should train geeks", I'm behind it 100%.

Re:While "Geeks should train geeks" might seem ...

[CynicTheHedgehog]

I recently attented API training class offered by one of our vendors. It was a 3-day class taught jointly by a customer representative and one of the engineers. The first day ran smoothly; the representative managed to make the class personal and comfortable, and he seemed at home with the slides and printed material. He deferred most of the questions to the engineer, who clumsily spat out biased answers and misinformation. The rep had to leave on some personal errand on the second day, and the class dissolved into a programming exercise reminiscient of a 10th grade BASIC class, wherein the engineer spent all of his time hopping from desk to desk trying to get things to compile on an IDE none of us was familiar with. The agenda and printed materials went right out the window. We learned no new material that day.

The rep stayed at a pretty high level, but it was useful background and it was organized. Between him and the engineer I learned quite a bit. I a figured out a few things myself while I was fighting code on the second day, but not as much as I would have had there been some semblance of order. I much prefered the rational, methodical training offered by the rep and the printed materials to the chaotic, hands-on approach of the agitated engineer.

of course

[tanveer1979]

yes you are right. But mostly while delivering such training programs the company has a number of constraints.

• Current Market demands
• Project Goals
• Long term investment to gain ratio
• Value addition Index

So though geeks for geeks is a good idea, managers need to intervene. The right balance should be struck between employee gain and company gain.
But then deciding is not a easy job, and in my expirience employee gain is sacrifised for company gain.
One option would be to be slightly more vocal and talk it out.
The complete geek way is also not theway to go coz then company wont gain everything.

Classic business problem...

[Chagatai]

The difficulty with getting proper training is that what you want for training doesn't always equal what the company wants for training. You may know of someone from a seminar who will give the best presentation on the latest and greatest tool, but business needs dictate that you need training on a tool that is ten years old. I've run into this quite a few times, being sent for classes where I didn't care for the subject but had to go because the business needed it. Throw in a mix of PHBs and you will soon realize why you're enrolled in that OS/2 starter class.

I have pretty good control

[JoeWalsh]

Every year, I get a personal training budget. I can spend that money on whatever technical training I want, from whomever I want. Obviously, if I choose to take courses out of state, the money will go much less far due to travel expenses, so I mostly take them locally. It usually works out to about 4 weeks of training per year.

I guess you could say my company treats me like an adult - or maybe like a member of the family. It gives me the money I need to get good-quality training, then trusts me to decide what training I need, where I should take it, etc.

It's a really good situation, and one of the reasons I've been working at the same company for nearly 10 years now.

-Joe

You assume we get any training at all

[Anonymous Coward]

In the past 4 years working for Company X, I've had 4 hours of company-paid-for-it training. Those 4 hours were for training as some massive quality control initiative (1984 Motorola Technology, now known as Six Sigma).

The training consisted of the instructor reading aloud overhead transparencies.

Every other request has been denied.

So, getting some training in the first place would be wonderful.

Google Trains Me

[scott1853]

Anytime I have to learn something new related to computers, I head over to groups.google.com and look up "[fancy-new-product] sucks" and read the results. Saves many hours later on.

This smells of free commercialism...

[FortKnox]

After reading this, I have a sour taste in my mouth. I'm thinking its one of two things:

• 1.) This is to prep you all for an ad they will be running about how Dr.Educators employer has GOOD training, unlike the examples of bad training that will come up in the posts (or to determine if slashdot IS a good place to advertise).
• 2.) Dr.Educator has been assigned to poll professionals, and is using you to get the results.

You won't get an answer from me. Sorry.

Common training mistakes

[borkus]

...and my employer makes many of them.

1. Train management only. We're quite good about sending management to technology conferences. They attend the conference, don't understand what's being presented and conclude that conferences are of little value.

2. Train only to address skill deficits. I've been told I'm one of the experts on my team and have somehow wound up as the only full time employee who hasn't gone to training in four years. I'm a web programmer who's taught himself enough Unix and SQL to survive. When I've had a task on hand, I've been willing to teach myself enough to get the job done; most of my co-workers just throw up their hands and say "I don't know how to do that." So they get sent to training.

3. Ignore the class syllabus. One of my co-workers took an online class then promptly took a sit-down class from another vendor on the same material. So, of course, he comes back and says that the class didn't cover any new material. Good luck for getting anyone signed up for that class now.

Re:Common training mistakes

[King_TJ]

On item #2 there in your list of mistakes, I'd venture to say that honestly - you're better off in the position your in.

The people complaining "I don't know how to do that!" who get sent off to training are still going to come back with less usable knowledge than you have by figuring it out, hands-on.

What I've started figuring out is that training is of relatively little value unless it earns you some type of certification upon its completion. Certifications help get you future jobs. The other stuff doesn't. I've been to all sorts of training on everything from MS Exchange Server to Dynamic HTML development - and without certs. from any of it, people don't seem to really care.

I doubt the people getting shipped off to training classes in response to the "I can't do it!" exclamations are earning certifications.

Re:Training is a joke

[Twylite]

You are assuming the training is aimed only at programmers and for the purpose of teaching programming. This is seldom the case - most often training is used to promote a programmer's skills to include design knowledge, or management.

Where the object is to teach programming, the result is often shocking. Experienced C/C++ developers regularly come out of courses saying "Hey, I had no IDEA it worked like that".

Many developers take a "know one, know 'em all" approach to languages, without understanding that every language has its own unique way in which it is best applied. For all their syntactical similarity, Java and C++ are worlds apart in the way they should be used, for example, algorithms which are efficient in one are dogs in the other.

I have never been on a training course where I have not learned some useful piece of information. Even a presentation of the Thinking in Java course (after I had read the book and had 5 years of experience with Java) provided some insights which proved useful during project implementation.

On the other hand, I have never met someone who can be an "expert" on a language in one week. There is a lot more to language than syntax, and if you believe otherwise, you are seriously deluding yourself.

Training?

[ChuckDivine]

Perhaps I've been exposed to too many of those "intensive, hands on training" short courses that purport to teach everything about a topic in a few days. Generally, though, I've found such courses to be of little value. Personally, I'd rather learn by reading a book, interacting with peers and trying things out on my own. This style of learning is more incremental -- and I think it leads to better knowledge of the subject.

While I'm aware of the problem of using universities as a model, it's interesting that rather than two (or more) eight hour training sessions over a few days, universities will stretch the same amount of class time over several months, with practice time (homework) and discussion interspersed with the formal lectures. Practice, to me, is essential to really learning something. And "hands on, intensive" training just doesn't provide enough time for practice.

I have taught a few, very short courses myself. The approach I used was 2 or 3 two hour sessions spread over multiple days. There was plenty of time for practice during the training sessions. Students could also practice on their own between sessions. Some actually did. I also provided students with thoroughly documented examples that they could refer to back at their jobs. Finally, I made myself available for further consultation. My students indicated they found my approach quite helpful.

CSH

[IceFox]

When I was (on a break right now) at the Computer Science House at the Rochester Institute of Technology there were very frequent seminars given. To be a active member you have to do projects over the year. Many members fufill this requirment by giving a lecture on speciallized knowledge that they have. I myself have given a half dozen seminars. While at RIT I have to say that I learned more from these seminars then I did in classes. Frequently the speaker would compress down an entire course into 2 hours and because you actually wanted to goto this seminar you would pay attention, take notes and ask questions (gasp!). Requests for seminars would frequently get filled. Some seminars that I can remember include: OpenGL Programming, BeOS Programming, CVS/Perforce, Securing Linux, UML, Intro to Linux (A Geek intro, not mom&pop intro), Qt Programming, UI Design, OS Design, Computer science theory, logic, compression algorithems, genetic algorithms, DNA computing, neural networks, parallel computing, network design, network programming, and java. Pretty much anything went. I remember saturday mornings waking up and walking down the hall to spending the rest of the day learning about circut design.

Check out the official page here.

If you are in the Rochester NY area check them out. CSH is a very cool place that always has something going on (ping our soda machine!). Maybe you could give a seminar?

-Benjamin Meyer

Ok, I'm drawing the line when it comes to training

[Treeluvinhippy]

1: I will not chase the beach ball. Forget it. It just isn't going to happen anymore.

2: God dammitt, I am a giant cow of death! I will poop where I want.

3: Watching the villagers bring food and wood to the town center is boring.

4: Bringing food and wood to the town center is even more boring.

5: WTF! I am a giant cow of death! I don't want to learn how to use a water miracle to water the damn crops, I want to learn FIREBALL!

6: The throwing villagers around the island trick is pretty fun though. C'mon teach me more stuff like that and this relationship will change for the better.

The best training I've had...

[cduffy]

...was just communication with my coworkers.

What better way to learn to do kernel debugging than to be tutored (and given a helping hand when needed) by the fellow down the hall that does it all day long? What better way to learn good design process than to hang around with the product leads and get involved in their discussion? What better way to learn the QA process than to get involved in writing software with them for a bit? I've done the formal education thing -- spent four years doing it -- but I never learned as much in as little time as when being given a helping hand (or just chatting over lunch) with a coworker more experienced than me.

Alternately, I've had the opportunity to help and tutor some (other) coworkers as well. An environment in which folks are encouraged to share with -- and learn from -- others is perhaps one of the most valuable things a company wishing to have a robust, happy engineering department can have.

I don't know that there's anything that's been done by management or by the founders to encourage this behaviour, by the way, except hiring the very best engineers they could. Politics and one-upmanship don't mix well with an engineering mindset (well, not a hacker mindset, in the Jargon File sense), particularly when everyone involved respects each others' skills -- and teaching and learning are things we all enjoy.

Train internally--if you can

[JThaddeus]

The most successful training I have seen was the internal training program that TRW set up in its northern Virginia offices. I was there five years and found that it worked quite well.

First, we had a committee, chaired by Human Resources but staffed by employee volunteers. Second, we had a budget with which to furnish classrooms and pay instructors. Our classrooms had PCs, Mac, Linux, and various servers. We managed the classrooms, scheduled instruction, and picked instructors. The instructors were fellow employees.

Using your own employees has several advantages. First, you know this guy or gal. You can look at their work and see that they know their stuff. Next, the person knows you and they can tailor the instruction accordingly--like match it to current or future projects. Finally, the person is available during the work day for questions should they arise. For example, I became Joe-X-Windows and, as a result, had my pick of projects

Classes were mostly held after work hours, starting at 5pm. Instructors were paid (8 years ago) $25/hr for preparation (negotiated ahead of time with the training committee) and $30/hr instruction time. Slots went first come first serve or, occassionally, to projects/employees where a need was seen.

Everyone got a lot out of this: The student got a good class. The instructor got some extra money, the chance to look good to his/her peers, and the learning experience of teaching. And the company got off cheap! Not that we didn't send people outside when necessary, but looking inside worked very well.