Slashdot Mirror
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?"
If you alter your phrase to "geek teachers should train geeks", I'm behind it 100%.
--Chag
- 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.Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
...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.
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
...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.