Teach Programming to become a better programmer(zeroequalsfalse.press)
zeroequalsfalse.press
Teach Programming to become a better programmer
https://www.zeroequalsfalse.press/2018/06/10/teach/
59 comments
> 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.
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.
Yes! There is crazy amounts of dilly dallying with these analogies and there are implied points of logic that are not to belong in the actual technical concept, especially when teachers make it a point to say "these should be separated into a superclass/subclass/attribute but these shouldn't, and it should be specific to this extent and not to the extent that you thought was fitting", while talking about cars and car parts or animals and animal parts and species etc and, there is no actual logic behind their arbitrary separation of concepts that makes sense in their mind, it could be implemented in multiple ways that work, but only the one that they thought made sense to them is correct and students get punished for not thinking like the teacher even if they did something right, this leads to the students wondering if the concepts are just too difficult and going over their head when it's not their fault at all.
As a child (circa easly 2000s) I was immensely confused by the analogies that online guides used to explain OOP. I ended up so confused that I just gave up for many years until a wonderful professor explained it to us in plain, concrete language.
Analogies and use cases can help demonstrate _why_ something is useful, but can also obfuscate concepts.
Analogies and use cases can help demonstrate _why_ something is useful, but can also obfuscate concepts.
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".
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".
> 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.
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.
People learn differently. For me, it was probably they best book I have ever read to learn programming. Before that I only knew PHP from web tutorials and even functions weren’t obvious to me (I knew what they did, I just almost never used them because by the time I knew what the function was, I already inadvertently reused a lot of code – I still have one of my early websites with over 2000 lines of code in a single file and only two functions with 10 lines code each! It is an absolute nightmare to read but it worked). Head first java brought all those concepts to me in a way I understood and could apply and benefit from.
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.
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.
Absolutely what happened to me.
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.
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.
Can you go into a bit more detail about what you mean with these special fn_for_* things? I learned OOP recently with all the animal->mammal->cat analogies, however those all seem to focus on inheritance and miss the key concept which might be summarized as “managing context”. Am I on the right track here?
I'm not the original commenter (and on mobile, so this response might be a little terse), but I think what he's talking about is polymorpism. For an example, if you have two classes, Int and String, and you have a method special_fn you want to implement for both in different ways, (e.g. "addition/concatanation"), you can either make a bunch of special_fn_* stuff, or simply create an interface SpecialFner with the special_fn method, and implement it for Int and Str. This lets you use this interface in other places without worrying about all the different versions of this function.
Biggest issue I continuously encounter with new engineers is reinventing the mistakes of the past due not understanding the history of engineering and in turn what criteria we measure the quality of a decision on. Does this design take us closer to an over arching engineering ideal or farther a way?
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.
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'm interestied in this context. Thanks for posting it, of only not to plug the holes that my bachelor & master degree left me.
If you don't consider yourself talented, but you make it a profession, you can make it work and become successful, but if you have the talent, and you aren't a professional, then there's nothing you can do and everything will end in failure.
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.
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.
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.)
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?
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.
> 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.
Thanks for the article -- especially agree with the "Lead and take the charge." I feel that's very important if you expect to learn from mentoring.
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...
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...
I thought I was a pretty hot Pascal programmer in grad school. Then, for a period of time, I was tasked with teaching Pascal to professional programmers and engineers throughout Texas Instruments. I quickly discovered that there were aspects of the language (even in a language as simple as Pascal) that I found difficult to explain because I didn't fully understand them. Getting to teach the subject multiple times and each time making the presentation clearer made me understand the language, it's limitations, and effective use much better.
I've done this on IRC since the late 90s and I think it benefited me greatly, but you should see the blank stares I get when I mention this in interviews. Best just to forget mentioning "IRC" in general.
EDIT: "in interviews" to put things in real terms
EDIT: "in interviews" to put things in real terms
Yeah I spent hours in linux IRCs helping out new users, and it helped cement my understanding.
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.
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.
If you're in New York City or the San Francisco Bay Area, ScriptEd (https://scripted.org/volunteer/) offers opportunities to teach programming to students at under-resourced high schools. It's especially rewarding because these are students who are least likely to be exposed to this material in their normal curriculum. If your employer is OK with you taking half days twice a week to volunteer, then I strongly recommend it. It's a unique growth opportunity.
The "Lead and Take Charge" point is an interesting one, which I don't entirely agree with (if I'm reading it correctly).
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!
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!
This is what I do, I teach stuff to become better at it because trying to explain it to someone else makes you think of it as a designer where you have to reframe.
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.
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.
The easiest way to "teach" programming right now is to watch beginners programming on twitch and offer advice when you can. Trying to pair remotely through chat also imrpoves your pair programming skills.
Of course you could just write blog posts instead Kappa
Of course you could just write blog posts instead Kappa
There is not question that teaching Python to beginners has made me appreciate various aspects of the language better.
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.
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.
[deleted]
"Those who know how to do - do, those who don't - teach. Those who can't even teach - manage".
Ok this is not very accurate but still amusing...
Ok this is not very accurate but still amusing...
Should be "those who did - teach".
Maybe I'm the wrong audience for this (I have degrees in CS and Education and have worked in both fields) but this seems very simple/rudimentary and for the most part, doesn't really seem useful. Feels more like an ad for the link at the end.
"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.
"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.
An even better way is to program, program and program some more.
Doing ( creating software ) > teaching/explaining > doing nothing.
Nothing beats solving problems yourself.
Doing ( creating software ) > teaching/explaining > doing nothing.
Nothing beats solving problems yourself.
I'd say I learn different things from each.
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.
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.
There is a cliche in the martial arts world... that there is a large difference between 10 years of practice, and one year of practice repeated 10 times.
Be careful as you "program, program, program" of which one of those you are doing.
Be careful as you "program, program, program" of which one of those you are doing.
> Nothing beats solving problems yourself.
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.
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.
As someone who has done a fair bit of teaching, I agree. Teaching made me learn, but much less than working on actual projects. And the kind of stuff I've learned for teaching isn't very useful for real-world development. It tends to be edge-case trivia useful to reply to "clever" student trying to point inconsistencies in the technology I was teaching.
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.
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.
I agree, but programming over and over will not necessarily make you better, especially if you are solving the same old problems. After a while a webapp is a webapp if all you are doing is basic CRUD. It takes a strong focus and direction to move yourself towards a new direction to grow in the right way. Most people don't know how to engage in deliberate practice, they simple practice their comfort zone over and over again.
If the only thing you're aiming at is to become a better programmer, you may be right.
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.
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.
Yes and no.
Good advice for nearly anything.
Whatever it is, teach it to someone else if you want to understand it better yourself.
Whatever it is, teach it to someone else if you want to understand it better yourself.
In general, sure, that sounds like a great idea.
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.
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.
I do some mentoring on Codementor.io from time to time. Scammiest thing I've seen so far: program in Africa, teaching underprivileged to code. I was willing to mentor not for free, but at about 1/3 of my rate as I was on-board with what I thought the mission was. Then they asked me to sign an NDA... turns out the org was having the kids do client work. I noped out of that.
I said the same thing back in the day... Nothing teaches the nuance more than trying to explain something and being wrong in front of 20 people.. you make sure you fully understand it so it doesn't happen again.
It's embarrassing at first, but it can be turned into a learning experience for everyone. It can foster a more engaged, collaborative classroom when an instructor admits when he's wrong and graciously thanks students for improving their own knowledge. That said, the instructor should have the strongest grasp of the material.
I'd advise people to not teach if they don't understand the source material very well, it can lead to spread of misconceptions which can make the concepts more confusing for the students rather than less. I feel this is often left out of these discussions.
You can always pretend to teach yourself to navigate the concepts though, when learning the first time yourself.
You can always pretend to teach yourself to navigate the concepts though, when learning the first time yourself.
Teaching others, even if you don't know the material too well, pays because your students will come up with bugs, problems, and questions stemming from misunderstandings that you can't even conceive of. So it forces you to go away and find out and explain more clearly next time around. Pretending to teach won't come close.
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. :)
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. :)
My experience from TAing is that teaching forces you to go through the material very thoroughly yourself, much more than just studying for yourself. Also, when you go through the material for second time, knowing everything you have learned since then, you tend to notice new things.
I've found that when a developer on my team is tasked with explaining something to another team member, they themselves get a much better grasp of the topic.
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.
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.
> I've found that when a developer on my team is tasked with explaining something to another team member, they themselves get a much better grasp of the topic.
Tightly related, rubber duck debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging
Tightly related, rubber duck debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging
I'd argue that teaching helps you to push yourself to understand the subject matter more clearly. You might also be fooling yourself that you do comprehend something, and that becomes obvious when you can't explain the topic clearly.
This has been so true for myself and many of our instructors at Fullstack Academy. There are so many cool ideas in programming that you can get by without - but once you start teaching it forces you to truly wrestle with those ideas. Definitely makes you a stronger programmer on the other side.
What are some of those cool ideas?
Anecdotally, I can say that I don't think I've ever been more sure of the material I've learned than when I was serving as a TA/Tutor for a computer science class at my college.
let me add few things...
- 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
- 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
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.