Programming Challenges

1. Programming Challenges Paul McMullan School of Computer Science Queen’s University of Belfast

2. Picture this… • Student meets their Final Year IT Project Supervisor for the first time: • Supervisor: “So, let’s try to figure out a suitable project for you to work on” • Student: “Okay, but as long as it doesn’t involve any programming – I don’t like that!” • Supervisor: * places head in hands *

3. The problem with Programming • Too often a student reaches final year without the required expertise / background in programming • This is a crucial time for these skills to be utilised • Many students are poorly equipped and grades can suffer as a result • … and these are the lucky ones!

4. The problem with Programming • Many students can reach final year by avoiding having to program to any great level of competency • Less “fortunate” students find the concepts or work too difficult to grasp, especially those with no previous exposure to programming • Programming alone can cause many students to withdraw or change degree pathways / career paths • Does this mean Computer Science was not for them??

5. Programming at QUB • Level 1 programming has been semi-notorious for many years • Main barrier preventing progression or skills development • General (old school) consensus was: • “If they can’t program, they shouldn’t be in the degree!” • However, IT these days is not all about programming – many IT professionals will never be involved in application development • Useful for background, but not always essential

6. Programming at QUB • Main problems faced traditionally: • High Fail rates • High dropout rates • 35% average drop-out rate (withdrawn or failure) over last 5 years • Rate was increasing over this period • Many progressing students had low level of programming competency

7. Programming at QUB • Main causes: • Expectation on Students quite high • Level of material dense, unclear or inappropriate • Programming Language complex (for beginners) • Delivery either obtuse or assuming some previous knowledge • Lecturer (may!) know what they are talking about, but simply can’t get it across

8. Java • Java main programming language taught at Queen’s • Advantages: • Free / Available to Students • Wide support network, copious helpful documentation • Professional Development Platform • Disadvantages: • A tough introductory language to learn (Objects, etc.) • No Integrated Development Environment (IDE), unlike Visual Studio or Delphi

9. Module Review • Main goals for the Review: • Allow beginners / weaker students a fair chance at programming • Do not put them at a disadvantage if they are weak in this particular aspect of IT • Keep stronger students motivated • Better Student tracking - Identify at-risk students • Avoid drop-outs - potentially worth an extra 2 / 3 years of fees per student • Java still an ideal platform for learning – just need to make it more accessible to all

10. Dangers • Change programming language – may not equip students properly (too simple), may not be available / free • Lighten the amount of material – again, danger of too little useful info, stronger students may get bored and unmotivated, danger from the “dumbing down” effect • Keep a tighter grip on student progress – students feel pressurised, intimidated… the “big brother” effect • More assistance and help provided – danger of spoon-feeding, remove the benefit of learning from mistakes

11. Proposed Steps • New (softer) degree to run in parallel with traditional Computer Science degree • Some commonality, but emphasis on programming skills main difference • Assessment reflects this emphasis – students can choose how they are graded • Lecture material to be made “User Friendly” – gentle learning curves • Tracking / Resources – attendance (lectures and practicals) monitored regularly with meetings, all resources available to students

12. Fundamentals / Challenges • All students enrol to “Fundamentals of Programming” module • Computer Science degree (traditional): • Programming competency quite high (greater emphasis) • Modules at a lower level of IT competency • Students also enrol to “Programming Challenges” • Computer Information Technology: • Less emphasis on Programming (some modules at higher level than Computer Science • Students remain at the “Fundamentals” level of programming

13. Fundamentals / Challenges • Students can choose which pathway they feel is best for them • Confident or Weak students can choose early • Undecided can choose along the way – originally difficult concepts can “click” for them • Recommendation to undecided is to assume a Challenges pathway and change if required • Students who grasp concepts late into the year can still pass the “Challenges” progression requirements provided their marks are reasonable

14. Assessment • Main difference between “Fundamentals” and “Challenges” (apart from Pathway itself) is how students are marked: • All students undertake the same core exercises / tests / exam questions • “Fundamentals” students’ marks are based on 100% of this • “Challenges” students must complete extra (more challenging) work to attain a potential 100% • The “Fundamentals” core assessment material is roughly two-thirds of the full “challenges” material

15. Structure • Module now spans 2 Semesters (was originally just one) broken into two distinct halves • First half deals with basic introductory concepts: • Statements, Syntax, Variables, Logic, Selection, Iteration, Methods • No Object-orientation – Objects are simply Variables at this point • Second half introduces further concepts: • Data Structures, Objects, Algorithms, GUI • More emphasis on how to use what has been learnt before

16. Structure • Each semester of material has a similar learning curve • Introductory concepts are delivered slowly, allowing a “bedding in” • Second half of each semester starts to ramp up • At this point students will have had time to ingest concepts, completed practical work, made their necessary mistakes and generally start to understand what they are doing • At no point is Recursion mentioned!

17. Main Assessment Breakdown • Semester 1 and 2: • Practical sessions (seen) • Class Test (unseen) • Practical exams (unseen) • 30 % for each semester • End of Semester 2: • Written exam • 40 % - 2 questions • Exam and later assessments broken into Fundamentals / Challenges sections

18. Teaching • Teaching Material required a major revamp • Separated into two distinct, but linked deliveries • Very gentle learning curve for first half of each semester • Material to appear light and friendly, while not sacrificing detail or required information • Closely linked to practical exercises – students not expected to tackle exercises which haven’t been introduced (at least) in class • Better ways required to get concepts across and help students remember what they’ve been taught

19. Teaching • Main techniques to explain concepts: • Lots of analogies to familiar aspects of students life • No confusion with Objects – variables only at this point • Repetition, Repetition, Repetition • Speed – tricky introductory concepts (such as Variables) taken slowly • Layering – introducing a little at a time, then building – e.g. data types – integer, double, String to begin with • Familiarity – same set of example programs used from start, but expanded or modified as new topics introduced

20. Other Techniques • “Pop” quiz: • “Millionaire” style multiple choice – one question, four possible answers • Students keep track of their own score – not assessed formally • Full explanations and run-through of the correct answer and reasons why • Some “tricky” questions – Can’t assume the obvious answer is the correct one • Light-hearted, provided good interaction, students seemed to “enjoy” it to a certain extent

21. Other Techniques • Continual Reassurance • Inform the student that this is renowned as a difficult subject • If they struggle, it’s not because they are stupid, but that it is indeed tough • Practice is important, no matter how discouraged they feel – getting to that Eureka moment • Mistakes are good – best way of learning • Sympathy – everyone goes through the same problems – few find it straightforward • Encouraging the use of lecturer / practical assistants / background info

22. Useful Examples • Real-World or amusing examples to explain difficult concepts got a very positive reaction from students • Helps them learn, but also reinforces associations • For example, comparing Black, Blue, Brown “Wheely” bins to Variables of different data types – can only put items of certain type into corresponding appropriate location • A light-hearted example was the use of “Pirates” to explain returning values from a Method…

23. “Pirates” • Pirates find and board a ship, to steal their treasure chest • Like all good pirates, they scuttle the ship and make the crew walk the plank • Unfortunately it’s only then they find the treasure and realise it’s in a safe, securely attached to the ship itself • Meanwhile, the ship is sinking fast • Luckily they manage to find the key in time and get the safe open • The treasure is grabbed and taken off the almost-submerged ship and onto the pirate ship

24. Example • Although this may seem like a meaningless little story, it very effectively explains what happens when trying to return values from Methods • Students get confused with the idea of local variables in Methods and Scope • The variables themselves are not returned, but the contents • When a Method is exited, any variables are destroyed but the values (valuables?) can be saved and sent back to the original calling Method (pirate ship)

25. Tracking • Attendance recorded for Practicals (compulsory to attend, assessed or otherwise) • Attendance recorded for first 6 weeks of Lectures, then randomly for next 6 weeks • Students not handed out lecture material directly – must download online – tracking kept of who has downloaded what • Students informed of all this, but reassured that it is to identify people in trouble, not to try to penalise or catch people out

26. Current Results • Lecture Attendance over 90% first half of semester, remained at 60%-80% latter half • Student evaluation feedback (taken twice) extremely positive (4.8 and 4.4 / 5.0) • Drop-out rate (withdrawn students) decreased from same time last year (roughly worked out as 4% of class as opposed to 15%) – exact figures will be determined later in year • Practical assessment results for first semester greatly improved over previous year

27. Current Results • Some anecdotal feedback: • Practical assistants reported that weaker students (who traditionally do not fully complete exercise), came well prepared, were tending to “stick at it”, and most were able to complete within the the time allotted • Stronger students found the extra “challenge” exercises interesting and did not leave early • Advisor of Studies reported it noticeable that fewer students had come to him with problems in relation to this module than in previous years • A repeating student (who had attended and failed the programming module last year) claimed to have been delighted to have written his first program single-handedly for the first time

28. Conclusions • Experience (and mistakes) has been useful in revamping and improving this module • Students have responded well to being treated with understanding and as equals • Initial results have been very encouraging!