Teach Programming to become a better programmer

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:

http://amazon.com/d/0692878971

It's either intermediate or advanced, depending on your perspective.

I had almost exactly the (almost the exact?) same experience.

I was 12 when I picked up a "Head First Java" at the library. The first chapters on for loops and variables were a breeze, but after a few more the book started a new program of loosely analogizing various function specifiers to real-world ontologies; all against the background of a writing style that emphasized that programmers can also write (and poorly photoshop) in a "WILD & ZANY STYLE THE KIDS WILL LOVE'. Yes, I'm starting to remember the trauma now: "Vehicles and Cars" or 1-Stripe Zebras vs Zebras-with-many stripes vs a Zebra with a stripes attribute...

I had no problem with a for loop to print "FUGAZI SUX" 99 times, but the book wasn't communicating how these concepts were important to making a nontrivial program in Java; which I desperately wanted to do so badly.

A bit later, I downloaded a book about writing computer exploits, which was very basic and very direct. Strangely, dealing with computers at this extremely basic level of stored instruction pointers, buffer overflows and assembly language actually let me gain the skills required to be an "actual programmer".

> This is good up to a point, and obviously it makes sense for absolute beginners.

The way classes are explained with cars and animals has always struck me as extremely perverse, I've seen a couple of very bright students who were just baffled by what lesson they are meant to take away from the analogy. Consider:

Vehicle is to Car as is Superclass is to Subclass.

Vehicle is to Car as also is a string of bits is to a C int.

Why is this analogy any more relevant to explaining class relations vs explaining that all data can be represented as a stream of bits? Or a whole list of other concepts where a thing is classified? Once the OOP vehicle-car analogy is probed past the truly superficial grammar, there isn't anything there.

Classes are an organisational tool. They have more in common with database normal forms and and functional programming than cars. Representing that an organisational concept should be thought about as a physical relation is not helpful.