Teach Programming to become a better programmer
zeroequalsfalse.press
zeroequalsfalse.press
This is good up to a point, and obviously it makes sense for absolute beginners. But eventually, when you understand programming, and just need to learn a new thing, it makes more sense to frame it in terms of actual use cases. I tried to read an explanation of JavaScript promises that used Shake Shack as an analogy and I think there were too many levels of indirection to understand it. Meanwhile, there's a Google developers post that explains it using image loading and that one clicked pretty much right away.
Analogies and use cases can help demonstrate _why_ something is useful, but can also obfuscate concepts.
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".
There is nothing strange about that. People learn in different ways. For me the Head First books were a great alternative to the scores of dry "here is fact 1. And here is proof for fact 1. Here is fact 2. Here is proof for fact 2." books, which bored me to death and didn't help me with learning.
What you are describing is a problem I see with a lot of people who learn programming. They want to apply what they have learned in a way that is different from a few modified example. When they learn python, after chapter one or two, the most common question is: but how do I build a GUI because the command line is very foreign to them. People often don’t have enough patience, or motivation to learn a whole book and not be able to do something remotely useful. I’m glad you got into it by learning something that really interested you with computers (unfortunately this is really hard these days because everybody I know either wants to program GUIs or Games).
I know some who got into programming by writing Minecraft plugins. That allowed them to apply what they learn to something really useful and fun. But I also like Apple’s approach with Swift. Children get immediate graphical feedback of what they have written. It’s certainly not something that teenagers have a lot of fun with (because “it is silly”) but children might really enjoy learning that way. Websites are probably another good example. Writing working JavaScript and html is really easy these days and a website is useful for a lot of people.
A class is not a car, you don't explode your car when you go off road, create a SUV using the base of the car along with what's in the trunk, then do it back again when you reach a road.
Analogies are a terrible way to teach. Both dogs and cows are mammals with 4 legs and a tail, but you will have an interesting experience playing catch with a cow and trying to milk a dog.
I only learned what a class is and why it matters after writing a bunch of C spaghetti code trying to keep track of special_fn_for_strings, special_fn_for_ints, special_fn_for_big_ints, etc. You can teach that way quite easily if you have more than a week to do it in.
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.
You can always pretend to teach yourself to navigate the concepts though, when learning the first time yourself.
So long as you approach it honestly; "you know, that's a damn good question. I'm not sure so I'll have to come back to you tomorrow." Then make sure you do come back to them. Or walk through the language reference with them. It will move you massively ahead in knowledge and soon kill off any misconceptions. It's OK to admit you got something wrong earlier in the week. Just don't do it daily. :)
When we are doing work we often do "what works" to complete the job. Somehow, becoming responsible for someone else's knowledge forces some people to understand their own limitations.
Tightly related, rubber duck debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging
As for the actual linked website, https://www.virtualprogrammingtutor.com/, it's highly unclear what the deal is. Are the people requesting tutoring going to pay for this? Do the tutors get paid?
Teaching programming to become a better programmer is one thing, teaching programming for free so that someone else can make money is a another thing.
The only course I've found is this one that starts from square one and gives new engineers this context is this: https://www.udacity.com/course/software-development-process-...
It would be great if there was more material online and we systematically teach new engineers history and context in addition to the nuts and bolts of making a program.
I've learned that lesson the hard way I think. I read the Pragmatic Programmer early in my career but I don't think I understood it very well.
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.)
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?
> 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.
Shameless plug but I wrote a Medium article about what I learned from mentoring an intern last summer and what people can get out of it. I'm mentoring another intern this summer and it's really great working with different people and how they learn in different ways.
https://medium.com/@augburto/the-menternship-why-mentoring-i...
- keep telling pupils the goods (of becoming a pro-gram-mer), AND telling them the bads. One at a time, some needs repeating often. Like the sky moments when u see someone using your stuff and liking it. Or the multi-shizophrenia that backs that achievement :/ They should know the whole truth, and decide - would they sustain all the pluses and the minuses, or such a vocation/devotion is not for them.
- teaching/mentoring, esp. around my place, isn't much $$$ rewarding.. if at all. More, you can be considered a nuisanse/"wtf" - when the common thinking is "give me monie/solutions, dont give me brains".. Sadly.
- i do teach people, quite a few years, but by working with them. Not by lecturing.. Lecturing works en masse but is veeery short-term/shallow. (example: from 50+ ppl i taught python-courses in last 2-3 years, various levels, ~6 became programmers and/or went using it.. half of them with further mentoring. From ~20-25 ppl i have worked-with and mentored in last ~15 years, all became pros... some better than me.)
- It is a very deep investment.. maybe as more for the teacher/mentor as for the pupil/mentee.
have fun www.svilendobrev.com
EDIT: "in interviews" to put things in real terms
It's funny looking back. Sometimes you can do something that seems engaging at the moment, but turns out to have been a massive waste of time. Yet hanging out in a chat room for hours on end felt like a waste of time in the moment but looking back it was very valuable to me.
I mentor weekly (codebar) and sometimes find myself not knowing the answer to a question. When that happens, I'm honest about my position, and then show the mentee how I go about figuring out the answer. After a couple of times I get them to suggest an approach to answering it. By doing this, I cede control. The point, after all, it to make myself redundant as a mentor!
Reframing opens up the potential to understand both as an end user and as a manipulator(creator).
Once you see both sides, it becomes clearer.
Whatever it is, teach it to someone else if you want to understand it better yourself.
Of course you could just write blog posts instead Kappa
For one how little need is there for map,reduce,filter in Python when you have list comprehensions and generators .
Still trying to find a use for coroutines though.
Ok this is not very accurate but still amusing...
"if you can’t do then teach! ;)" Maybe the winking face was meant to indicate that this is tongue-in-cheek but nothing else in the article really serves to support that. I dislike this phrase in general.
Each section seemed too cursory to provide any meaningful insight. As a teacher, I'm used to having people with less expertise offer me advice like "Use real world examples if you want to be effective." So, uh, use the vehicle, car, truck, etc... analogy when discussing superclasses and subclasses. Okay. Can you provide something else that's not so superficial? And calling words like "polymorphism" mumbo jumbo doesn't really help either. It's domain specific language that you should introduce eventually while making connections (both to other content in the domain and real world phenomena). Of course using those words without sufficiently explaining them isn't enough but shying away from key vocabulary because you underestimate your student isn't the best policy either.
"So if someone is not getting what you’re saying, try rephrasing your words and approach it like it’s a challenge on your end, not theirs." I think this is a good point and could be insightful for people who haven't taught before. Anyone that engages in teaching should hopefully realize it is a skill that takes effort, practice and reflection to hone (like any skill). You won't be perfect from the beginning. Assume your students are trying their best to understand and you are both trying to work together to build the connections needed to reach understanding. But if you're going into this thinking teaching is just a thing people do and your goal is to become a better programmer, I think there are more efficient ways to achieve that. You must be willing to put the time and energy into working on your teaching before you start seeing the benefits.
"it must be clear who is leading the way." Hmm... Definitely disagree with this. In the beginning I'm leading and directing but I'm trying to build skills, confidence and motivation such that control is slowly shifted to the learner (Student-led instruction is a big buzzword (buzzphrase?) in the edu world). I want my students to become independent so that whenever they leave me they can continue learning on their own. Going from having a boss/teacher that always takes charge to the "real world" of learning and doing all on your own can be disorienting. Let the student take the reigns so they get experience making decisions on their own while you're still there to offer guidance.
Sorry if this came across as harsh, I hope it can be taken as constructive criticism as opposed to me just being mean spirited. I definitely appreciate the subject of teaching popping up on hn.
Doing ( creating software ) > teaching/explaining > doing nothing.
Nothing beats solving problems yourself.
I work for Pivotal. Our default mode is fulltime pair programming.
Pairing has forced me to explain myself above a gut feeling level. I can't just say "it's better, my gut says so, trust me" to a pair. I have to explain my reasoning. Which requires me to try and discover what that reasoning is.
I learned a lot from stopping my pair any time I was lost and I've learned a lot from being stopped when my pair was lost. There's no real "teacher" or "learner" roles. You're in it together.
Be careful as you "program, program, program" of which one of those you are doing.
Assuming you understand why you solved a problem, and you solved it well. This is where teaching helps. You have to prove that you understand it, and because you are putting it out there, it will get judged and corrected. Often programmers can solve problems without understanding why their solution works, or whether it actually works and they are just missing something critical.
In fact, I'd go so far as to say that teaching well requires doing, but doing doesn't require teaching well, so one could make the argument that Teaching Well > Doing.
In my experience, a more valid reason to teach is that it makes you speak and stand up, which can be a kind of physical relief from sitting silently in front of a monitor all day. And also of course the joy of helping students who are interested in the subject.
However, I think you should try looking at the bigger picture: when you teach, you make two people better programmers. And that's when teaching a single person.