CS pedagogy
I don't agree that experience can be taught. You can teach the result of experience, such as how now we know how you should basically never use naked pointers in C++. That's something we've learned from experience and we can save newbies the effort of learning that the hard way.
Experience itself cannot be taught, because that's the point. You experience it directly.
https://xkcd.com/1356/
It really does work like that. The brain is much, much better at dealing with the results of repeated experimentation than pure abstract facts.
Experience itself cannot be taught, because that's the point. You experience it directly.
https://xkcd.com/1356/
It really does work like that. The brain is much, much better at dealing with the results of repeated experimentation than pure abstract facts.
It only takes a split second to experience and learn, gain knowledge if you like, that grabbing a red hot poker with bare hands is not a good move. So there goes that time factor theory out the window.
No, I don’t see what you mean with the geometry analogy. It strikes me as relevant as the dissertation on CERN and the Higgs boson. They just don’t help making the case that programming can’t be taught which, more or less, is the original question.
Of course programming can be taught. As I commented before thousands are being taught right now.
In fact you said you were self taught as many others are. What better proof do I need that the original proposition is absurd?
No, I don’t see what you mean with the geometry analogy. It strikes me as relevant as the dissertation on CERN and the Higgs boson. They just don’t help making the case that programming can’t be taught which, more or less, is the original question.
Of course programming can be taught. As I commented before thousands are being taught right now.
In fact you said you were self taught as many others are. What better proof do I need that the original proposition is absurd?
I'll use a couple of analogies - as this was explained to me years ago by my late Professor Of Computer Programming when he was explaining why some of the class would seriously struggle and possibly/probably fail.
1) You can teach the structure and grammar of the English language. You can be given lists of words and their meanings. You can find other words in books such as a dictionary. Now assuming you're learnt the grammar, memorised the words and their meanings etc, will you therefore become a great best-seller author if yiu write a book? Probably not. Knowing how to and being able to do so doesn't mean that we are naturally great at it. Some will be naturally, some will become good if they really want and put in a lot of effort. Some will never become.
2) Similar. You can be taught the basis of mathematics up to performing integration of 'standard' simple expressions. Given expressions of the known type, you can then perform the required steps to undertake the integration. Then you are taught other integration techniques such as substitution and by parts. Then given an expression and the required technique to use, you should be able to complete the integration. However, given an expression and no hint, you have to use 'experience' as well as knowledge and a 'feel' for what would be the best method. Again, as with writing, some are naturally good at this, some will get there by dint of hard work and some will never be able to do it.
Really, the same can be said about programming. The language syntax can be taught/self taught. Given a detailed enough design, you can use your language knowledge to produce a working program. But without the given design, some instinctively know how to design the program, what data structs are best, what loops of what type are required etc etc. Some will get there after putting in a lot of work, trying different ways and finding our the best. Some will not be able to as they do have the 'feel' for producing the design/program - irrespective of how much 'teaching' they receive.
Way back when, there were 3 types of people. The system analysts who would produce the high level requirements of the system, the files, the programs, the interactions, the input/output etc. Then there were the analyst programmer who would take the system analysis and produce the required program designs. Then at the bottom were the coders who took the program designs and actually produced the code. The level of pay also reflected this hierarchy - with the system analysts paid the most down the coders who were paid the least. The job of the coders could (and would) be taught. The other levels were more concerned with experience and instinct - things which couldn't necessarily be taught. These levels have largely been replaced with others (and especially the difference between analyst programmer and coder) - but the idea still stands. Some made great system analysts or analyst programmer, many didn't.
Just like writing a book or performing integration or others - some are naturally good, some can become good by dint of hard work and some just aren't. If you aren't then really there's not much that can be done to make you good - other than to find a different line of work!
1) You can teach the structure and grammar of the English language. You can be given lists of words and their meanings. You can find other words in books such as a dictionary. Now assuming you're learnt the grammar, memorised the words and their meanings etc, will you therefore become a great best-seller author if yiu write a book? Probably not. Knowing how to and being able to do so doesn't mean that we are naturally great at it. Some will be naturally, some will become good if they really want and put in a lot of effort. Some will never become.
2) Similar. You can be taught the basis of mathematics up to performing integration of 'standard' simple expressions. Given expressions of the known type, you can then perform the required steps to undertake the integration. Then you are taught other integration techniques such as substitution and by parts. Then given an expression and the required technique to use, you should be able to complete the integration. However, given an expression and no hint, you have to use 'experience' as well as knowledge and a 'feel' for what would be the best method. Again, as with writing, some are naturally good at this, some will get there by dint of hard work and some will never be able to do it.
Really, the same can be said about programming. The language syntax can be taught/self taught. Given a detailed enough design, you can use your language knowledge to produce a working program. But without the given design, some instinctively know how to design the program, what data structs are best, what loops of what type are required etc etc. Some will get there after putting in a lot of work, trying different ways and finding our the best. Some will not be able to as they do have the 'feel' for producing the design/program - irrespective of how much 'teaching' they receive.
Way back when, there were 3 types of people. The system analysts who would produce the high level requirements of the system, the files, the programs, the interactions, the input/output etc. Then there were the analyst programmer who would take the system analysis and produce the required program designs. Then at the bottom were the coders who took the program designs and actually produced the code. The level of pay also reflected this hierarchy - with the system analysts paid the most down the coders who were paid the least. The job of the coders could (and would) be taught. The other levels were more concerned with experience and instinct - things which couldn't necessarily be taught. These levels have largely been replaced with others (and especially the difference between analyst programmer and coder) - but the idea still stands. Some made great system analysts or analyst programmer, many didn't.
Just like writing a book or performing integration or others - some are naturally good, some can become good by dint of hard work and some just aren't. If you aren't then really there's not much that can be done to make you good - other than to find a different line of work!
Last edited on
Topic archived. No new replies allowed.