In the first 4 months of 2018, I taught intermediate-to-advanced Python to about 2500 working engineers around the world. This was through a 30-hour series of online trainings, repeated once or twice each month.
It absolutely made me a better developer. Some comments:
* Since I don't teach beginners, some of the questions I get are really hard. As in, someone who's good enough at writing software they've been paid to do it for many years will encounter some hard problem, bang their head against a wall with it for days or weeks... and then ask me about it live during the Q&A.
* If I make some claim during class that is not accurate, the students - who, again, are all professional engineers in the work force - will eat me alive. The early classes quickly dispelled a lot of incorrect knowledge I didn't realize I had. (If I were teaching something like art or politics, maybe I could sometimes BS my way through something... but not coding.)
* Toy code sucks. I quickly figured out it is 10,000% better to have a realistic example that might actually exist in a production code base somewhere, for all sorts of reasons. This is also 10,000% harder to do well, for the instructor.
* We all have certain mental models and even beliefs that have been "installed" in our thinking from our previous coding experiences. A big part of my job is to quickly figure out what lens you're using to view coding reality (e.g. maybe you're a Java expat, and tend to think in terms of its type system); pace that reality so I don't lose you; and gently drag you into a very unfamiliar way of thinking, using the different metaphors required to reason about the new language/technology. Oh, I have to do it for 150 people from two dozen different countries all at the same time.
* Biggest surprise: what's been more useful than anything in helping me become better as a trainer: studying psychology and hypnosis. (Lots of subtle hints in how this applies in the previous item.)
> * If I make some claim during class that is not accurate, the students - who, again, are all professional engineers in the work force - will eat me alive.
This is interesting. I imagine that in high-level training for any industry this could happen. I'd personally try to let my students know that I'm not an all-knowing god and ask them to correct me if they noticed something I said was wrong, and I'd be happy learning something new. Maybe this is what you meant, but were you ever met with hostility or animosity because of this?
Also, what, in general, is intermediate-to-advanced Python?
No hostility ever, no, because (a) I freely acknowledge I don't know everything, and (b) I'll not hesitate to say if I don't know something or I'm not sure (or become unsure). People are of course really understanding and good-natured about it. "Eat me alive" is an overstatement; better to say they won't let it slide.
> Also, what, in general, is intermediate-to-advanced Python?
Basically the kinds of topics covered in my Python book, which I'll plug here without shame:
It absolutely made me a better developer. Some comments:
* Since I don't teach beginners, some of the questions I get are really hard. As in, someone who's good enough at writing software they've been paid to do it for many years will encounter some hard problem, bang their head against a wall with it for days or weeks... and then ask me about it live during the Q&A.
* If I make some claim during class that is not accurate, the students - who, again, are all professional engineers in the work force - will eat me alive. The early classes quickly dispelled a lot of incorrect knowledge I didn't realize I had. (If I were teaching something like art or politics, maybe I could sometimes BS my way through something... but not coding.)
* Toy code sucks. I quickly figured out it is 10,000% better to have a realistic example that might actually exist in a production code base somewhere, for all sorts of reasons. This is also 10,000% harder to do well, for the instructor.
* We all have certain mental models and even beliefs that have been "installed" in our thinking from our previous coding experiences. A big part of my job is to quickly figure out what lens you're using to view coding reality (e.g. maybe you're a Java expat, and tend to think in terms of its type system); pace that reality so I don't lose you; and gently drag you into a very unfamiliar way of thinking, using the different metaphors required to reason about the new language/technology. Oh, I have to do it for 150 people from two dozen different countries all at the same time.
* Biggest surprise: what's been more useful than anything in helping me become better as a trainer: studying psychology and hypnosis. (Lots of subtle hints in how this applies in the previous item.)