Fault diagnosis and logic debugging using Boolean satisfiability
Debugging geographers: teaching programming to non-computer scientists
Transcript of Debugging geographers: teaching programming to non-computer scientists
1
Journal of Geography in Higher Education – Author’s Accepted Manuscript 1
http://dx.doi.org/10.1080/03098265.2014.908275 2
3
Debugging Geographers: 4
Teaching programming to non-computer scientists 5
6
Catherine L. Muller1a
and Chris Kidd2 7
1School of Geography, Earth and Environmental Sciences, University of Birmingham Edgbaston, 8
Birmingham, B15 2TT. 9
2 Earth System Science Interdisciplinary Center, University of Maryland, College Park, MD 20740, 10
USA and NASA/Goddard Space Flight Center, Greenbelt, MD 20771, USA 11
aEmail: [email protected] 12
13
Abstract 14
The steep learning curve associated with computer programming can be a daunting prospect, 15
particularly for those not well-aligned with this way of logical thinking. However, programming is a 16
skill that is becoming increasingly important. Geography graduates entering careers in atmospheric 17
science are one example of a particularly diverse group who often require a better knowledge and 18
understanding of computing. Critically, there is a necessity in the field for people with a diverse range 19
of data analysis and modelling abilities. This paper outlines the module design and evaluation of an 20
introductory programming course for non-computer scientists within a UK geography department. 21
22
Key words: FORTRAN programming, R, Linux, module design, meteorology, postgraduate teaching 23
in geography 24
25
26
2
1
1. Introduction 2
3
We are currently entering an era of ‘Big Data’ and ‘Internet of Things’ (Swan, 2012; Kortuem, 2013) 4
– educating tomorrow’s workforce with appropriate computer skills and capabilities is essential for 5
the UK economy. Industry workers, business employees and research scientists are increasingly 6
required to use coding and programming as part of their work (Robins et al., 2003), yet few are 7
sufficiently taught the basics (Slocum & Yoder, 1996; Merali 2010). A recent article in Nature 8
(Merali, 2010) explored trends and common pitfalls that scientists run into when they generate their 9
own code, stating that most scientists have no formal education when it comes to coding and almost 10
everything they know is self-taught. Various problems can arise from a lack of formal programming 11
training, with code-breaking bugs slowing down a scientist more than a professional programmer. 12
Basic training is therefore essential. However, due to the nature of programming, it is extremely 13
challenging to teach someone who has no formal background in the field (Dehnadi & Bornat, 2006; 14
Robins et al., 2003) and often computer science educators have no training in education pedagogy 15
(Holmboe et al., 2001), as highlighted by Laurillard (1993, p.3): 16
17
“Teachers need to know more than just their subject. They need to know the ways 18
it can come to be understood, the ways it can be misunderstood... they need 19
to know how individuals experience the subject” 20
21
Indeed, the dichotomy that the ‘best programmers’ are the worst at ‘enabling’ non-programmers 22
maybe be partly true, especially if teaching and learning is not addressed from a psychological or 23
educational perspective (Robins et al., 2003). Indeed, Pears et al. (2007) noted that although relevant 24
pedagogic research is conducted is disciplines such as education and cognitive science, this material is 25
often inaccessible to many computing educators due to disciplinary differences. 26
27
3
Computer science-related teaching, learning and implementation issues are commonplace within 1
broad, multidisciplinary academic departments, such as geography (Reeve, 1985; Rees, 1987; Slocum 2
& Yoder, 1996; Merali 2010). Most geography students are taught to use basic ‘point-and-click’ 3
statistics packages in Windows, such as Microsoft Excel, SPSS, or GIS software with familiar and 4
user-friendly Graphical User Interfaces (GUIs). Command-line interfaces and programming are 5
therefore very unfamiliar territory for most people with a non-computer science background, yet are 6
important for graduates pursuing many physical geography careers, particularly those involving large 7
data sets (e.g. meteorology, earth observation science, earth system modelling). It has been noted by 8
others (e.g. Nulty & Barrett, 1996; Bradbeer, 1999; Chapman, 2012) that students are attracted to 9
geography because the ‘soft, applied and active nature of the subject suits their learning style’ 10
(Chapman, 2012, p.205). The re-introduction of subjects such as mathematics, statistics and 11
computing at a later stage in their education can cause anxiety (Chapman, 2012). Indeed, a large 12
proportion of students will have never had any exposure to programming whatsoever, and as a result, 13
the inevitable steep learning curve will be a daunting and overwhelming prospect. Teaching computer 14
programming requires the integration of many learning sub-domains (Bloom, 1956) within a 15
supportive learning environment (e.g. interactive lectures, computer-based activities and assessments; 16
Biggs, 2003; Biggs & Tang, 2011) in order to be truly successful. 17
18
Although today’s students are more engaged with, and exposed to computers and technology on a 19
daily basis (via the internet, social media, computer games, smart devices, touchscreen technology 20
etc), they are more detached from the underlying mechanisms and computer processes involved. 21
Previous generations were brought up using command-line interfaces from a young age in order to 22
access computer games on old games consoles and home computers (e.g. Atari, ZX-Spectrum), or 23
using it at school as part of computing lessons (i.e. Logo, Basic on the BBC Micro, Visual Basic) 24
(Dagiene et al., 2013). Many students are now unfamiliar with traditional computer language and 25
command-line Operating Systems (OS) (e.g. MS-DOS, Unix, Linux) since most popular OS adopt 26
GUIs (i.e. Microsoft Windows, Mac OS10) while school-based computing classes have been mainly 27
focused on Information and Communications Technology (ICT) and using software packages for 28
4
creating databases, spreadsheets and documents (e.g. Microsoft Word, Excel and Access). As a result, 1
understanding of key computer concepts is lacking (Barnett & Windley, 1993). But there is more to 2
this understanding. Often ‘programming’ is more than a single entity – it is the blending of the 3
command-line, programming language, graphics system and shell programming – each can be learnt 4
on its own, but it is when they are combined that computing really pays dividends. Computers are 5
essentially ‘dumb; they wait to be told what to do and will do what you say, whether it is right or 6
wrong. Part of this learning process is preciseness – knowing that i and 1, 1 and l, 0 and O, are 7
fundamentally different – something that we (as individuals) instantly acknowledge as incorrect but 8
can carry on, whereas a computer will produce an error, not continue, or perhaps even worse, continue 9
erroneously. Introducing devices such as Raspberry Pi and Arduino to assist with computer science 10
teaching at both school- and university-level is expected to assist with such misunderstandings in due 11
course (The Royal Society, 2012). 12
13
Introducing a different, unfamiliar way of interacting with a computer to someone who has had no 14
experience with command-line interfaces and is only accustomed to GUIs, can therefore be a daunting 15
prospect. This may cause anxiety and frustration if not taught effectively, pitched at the right level or 16
delivered with clarity and patience. Occasionally, when students have had a negative teaching and 17
learning experience it detracts from the appreciation of what is being taught (Reeve, 1985) and in the 18
long term students may be reluctant to use those particular skills in the future. This has a potential 19
detrimental or restricting impact on their chosen careers, particularly if they wish to enter a research-20
orientated or data-intensive field. 21
22
As previously mentioned, programming is not a subject that can be completely and wholly ‘taught’. 23
Only a small proportion of professional programmers would consider themselves experts in all aspects 24
of computer science and every programming language, which are wide-ranging and often very 25
subject-specific. Students instead need to be equipped with the basic skills for solving specific 26
problems, thus becoming self-taught in order to progress (like any ‘foreign’ language, it is a real 27
example of the concept of “practise-makes-perfect”). This does not, however, mean that basic 28
5
programming and computer languages cannot be introduced using formal teaching methods – often 1
students simply require background theory and step-by-step demonstrations to get started. However, 2
this must be taught effectively using appropriate pedagogic techniques and using ‘real-world’ 3
examples and analogies that are familiar to them. Computer Science Education (CSE) research has 4
found that effective methods for teaching programming include the use of program plans (Soloway, 5
1985), implementation-independent pedagogic approaches (Ford, 1994), team working (Robins et al., 6
2003), mathematical constructs (Elenbogen & O’Kennon, 1988) and sophisticated educational 7
software (Holmboe et al., 2001). However there must also be a realistic assessment of what is 8
possible and what is desirable (Reeve, 1985). 9
10
Since computing and command-driven, or command-supplemented, software packages (e.g. some 11
statistical packages, GIS software) now represent an important component of most geographical 12
degrees (QAA, 2007) and related careers, this paper outlines a strategy for improving the delivery of 13
an introductory module in computer programming and data analysis to masters-level meteorology 14
students in a UK geography department. This enables them to have sufficient experience of coding in 15
order to process and analyse data sets to at least a basic level. 16
17
The second Author of this paper initially designed and ran the module for several years, whilst the 18
first Author now teaches the module; she was also a former student on the Masters course and 19
therefore has used her first-hand experience of the module as a student, along with feedback from 20
other students from previous years, to incorporate some of the outlined improvements. The module is 21
taught as part of an Applied Meteorology and Climatology (AMC) masters course that draws the 22
majority of the students from a geography background, although each year there are a number sourced 23
from other non-computer-science fields, such as environmental science, maths and physics. The 24
techniques implemented here could potentially be altered and applied to other geographical and 25
environmental subjects, or other undergraduate courses. A range of operating systems, open-source, 26
free-licence software is also utilised where possible, allowing students to download software in order 27
to permit independent learning and practice during upon completion of the introductory module. 28
6
Student evaluation from the current module is also presented and analysed to illustrate the 1
improvements made. 2
3
2. Module Design 4
5
This section provides an overview of the module design and pedagogy. The AMC masters course 6
covers a number of modules designed to benefit those entering the fields of meteorology and/or 7
climatology field. The programming and coding element of this course have been designed to 8
complement other AMC modules – for example, the statistics and analysis techniques that are 9
incorporated into the programming module are based on what theory the students are taught as part of 10
the ‘Statistics’ module, whilst the exercises are put into context by relating them to the ‘Atmospheric 11
Physics and Dynamics’ module. Furthermore, FORTRAN (FORmula TRANslation) is still the main 12
language used for meteorological and climatological modelling, and thus this aspect complements the 13
‘Climate Modelling’ module. As noted by Pears et al. (2007), course design and content are often 14
influenced by the history and culture of a department and the needs of prospective employers 15
(“Extrinsic Criteria”). The specific elements included within this module are therefore included for a 16
number of reasons: 17
18
The introduction and theory endeavours to bring all students up to the same level; 19
HTML (Hypertext Mark-up Language) is a simple, easy and familiar language which allows 20
students to gain confidence with computer-interpreted code; 21
Linux environment is used since it is common-place within the field; 22
FORTRAN is still widely used for meteorological and climatological modelling, and it is essential 23
that students are taught FORTRAN programming since it is a pre-requisite for many meteorology 24
jobs, PhDs and post-doctoral positions; 25
7
R is free data analysis software – similar to MATLAB and IDL which are other standard analyses 1
packages – allowing students to visualise data that has been processed or produced using 2
FORTRAN (which may occur in a real research job). 3
4
It must be noted that the module is not intended to deliver broad, expert computer programmers in the 5
time-frame of such a short module - indeed, expert programmers usually have several years of 6
experience (Winslow, 1996) - but rather an ‘advanced beginner’ (Dreyfus and Dreyfus, 1986). It is a 7
bespoke module, designed with the course objectives in mind: to impart knowledge about the subject 8
(within the context of the meteorology and climatology course) and to train the students to a specific 9
level with the relevant skills required to pursue a career in the atmospheric sciences. However, this 10
module could easily be adjusted and used as a foundation for other geography-related courses (e.g. 11
geology, air pollution, hydroecology). 12
13
The module consists of 20 hours of formal lectures and practical workshops, plus additional non-14
contact self-learning from each student. During each lesson example programs are demonstrated, 15
discussed and practiced interactively, before the students are given a number of exercises to allow 16
them to implement and practise what they have learnt, under the guidance of the lecturer and a class 17
demonstrator (usually a PhD student). The students are also able to liaise with the module leader for 18
assistance and explanations, both via email and in person. Table 1 gives a breakdown of the current 19
module – for each session a number of resources are suggested (e.g. online material, sites, tutorials, 20
guides and useful library books) along with a breakdown of the learning objectives and what is 21
expected from the students that session. The module is assessed by four continuous worksheets 22
(worth 50%), which are set at various stages, and a final exam (worth 50%). The latter is an open 23
book exam that replicates reality where programmers consult books, online forums and guides in 24
order to assist with their coding, therefore there is no expectation for the students to memorise 25
everything, emphasis is placed on understanding how to use what they have learnt. Recent 26
modifications to the module include incorporating R, adding in a dedicated session on Unix/Linux and 27
8
improving the methods used to explain specific concepts (e.g. through the use of diagrams, 1
visualisations and familiar, real-life concepts). 2
3
Another important aspect - and recent addition - is to provide ‘feed-forward’ prior to the 4
dissemination of each coursework assignment, where students were advised on issues arising in 5
previous years in order to help them avoid similar mistakes (Sadler, 1998; Whitfield et al., 2009). 6
Feedback and example answers are also provided after the coursework is marked. Timeliness of 7
feedback is also important – all worksheets are returned by the next class to ensure any problems are 8
rectified prior to proceeding onto the next topic. The first session includes an overview of the whole 9
module, including module description, key learning outcomes, the elements covered and the 10
organisation of the assessments, so that the students are aware of what material is to be covered each 11
week (Biggs & Tang, 2011). 12
13
2.1. Introducing Programming and Coding Using HTML 14
15
It is imperative that students, many of whom will have not thought about computers in this way since 16
school, are brought gently up-to-speed with computing basics. If this is not adequately achieved, 17
students may feel frustrated and disengaged from the outset. During the introductory session, an 18
engaging YouTube video [http://www.youtube.com/watch?v=nKIu9yen5nc&sns=em] is shown, 19
which contains ‘well-known’ programmers (e.g. Bill Gates, Mark Zuckerberg) and other ‘less-20
obvious’ code-enthusiasts (e.g. sports personalities, musicians) explaining how they got into 21
programming and why it is important. Basic computing concepts are introduced to gently ‘boost’ 22
learner’s confidence (Reeve, 1985), for example the structure of a computer, what programming is 23
and why we use it, basic terminology (e.g. bits, bytes, wordsize) and how computer memory works, 24
including an overview of data units (e.g. binary, hexadecimal systems). It is important that students 25
understand these basic concepts, since it will help them fully understand many of the aspects of 26
programming, such as memory, storage, etc. 27
28
9
One very successful way to introduce ‘computer-speak’ to non-computer scientists is to start with 1
HTML, as web pages are readily accessible and HTML is an easy ‘language’ to learn. Although not 2
‘programming’ per se, it is a simple way for students to gain confidence at the start of the module by 3
showing how simple code can be interpreted by the computer. This was first introduced to the 4
module in 2006, and has remained part of the introductory lecture due to receiving positive student 5
feedback. By creating web pages using HTML, the students begin to think in computer terms, 6
structure material and start to understand how code can be used to produce a desired result. Following 7
introduction and demonstration of how to use HTML (Table 1), students are given the opportunity to 8
produce some web pages, either personal or subject-related (which many subsequently go onto 9
develop further). 10
11
2.2. Computer Platforms and Operating Systems 12
13
The majority of students will only have had access to PCs/Laptops and Windows OS (and in some 14
cases, Apple Macs) up to this point. The concept of different platforms, such as Unix and Linux, will 15
often be very new. It is important for students - especially those who progress towards a career in 16
programming - to be aware and have some experience in using a command-line OS, since most 17
programming is conducted on these types of OS. Furthermore, it shows students that computers wait 18
to be 'told' what to do next and it is the critical-level for dealing efficiently with problems, 19
copying/moving files, etc. It is worth noting that a point-and-click FORTRAN compiler within a 20
windows environment was previously used, but problems with this software/platform impacted 21
student confidence. Importantly, students still needed to know how to generate lists of files, merge 22
files etc. - something far more achievable with the command-line interface. The use of X-windows 23
software on PC-based systems to access remote Linux/Unix hosts is also akin to a ‘real-world’ 24
research environment. 25
26
In order to provide students with some practice in using command-line OS, one whole lesson is 27
focussed on Unix/Linux, along with FTP, networking and x-windows environments (Table 1). 28
10
Previous feedback indicated that if this teaching is done parallel to FORTRAN, confusion can result 1
since students feel they are learning two completely new things at once (e.g. some students try to 2
incorporate Linux commands into the FORTRAN program and vice versa). Therefore spending 3
practical time focused on familiarising themselves with the Linux environment and Linux commands 4
is critical prior to learning the programming language itself. This provides a foundation and makes the 5
students’ learning and understanding of programming in subsequent sessions more straightforward – 6
thus after this session, focus is primarily on teaching the programming language, not how to use the 7
‘new’ OS. 8
9
2.3. FORTRAN 10
11
‘FORTRAN’ is the high-level language that is taught on this module. The advantages of FORTRAN 12
are that it is easy to learn (essentially only two command structures - the 'do loop' and the 'if' 13
statements in FORTRAN 77), can be easy obtained with the GNU license, interfaces with other 14
software (FORTRAN can call C-routines - and vice versa), is relatively easy to learn since it uses 15
familiar ‘English’ terms (e.g. for, if, then, else, do) which aids learning and helps in detection of 16
erroneous coding, and is faster when compiled than many other languages. But perhaps more 17
importantly for the AMC course, FORTRAN is still the standard choice of language (e.g. 18
Easterbrook, 2012) in the field of meteorology and climatology (e.g. for computer modelling and 19
processing large data sets). Therefore knowledge and experience of the language is essential for 20
anyone aspiring to enter this field. Specifically, FORTRAN 77 (ISO 1539:1980; 21
http://gcc.gnu.org/wiki/GFortranStandards) is used to explain some fundamental program structures 22
and why we do certain things (e.g. explicit declaration vs. implicit types) that are not necessarily 23
required in future versions. However, this work could easily be modified for FORTRAN 90/95 24
(ISO/IEC 1539:1991 and ISO/IEC 1539-1:2010; http://gcc.gnu.org/wiki/GFortranStandards) or 25
indeed, other computer languages (e.g. JAVA, C++). 26
27
11
FORTRAN is taught using a central, networked-Linux machine which the students access from a PC 1
(using Open-Text - formerly Hummingbird - Exceed software; http://connectivity.opentext.com/), but 2
Linux OS or Unix machines could also be used directly, where available. A syntax-highlighting tool 3
‘Gedit’ is used to type in the FORTRAN code. Since the best way to progress with any language is 4
consistent use and practise, options are also provided for practising code off-campus using windows-5
based compilers (Silverfrost Plato) that students can download free of charge to their personal 6
computers. 7
8
It is important not to rush through these fundamental elements of programming, since any 9
misunderstandings that occur at this stage may have detrimental impacts later on – this is particularly 10
important for students who have no previous experience of programming, as it will be completely new 11
to them and as such, is a very steep learning curve. The five programming domains (orientation, 12
notional machine, notation, structures and pragmatics) introduced by Boulay (1989) were used to 13
inform the module design. Table 1 provides specific details of what is covered. As part of this 14
module, students are given the opportunity to work in pairs to ‘role-play’ and talk through the 15
processes and stages of a program with one another to see the kind of steps used by a program from 16
start to end (i.e. one student gives the second student a value and the second students has to convert 17
that value using a simple equation and provide the output value to the first student). Flow-diagrams 18
are produced by hand, again in pairs, for specific tasks, in order to demonstrate the need for structure 19
in program development. This is not officially ‘pair programming’ per se (Wray, 2010; Sheard et al., 20
2009; Braught et al., 2008; Hanks et al., 2006; Mendes et al., 2006) since the students produce 21
independent code, but is similarly a useful and mutually-beneficial learning technique, which for 22
students who have never written any kind of code, is an excellent way to ‘walk though’ problems 23
step-by-step. Indeed, many of the students use this method throughout the module and beyond in 24
order to understand problems and work out structured solutions. By working informally in pairs or 25
groups (as encouraged throughout the module) students discuss and identify issues, and observe, 26
review and debug each other’s programs using informal code walkthrough techniques (McKenney, 27
2011) to locate errors. 28
12
1
Figure 1 shows an example of the algorithm development for one of these tasks – it is important that 2
the tasks are familiar to the students, so in this case, students were asked to first produce a 3
methodology for converting temperatures from Fahrenheit into Celsius, and then between Celsius, 4
Fahrenheit and Kelvin depending on what the input is. This is a very simple, yet important way of 5
getting students thinking of how problems are solved and the stages that need to be carried out in 6
order to reach an answer. Logical progression through a problem is a key element of programming, 7
so it is essential that it is broken down into its constituent elements. One way students are asked to 8
approach programming is to consider how they would view a cake recipe or flat-pack furniture 9
instructions – the various stages of the recipe or instructions need to be carried out in the correct order 10
to produce the desirable result. 11
12
After producing the customary ‘Hello world’ program, students then take the methodology they 13
composed earlier by hand and turn them into successful FORTRAN programs. Various text files 14
containing time-series meteorological data (see Table 1 for details of data files) are also processed by 15
applying the theory and programming learnt in previous lessons to a number of exercises which link 16
with other course modules (e.g. Statistics, Mathematics, Atmospheric Physics and Dynamics). For 17
example, a ‘bubble sort’ algorithm (Knuth, 1997) is applied to a simple hourly temperature dataset in 18
order to rank the data in descending order and to subsequently calculate a range of statistics (e.g. min, 19
median, max, range, quartiles, percentiles). 20
21
Advanced concepts are examined later in the module, including arrays and subroutines. Arrays can be 22
quite a complex subject to grasp for those new to programming, therefore the concept of 1, 2, 3+ 23
dimensional arrays are introduced once the students are comfortable with writing code and processing 24
data. In order to ‘visualise’ the organisation of the data up to 3D-arrays, a number of diagrams are 25
used (e.g. Figure 2) along with a Rubix cube which is handed out as a visual, tactile aid to help 26
explain how the data is stored and accessed using three do-loops. Finally, students are asked to 27
modify programs they have previously developed to incorporate sub-routines. Once all elements of 28
13
the module are formally covered, there is a session dedicated to reviewing and revising previous 1
topics to assist with bringing all students up to the same level of understanding and to prepare them 2
for their third coursework assignment which involves creating complex programs. By the end of the 3
module each student should have sufficient knowledge and understanding of FORTRAN and 4
programming in order to extract, collate and process data in an organised manner, in addition to the 5
necessary tools and understanding to independently progress with programming. 6
7
2.4. Data analyses in R 8
9
Prior to the introduction of the revised module, students were taught how to visualise and plot data 10
using FORTRAN and UNIRAS subroutines. However, feedback from students indicated that this is 11
quite challenging to learn and apply in the time allocated, resulting in significant frustration. 12
Moreover, this is now less frequently used as the standard method to analyse data and produce 13
graphics (FORTRAN is mostly used in modelling and processing large datasets) – more often, 14
command-line, visualisation packages, such as MATLAB, IDL and R are used to analyse and 15
graphically display data. Having an initial understanding of programming prior to learning such 16
analyses packages also assists with understanding of the coding that goes into the specific ‘functions’ 17
used within these packages, and as a result, students often grasp R quickly. Therefore, over the final 18
three sessions of the module the command-line, code-driven data analysis package, ‘R’, is introduced. 19
This is valuable to the student in the short-term, since many progress to use this package as part of 20
their dissertation as it is relatively easy to learn. Furthermore, R is free to download therefore 21
students are able to install the software on their personal computers. RStudio (2011) is the integrated 22
development environment (IDE) chosen for learning R, due to its user-friendly interface (Torfs & 23
Brauer, 2012; Figure 3). Since it is an increasingly popular piece of software, there are many online 24
tutorials, help guides, code and packages that can be downloaded, providing considerable support 25
during the learning process. R was chosen over others such as MATLAB or IDL, since these software 26
packages have expensive licenses and there is a growing demand for training in such open source 27
software. Furthermore, students that are required to use similar packages such as MATLAB in the 28
14
future, find these easy to learn once they have experienced R (Note: there are numerous books 1
available explaining how code can be transferred from one language to the other). R also has a large 2
and growing community of scientists and researchers who contribute to its development, there is a lot 3
of readily available support for beginners online and it allows for professional-looking, publication-4
ready plots and graphics to be produced with ease, (also R handles dates and times with ease, unlike, 5
for example, Excel). After just 6-hours of practical lessons, students with no prior knowledge of R 6
leave with an understanding of R data structures, reading in/writing out data, producing plots, 7
conducting statistics and performing spatial analyses (Table 1). By linking the R lessons to the 8
statistics theory which is taught on the AMC course prior to this module, the students gain a better 9
understanding of how to apply such analysis techniques using a coding environment. Meanwhile, 10
data which is familiar to the students (e.g. meteorological and atmospheric data sets - see Table 1) are 11
processed using FORTRAN are subsequently analysed in R, as may be required in reality. The wide-12
range of activities incorporated provide a broad overview of R sufficient to build on for coursework 13
and dissertation projects. 14
15
3. Evaluation 16
17
In order to assess how successful new teaching strategies have been, data from two key indices, 18
student evaluation and overall module results, are often examined. Although the students’ results 19
have generally improved over the years, significant alterations have been made to the module over 20
time (e.g. different lecturers, module structure and content). Furthermore, the AMC course attracts a 21
very diverse group of students; although geography graduates comprise the single largest group each 22
year (e.g. 81% of the cohort in 2010-11; 38% in 2011-12; 69% in 2012-13; Figure 4), the numbers 23
with geography, environmental science, mathematics and physics backgrounds do vary each year. 24
Therefore it would not be a fair comparison to use the module results. From a teaching and learning 25
point of view, the educator is also more interested in the feedback provided by students in order to 26
improve the module and teaching methods. Therefore, only data from the student evaluation 27
15
questionnaires, which are completed at the end of the module, are examined for assessing the module 1
design and pedagogy. These formal evaluations have been implemented and developed by pedagogic 2
experts within the school – the main questions are based around: 3
4
Understanding of the module 5
Structure of the module 6
Learning materials and resources 7
Module organisation 8
How inspirational and/or intellectually stimulating the module is 9
Staff availability 10
11
The response rate to the evaluations is consistently high over the observed years, varying by just 4.3% 12
over the whole period, from 91.7% in 2006/07 to 96% in 2011/12. Figure 5 shows a bar chart of the 13
mean student evaluation scores from six academic years covering the period 2006 to 2013. Module 14
changes include the addition of HTML in 2006, whilst in 2011 a new lecturer took control of the 15
module, adding in a focused Unix/Linux session, modified pedagogic techniques and visualisation 16
methods for explaining complex programming concepts, and the R component. As evident, student 17
evaluation scores have varied over this time period, with changes relating to the introduction of new 18
components clearly visible in Figure 5. The mean evaluation score increased after HTML was added 19
to the module in 2006 (“post-HTML”), and then increased further after the addition of the new 20
lecturer plus associated module changes (e.g. addition of R, different pedagogic techniques) in 2011 21
(“post-R”). Furthermore, the standard deviation of the evaluation scores decreased indicating that the 22
general view of the module by all students has been consistent over the past two years, despite 23
changing student demographics (Figure 4). Indeed, there were (unusually) more non-geographers in 24
2011/12 (54%), but both 2010/11 and 2012/13 had more far more geographers (80% and 69%, 25
respectively) yet there were divergent evaluation scores in 2010/11 and 2012/13 (3.2 and 4.5, 26
respectively), thus supporting the view that changes to module content, design and delivery have had 27
16
more influence on evaluation scores over this time period than changing student demographics, and 1
thus student abilities, each year. In particular, this may be due to ensuring that students of all abilities 2
are engaged in the subject and focusing on explaining basic-yet-complex topics more thoroughly to 3
students, particularly those who struggle early on. At the same time, it is important to continue to 4
‘stretch’ those of a higher-ability. 5
6
In order to explore this further, the data for commonly asked questions are shown in Figure 6 for each 7
year (where available). It is evident that there has been a consistently high view of all aspects of the 8
module over the past two years. By looking further at module scores from previous years - which 9
were used to make the changes, as outlined in Section 2 - it can be seen that the organisation and 10
structure of module and the learning materials were viewed less-favourably in some years. The 11
exception was 2008-09, where scores were more consistently high – without data on demographics 12
and detailed qualitative comments (unavailable for this year) however, it is not possible to ascertain 13
the precise reason why evaluation scores were high for this year in particular. 14
15
We can investigate these trends in more detail by analysing the qualitative ‘freeform’ comments 16
provided by students (available for 2010-2013). Hazzan et al. (2006) suggested that quantitative 17
research is used for determining whether something is so, whilst qualitative research is to determine 18
why it is so (Sheard et al., 2009). The nature of the student comments have varied over the years and 19
have been instrumental in directing the alterations that have been made over the years. For example, 20
in 2010-11 and subsequent years, the methods of assessment were praised and these have remained 21
the same over the years, as was the HTML that was introduced in previous years, e.g.: 22
23
“Methods of assessment well chosen” (2010-11) 24
“[Best aspect was] learning HTML” (2011-12) 25
26
Whilst overall, the feedback on the knowledge, helpfulness and enthusiasm of the lecturing staff has 27
remained consistently high over the years: 28
17
1
“Excellent teaching in class” (2010-11) 2
“Very good lecturing style – made a hard subject far more manageable” (2012-13) 3
4
However there were a number of requests in 2010-11 for more time of difficult aspects of the module 5
and more feedback, e.g.: 6
7
“Spend more time on harder aspects of the module.” 8
“More detailed explanation of difficult concepts and explain how your [programs] have been 9
produced in more detail.” 10
“More helpful feedback [needed].” 11
12
Whilst for 2011-2013, there were more positive comments about the module structure and 13
reorganisation, reflecting the changes that had been implemented (as outlined above), e.g.: 14
15
“Completely new material eased in gently.”(2011-12) 16
“[The best aspect was] the breadth of packages/systems introduced.” (2011-12) 17
“There was enough time.” (2011-12) 18
“Simple and not over-complicated.”(2012-13) 19
20
Furthermore, the R component that was added in 2011, has been particularly well received: 21
22
“R is fun!”(2011-12) 23
“More R!”(2012-13) 24
25
In general, there was an increase in the number and range of positive comments (e.g. “Never though 26
programming would be so good!”, 2012-13) as well as an increase in the evaluation scores, providing 27
an indication that students are engaged with the current format of the module. For example, many of 28
18
these students go on to use R as part of their dissertation, providing further evidence in support of 1
incorporating this particular topic. Therefore, from the data it is possible to conclude that on the 2
whole, students are happy with the current structure, content and delivery of module. The module 3
will continue to be improved and updated based on student suggestions and recommendations each 4
year – for example, in 2011-12, a number of students requested to receive the handouts before the 5
lecture, and this was successfully incorporated the following year, whilst in 2012-13 there was a 6
request for some advanced exercises for more able students, which will be acknowledged in the next 7
delivery of the module. Furthermore the course will be adapted to incorporate new technologies, 8
software and techniques as appropriate, for example more formal inclusion of programming pedagogy 9
(e.g. code walkthroughs, pair programming) and other technologies (e.g. use of Raspberry Pi) could 10
be built into the current module to improve it further. 11
12
4. Summary and Future 13
14
This article provides an example of how the complex subject of programming has been successfully 15
taught to non-computer scientists within a UK university geography department. The languages, data 16
and analyses incorporated are specific to the AMC Masters course to improve subject-familiarity; 17
however these methods could easily be applied to other subjects. The approaches used have been 18
developed and updated based on student feedback and incorporate a range of pedagogic techniques 19
following the principle of constructive alignment (e.g. interactive lectures, computer-based activities 20
and assessments, team working and collaboration, problem solving, troubleshooting, applying 21
knowledge; Biggs and Tang, 20011; Biggs, 2003; Robins et al., 2003; Bloom, 1956) to avoid 22
alienating students who may ‘struggle’, whilst still keeping those of a higher-ability engaged (e.g. 23
Robins et al., 2003). Furthermore, the introduction of a new lecturer appeared to reinvigorate the 24
module as new pedagogical constructs were introduced (Fanghanel, 2007). Indeed, the first Author, 25
and current lecturer, had previously taken this course as a student and therefore had first-hand 26
knowledge of being on the other side of the teaching-learning experience. This was extremely 27
beneficial for assisting with module design, and could easily be applied to other courses. For 28
19
example, if previous students were approached as ‘consultants’ to expand on any comments and 1
suggestions given on evaluation forms, additional modules could be improved in this manner. 2
3
Many university courses now contain programming modules, yet with a large number of students 4
leaving school with little knowledge of computers and programming, it is increasingly important that 5
these subjects are taught in the correct manner to avoid disengagement with the subject. 6
Furthermore, touch-screen technology is being incorporated into an increasing number of devices; 7
whilst this is making technology more accessible and user-friendly, there is potential for future 8
generations to become increasingly distanced from computing fundamentals. However, the outlook 9
does look promising. Following changes to the school ICT curriculum in various countries worldwide 10
(e.g. US: CSTA, 2005; Germany: Dagiene et al., 2013), recent reports (e.g. The Royal Society, 2012) 11
and articles in the national press have highlighted these issues in the UK, with new proposals for 12
traditional ICT lessons to be overhauled. As in other countries, there are now plans to revert back to 13
more ‘computer science’ orientated lessons in the UK, covering computer theory and programming 14
basics (Vasagar, 2012). Indeed, as of September 2012 schools are being encouraged to include more 15
computer science lessons (The Royal Society, 2012). These changes recognise the lack of a basic 16
understanding of how computers actually work in current generations, perhaps brought-about by 17
modern computing systems. As mentioned earlier, it is hoped that with the proposed changes to 18
school ICT curriculum, and with educational developments and incorporation of innovative hardware 19
(e.g. the Raspberry Pi, Arduino, ScratchBoards) and programming languages and software designed 20
specifically for educational purposes (e.g. Scratch, Kodu, Python; The Open university’s Sense 21
software) , more learners will become engaged with computing at an early stage (The Royal Society, 22
2012; Wakefield & Rich, 2013; Dagiene et al., 2013). As basic computer knowledge and 23
understanding increases in future generations, the subject will become less-daunting and university-24
level modules, even those aimed at students without a formal computer science background, can 25
evolve from a beginner’s level to a more intermediate level. 26
27
28
20
Acknowledgements 1
The first Author is funded on a NERC-research grant (NE/O006915/1) whilst the second Author is 2
funded by the University of Maryland and NASA. The Authors’ would like to thank Dr Lee 3
Chapman for providing useful feedback during the preparation of this paper, as well as the five 4
anonymous reviewers - their feedback has been incorporated within this manuscript. 5
6
References 7
Barnett and Windley (1993) Dysfunctional Programming: Teaching Programming using Formal 8
Methods to Non-Computer Science Majors [www] 9
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2694 (Accessed August 2012) 10
Biggs, J. (2003) Aligning teaching for constructing learning [www] 11
http://www.heacademy.ac.uk/assets/documents/resources/database/id477_aligning_teaching_f12
or_constructing_learning.pdf (Accessed April 2013) 13
Biggs, J. and Tang C. (2011): Teaching for Quality Learning at University, (McGraw-Hill and Open 14
University Press, Maidenhead) 15
Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain. New 16
York: David McKay Co Inc. 17
Bradbeer, J. (1999) Barriers to interdisciplinarity: disciplinary discourses and student learning, 18
Journal of Geography in Higher Education, 23, 381–396 19
Braught, G., Eby, L. M. and Wahls, T. (2008) The effects of pairprogramming on individual 20
programming skill, 39th SIGCSE Technical Symposium on Computer Science Education, 21
Portland, OR, USA, 200-204 22
Chapman, L. (2012) Dealing with Maths Anxiety: How Do You Teach Mathematics in a Geography 23
Department? Journal of Geography in Higher Education, vol. 34(2), p. 205-213 24
CSTA (2005) The New Educational Imperative: Improving High School Computer Science 25
Education, Final Report of the CSTA, Curriculum Improvement Task Force, 26
February 2005 [www] 27
21
http://csta.acm.org/Communications/sub/DocsPresentationFiles/White_Paper07_06.pdf 1
(Accessed January 2013) 2
Dagiene, V., Jevsikova, T., Schulte, C., Sentance, S. and Thota, N. (2013) A comparison of current 3
trends within Computer Science teaching in school in Germany and the UK, Informatics in 4
Schools: Local Proceedings of the 6th International Conference ISSEP 2013–Selected Papers 5
[www] http://opus.kobv.de/ubp/volltexte/2013/6450/pdf/63_75_dagiene_etal.pdf (Accessed 6
July 2013) 7
Dehnadi, S. & Bornat, R. (2006) The camel has two humps (working title) [www] 8
http://www.cs.kent.ac.uk/dept_info/seminars/2005_06/paper1.pdf (Accessed December 2012) 9
Dreyfus, H. and Dreyfus, S. (1986). Mind over machine: The power of human intuition and expertise 10
in the era of the computer, New York: Free Press 11
Easterbrook, S. (2010) What makes software engineering for climate models different? [www] 12
http://www.easterbrook.ca/steve/2010/03/what-makes-software-engineering-for-climate-13
models-different/ (Accessed July 2013) 14
Elenbogen, B.S. & Kennon, M. R. (1988) Teaching recursion using fractals in Prolog. 15
Proceedings of the 19st SIGCSE Technical Symposium on Computer Science Education, 16
20(1), 263-266 17
Fanghanel, J. (2007) Investigating university lecturers’ pedagogical constructs in the working context 18
[www] http://www.heacademy.ac.uk/assets/documents/research/fanghanel.pdf (Accessed 19
January 2012) 20
Ford, G. (1984). An implementation-independent approach to teaching recursion. ACM SIGCSE 21
Bulletin - Proceedings of the 15th SIGCSE technical symposium on Computer science 22
education, 16(1), 213-216 23
Hanks, B. (2006) Student attitudes toward pair programming, 11th Conference on Innovation and 24
Technology in Computer Science Education, Bologna, Italy, 113-117. 25
Hazzan, O., Dubinsky, Y., Eidelman, L., Sakhnini, V., and Teif, M. (2006) Qualitative research in 26
computer science education, 37th SIGCSE Technical Symposium on Computer Science 27
Education, Houston, TX, USA, 2006, pp. 408-412. 28
22
Holmboe, C., McIver, L., & George, C. (2001) Research Agenda for Computer Science 1
Education, 13th Workshop of the Psychology of Programming Interest Group, Bournemouth, 2
UK, April 2001 3
Knuth, D. (1997) The Art of Computer Programming, Volume 3: Sorting and Searching, Third 4
Edition. Addison-Wesley, ISBN 0-201-89685-0, 106–110 5
Kortuem, G., Bandara, A., Smith, N., Richards, M. & Petre, M. (2013). Educating 6
the Internet-of-Things generation. Computer, 46(2), 53–61. 7
Laurillard, D. (1993). Rethinking University Teaching: a framework for the effective use of 8
educational technology. London: Routledge. 9
Mendes, E., Al-Fakhri, L., and Luxton-Reilly, A. (2006) A replicated experiment of pair- 10
programming in a 2nd-year software development and design computer science course, 11th 11
Conference on Innovation and Technology in Computer Science Education, Bologna, Italy, 12
108-112. 13
Merali, Z. (2010) Error...why scientific programming does not computer, Nature, vol. 467, p. 775- 14
777 15
McKenney, P.E. (2011) Is Parallel Programming Hard, And, If So, What Can You Do 16
About It? [www] 17
https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2011.08.28a.pdf 18
(accessed July 2013) 19
Nulty, D. D. & Barrett, M. A. (1996) Transitions in students’ learning styles, Studies in Higher 20
Education, 21, pp. 333–345. 21
Pears, A., Seidman, S., Malmi, L., Mannila, L., Adams, E., Bennedsen, J., Devlin, M. 22
and Paterson, J. (2007). A survey of literature on the teaching of introductory programming. 23
SIGCSE Bulletin, 39(4), 204–223. 24
QAA (2007) Subject benchmark statements: Geography. [www] 25
http://www.qaa.ac.uk/Publications/InformationAndGuidance/Documents/geography.pdf 26
(accessed Feb 2013) 27
Rees, P. H. (1987) Teaching computer skills to geography students, Journal of Geography in Higher 28
23
Education, 11(2), 99-111 1
Reeve, D. E. (1985) Computing in the geography degree: limitations and objective, Journal of 2
Geography in Higher Education, 9(1), 37-44 3
Robins, A., Rountree, J., & Rountree, N. (2003). Learning and teaching programming: A review and 4
discussion. Computer Science Education, 13(2), 137–172. 5
RStudio (2011). RStudio: Integrated development environment for R [Computer 6
software]. Boston, MA. [www] http://www.rstudio.org/ 7
Sadler, D.R. (1998) Formative Assessment: Revisiting the territory. Assessment in Education. 5(1), 8
77-84 9
Sheard, J., Simon, M. Hamilton, and J. Lönnberg, Analysis of research into the teaching and learning 10
of programming. Proceedings of International Workshop on Computing Education (ICER 11
2009), Berkeley, California, USA, 2009, 93-104. 12
Slocum, T.A. & Yoder, S.C (1996) Using Visual Basic to Teach Programming for Geographers, 13
Journal of Geography, 95(5), 194-199 14
Soloway, E. (1985). From problems to programs via plans: the content and structure of knowledge for 15
introductory LISP programming. Journal of Educational Computing Research, 1, 157-172. 16
Swan (2012) Sensor Mania! The Internet of Things, Wearable Computing, Objective Metrics, and the 17
Quantified Self 2.0, J. Sens. Actuator Netw. 1, 217-253 18
The Royal Society (2012) Shut down or restart? The way forward for computing in UK schools 19
[www] 20
http://royalsociety.org/uploadedFiles/Royal_Society_Content/education/policy/computing-in-21
schools/2012-01-12-Computing-in-Schools.pdf (Accessed January 2013) 22
Torfs, B. & Brauer, C. (2012) A (very) short introduction to R [www] 23
http://cran.r-project.org/doc/contrib/Torfs+Brauer-Short-R-Intro.pdf (accessed February 24
2013) 25
Vasagar, J. (2012) Michael Gove to scrap ‘boring’ IT lessons [www] 26
http://www.guardian.co.uk/politics/2012/jan/11/michael-gove-boring-it-lessons (accessed 27
January 2012) 28
24
Wakefield, J. & Rich, L.J. (2013) Google to give schools Raspberry Pi microcomputers [www] 1
http://www.bbc.co.uk/news/technology-21243825 (accessed January 2013) 2
Whitfield, A., O’Doherty, M., Mony, A., Hetherington, R. (2008) Write it Right: Developing 3
academic writing within the discipline of computing using feedforward feedback, 9th Annual 4
Conference of the Subject Centre for Information and Computer Sciences, 26th – 28th 5
August, Liverpool 6
Winslow, L.E. (1996) Programming pedagogy – A psychological overview, SIGCSE Bulletin, 28, 17- 7
22 8
Wray, S. (2010) How Pair Programming Really Works, IEEE Software, 27 (1), 50-55 9
10
25
Tables 1
Table 1: Module overview (Approximately 2 hours per session – although this can be flexible 2
depending on how capable the student group is i.e. certain sessions may take more time, therefore 3
may extend into the following session). 4
Session Lesson Datasets Coursework
1 Introduction and HTML: - Basic computing concepts - structure of a computer, what
programming is and why we use it, basic terminology (e.g. bits, bytes, wordsize) and how computer memory works, including an overview of data units (e.g. binary, hexadecimal systems)
- HTML basics - what it is and how it is used, how to structure files and folders, basic commands, what editors and software can be used to produce web pages, how they can publish a website
- Web development activity
N/A (but students can source their own data/images to include in their webpage
2 Unix/Linux systems, commands and FTP: - Linux - creating directories, moving between directories, moving
files, changing permissions, x-windows (Exceed) - opening and using the text editor, creating files and advanced shall-scripts
- FTP – command-line and filezilla
Students create their own sample file using Gedit to test FTP
Worksheet 1a: Linux directories
3 FORTRAN Introduction/Basics 1: - Computer programming - high/low-level languages, machine
code, compilers, syntax, ). - FORTRAN background - what it is, why it’s used, history - Programming basics - variables, functions, commands, stages of
development – concept, algorithm development, coding and debugging
- Assignments and algebra - Functions and formatting - Basic housekeeping – commenting code
N/A Worksheet 1b: Variables and simple programs
4 FORTRAN Basics 2: - Program structures - Data types (real, integer, character) - Variables (implicit and explicit) - decisions (if-then-else-endif, regional operators) - loops (do-enddo)]
N/A Worksheet 2: Assignments & Algebra, Formatted I/O, decisions and loops
5 FORTRAN Basics 3: - Handling data files - using real and familiar data files
(input/output).
Various simple text files containing data (e.g. hourly temperatures, daily minimum and maximum temperatures)
6 FORTRAN Basics 4 [Arrays and subroutines] - Simple statistics (e.g. Pearson correlations analyses, mean,
standard deviations and descriptive statistics (e.g. min, median, max, range, quartiles, percentiles).
Text file containing time-series meteorological data for 1881-2007 (e.g. day, month, year, temperatures, precipitation, wind, pressure, humidity)
Worksheet 3:Processing data and statistics using programming
7 FORTRAN recap/revision
8 Introduction to R/R Basics 1 - The RStudio dashboard - Understanding ‘R-speak’ - Interpreting the R help file - Understand R basics (e.g. packages, functions and arguments,
the assignment operator, saving files) - Using various data structures (e.g. scalars, vectors, matrices,
data frames, lists) - Basic plotting - Basic datasets (e.g. I/O, exploring data) - A range of exercises.
N/A
9 R Basics 2 - Exploring a large air pollution data set (e.g. using packages such
as lattice, ggplot2) - Formatting dates and times - Time series analyses - Advanced plotting techniques - Statistics.
A csv file which contains hourly data for a range of pollution species, along with some meteorological data including wind speed and direction over a seven year period; A csv file containing a range of hourly meteorological data (2000-2006)
Worksheet 4: Analysing and visualising data using R
10 R Basics 3 A netCDF file of hourly air
26
- Exploring a spatial dataset of modelled air temperatures - Complex dara sets: NetCDF files - Plotting and analysing spatial data.
temperatures for a range of latitude and longitudes over four summer months in 2006
11 1.5 hour open-book exam N/A
1
2
27
Figures 1
2
3
Figure 1: Example flow chart showing the algorithm for converting between temperatures 4
28
1
Figure 2: 3D array diagram and rubix cube visualisation 2
3
Figure 3: The editor, workspace, console and plots windows in RStudio. 4
29
1
Figure 4: Student demographics by year [(2010-11 (13 students in total)); 2011-12 (25 students); 2
2012-13(16 students)] 3
30
1
Figure 5: Bar chart showing the mean overall evaluation score with standard deviation whiskers 2
[2006-07 (12 students); 2008-09 (13 students); 2009-10 (21 students); 2010-11 (13 students); 2011-12 3
(25 students); 2012-13 (16 students). See main text for response rate.]. 0 = poor (strongly disagree 4
with questions) 5 = excellent (strongly agree with questions). Grey-scale indicates the years when 5
specific changes were introduced to the basic course (NOTE: Evaluation unavailable for 2007-08 6
academic year; standard deviation unavailable prior to 2009). 7
8