Teaching STEM to Novices: Maximize Your Effectiveness and Minimize Your Losses

1. Teaching STEM to Novices: Maximize Your Effectiveness and Minimize Your Losses Douglas A. Kranch2011 STEMtech conference

2. TeachingNovices Experts who teach courses to novices may include Various “tricks” they have learned Broad principles of the domain

3. Teaching Novices These are well-meaning goals: Bring novices “up to speed” quickly Help novices bypass the frustrations the experts experienced on their way to expertise BUT – students often fail to understand what experts consider the simplest principles by the end of the course.

4. Experts vs. Novices • Novices focus on surface features of problems • Rooted in the text • Read code like a story. • Program = collection of statements • Note the obvious

5. Experts vs. Novices • It takes up to ten years of dedicated work to become an expert • Everyone starts as a novice in a new domain • Three features of expertise are common to all domains: • Pattern recognition • Selective search • Rich knowledge Perception Response

6. Experts vs. Novices • Experts consider the deep features • Discuss programs at the functional level • Read program code in the order in which it is executed • Look for the purpose or function of parts in the whole; follow the power flow

7. Experts vs. Novices • Experts perform faster • Experts are twice as fast at understanding a program as novices • Experts can isolate bugs twice as fast as novices

8. Experts vs. Novices • While solving problems, experts: • Spend time trying to predict the overall scope of the final code and its rough spots • Apply previous solutions

9. Experts vs. Novices • While solving problems, novices: • Start working in the first direction that comes to mind and stick to it • Take little time to orient; it is easier than developing a mental model of the problem • Borrow solutions from everyday life • Have trouble seeing how subsystems interact • Add one part at a time, working from the program focus • Add and change the plan chaotically

10. Programming Ability Predictors • Unrelated or Unreliable Predictors • High school experience • Victorian Certificate of Education (VCE) results in English, mathematics, information processing and information systems • Learning style (other than relative abstraction) • Age • Encouragement from others to study programming • Self-efficacy score at the outset of the course. • Degree preference

11. Programming Ability Predictors • Unrelated or Unreliable Predictors • Job ambitions • Love of programming • Social well-being • Expected course grade • Preference to working alone or in a group • Emailing or surfing the web before and during the early stages of the course • Number of hours using application software • Prior programming experience

12. Programming Ability Predictors • Positive Predictors • Knowledge organization and self-efficacy rating at the end of the course • Belief that confidence and modularizing are keys to success • Sense of humor, patience, and persistence • ability in induction and syllogistic reasoning • Skill in manipulating rules of grammar and syntax • Performance on SOLO reading tasks for code writing • Total score by the Delta Vocabulary test

13. Programming Ability Predictors • Positive Predictors • Good spatial scanning map planning skill vs debugging • Induction ability (Seeing the rule from its examples) predicted detecting syntax errors vs ability to generate program fragments • Draw an overview map of the route showing integrated knowledge of the area • Higher LC-MATHEMATICS and PROG-SELF-EST • Use a consistent mental model • Past undergraduate grades

14. Programming Ability Predictors • Negative Predictors • More hours playing computer games • Often frustrated, with a tendency to immediately give up • Rate themselves poor in programming problem-solving ability • Dislike programming (A growing impact in second semester) • Have lower motivation with less planning, monitoring and regulating

15. Programming Ability Predictors • Negative Predictors • Use different programming models to solve different problems • Belief that memorizing problem solutions is the best way to learn how to program • Belief that a vast knowledge of programming techniques is needed to succeed • Belief that professional programmers see a solution almost immediately when faced with a difficult problem

16. Teaching • Sequencing • Procedures • Methodologies • Content • Writing New Code • Understanding and Debugging Existing Code • Laboratory and practice exercises • Assessment

17. Sequencing • Train perception first • Both write and readcode • Systematic code tracing as a base skill • Recognize where nested loops should be used • Present diagrams after understanding the concepts shown in them

18. Sequencing • Working memory must be able to hold all essential elements simultaneously for understanding to occur • Train prerequisites before skills • Good debuggers are usually good programmers • Good programmers are not necessarily good debuggers • Emphasize code reading and debugging

19. Procedures • Repetition • Varying points of view and a wide range of examples • Automation is an essential mechanism of learning • Repetitions well distributed

20. Procedures • Study Period Length • The duration of the learning periods has more influence on retention than the duration of the rest intervals • Increasing study duration • Study periods with lengths decreasing in a geometric progression • Interval between learning and sleep is short

21. Methodologies • Advance Organizers • A short introduction, presented prior to the text, providing the general concepts and ideas that can be used to understand the text • Increased transfer test performance for low ability subjects; most useful for technical or unfamiliar material, for “low ability” or inexperienced students, and when the test involves transfer to new situations • Decreased performance for high ability subjects

22. Methodologies • Adaptive Learning • Instructional sequence based on the performance on a rapid diagnostic tests • Decision based on performance and self-measured cognitive load • Visual Models • Given the model before learning • Not effective if too complex

25. Methodologies • Self-explaining • Describe the newly learned statement using a concrete graphic model of the computer

26. Methodologies • Self-explaining • Asked at each worked-out step which rule was applied • Take notes in their own words. • Helped performance on transfer for low ability subjects (based on Mathematics SAT scores) • No effect for high ability subjects

27. Methodologies • Cognitive Conflict • For students with problem in their pre-existing models • Requires students to mentally execute a program fragment and predict the result

28. Content • Having a viable mental model • Plans/Schema • Instructors should explain their problem solving strategies • Students are usually expected to implicitly construct them from their own program writing experiences • Novices do not tend to form models on their own; however, once they are helped to form one, they are able to use it

29. Content • Plans/Schema • Trace the development of a plan from focus to final form • In most instances, experts produce solutions using plans from a catalogue of plans • Plans to be taught: • Print the sum of the first n numbers. • Print the divisors of n and report if n is prime. • Print the value of n factorial. • Convert a measure in feet and inches to inches.

30. Content • In general, if novices master procedures before mastering the concepts behind those procedures, more efficient learning occurs than mastering both simultaneously

33. Content • If successive problems rely on exactly the same skills, then the problem context makes increasingly fewer demands. Thus, students should be given problems with different skill demands.

34. Writing New Code • Teach students to think before they write • Reduce the problem of fragile knowledge. • Explain exactly what commands do • Work through confusing areas • Elaborate • Caution students about treating the computer language as though it can communicate intentions • Find a balance between memorizing and understanding • Read the API documentation carefully

35. Writing New Code • Teach students to compile frequently • Stress effective testing techniques • Practice tracing • Concrete tracing a = 2; b = 3; sum = a + b; What is sum’s value? • Symbolic tracing while (count < max){statements}What is the value of count when the loop ends?

36. Writing New Code • Raise abstraction level • Need expertise, training • Syntactic detail processing must be automatized • Must create effective mental images for constructs • Concrete model early in learning • Modularization • introduce syntax and typical uses separately

37. Understanding and Debugging Code • Purpose must be discovered and derived • Experts vs. novices • Novices read the code as written, experts as executed • If novices cannot explain code, they probably do not possess the ability to produce it

38. Understanding and Debugging Code • Show novices how experts focus on abstract elements • Demonstrated examples • Worked examples • Model the analysis of buggy code

39. Laboratory and Practice Exercises Example Problems • Tracing exercises showing that • Statements execute sequentially • The order of the statements matters • Two statements do not execute simultaneously • The computer does what it is told and not what is intended

40. Laboratory and Practice Exercises Example Problems • Predict the output, then run the code • Worked-out examples • A limited number of standard problems • Completion problems • Troubleshooting experience

41. Laboratory and Practice Exercises Example Problems • Use a debugger • Designing/writing/debugging as distinct skills • Easiest bugs to fix are those found by the compiler • Difficult bugs: • Language-independent bugs • Malformed statements • Arithmetic errors • Loop conditions, conditional logic, arithmetic, and data initialization and updating

42. Laboratory and Practice Exercises Exploratory practice • Exploration practice forces novices to exert more effort for the same amount of learning than from worked examples • Students must be able to trace code well • Greater involvement for experienced students than with worked examples

43. Laboratory and Practice Exercises Deliberate Practice • A long period of practice and study • Enhanced if the learner is motivated • Practice is not enough to master a domain

44. Laboratory and Practice Exercises Paired Learning • Performance • Quality and duration favor pair programming while effort favors solo programming • Positive effect of pair programming for inexperienced programmers solving complex tasks • Percentage of trivial mechanical problems was nearly identical • Increase in effort

45. Laboratory and Practice Exercises Paired Learning • Personality • Students’ perception of their partners’ skill level • Partners had different Myers-Briggs personality types • No statistically significant personality traits for pair success • Not correlated with pair’s cognitive ability or conflict handling style

46. Laboratory and Practice Exercises Assessment • Recall/Recognition • Fixed-code • Skeleton-code • When new items are highly similar to studied items then both recognition and recall can lead to high levels of false recognition

47. Laboratory and Practice Exercises Problem Solving • The first solution step is a good indicator of the available problem-solving schemas • Skipping steps • Use tracing methods to investigate comprehension • The distinction between lack of experience and lack of conceptual understanding is crucial

48. Laboratory and Practice Exercises Debugging • Do they perform any test that provides information about the problem? • Better. Do they perform actions that possibly fix the problem and use the results to learn about the problem? • Best. Do they perform test-only actions to gather information relevant to the issue? • Do they mention a diagnosis or cause? • Do they consider more than one repair or fix? • Is a fallback provided? • Do they consider finding help as an option? • Do they consider working around the problem?

49. Laboratory and Practice Exercises General • Programming educators may be underestimating the difficulty of their assessments for novice programmers • Dehnadi and Bornat: “predict success or failure even before students have had any contact with any programming language with very high accuracy”

50. Laboratory and Practice Exercises General • Vessey classified programmers as novices or experts according to their ability to “chunk” the program they debugged and found expertise based on “chunking ability” to be an accurate indicator of debugging strategy and speed. • There are no errors fatal enough to motivate students to decide that a program is incorrect, although they would probably penalize a program by subtracting points from its score. The program would get a score greater than 0 as long as there was something in its code that was properly written and would be considered partially correct.