31–40 of 60 posts
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.
An even better way is to program, program and program some more. Doing ( creating software ) > teaching/explaining > doing nothing. Nothing beats solving problems yourself.
Be careful as you "program, program, program" of which one of those you are doing.
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.
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.
>What do they know? They know real world. So when explaining something like for example a Superclass, you can use something like a vehicle... 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 promi…
Analogies and use cases can help demonstrate _why_ something is useful, but can also obfuscate concepts.
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.
>What do they know? They know real world. So when explaining something like for example a Superclass, you can use something like a vehicle... 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 promi…
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.
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.
Earlier quoted context omitted.
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.
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 learn…
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.
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.
Tightly related, rubber duck debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging
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!