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: c.l.muller@bham.ac.uk 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 け‘-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

31

1

Figure 6: Evaluation scores for common questions each year (2006-2013) – please see Figure 5 2

caption for number of students in each year (NOTE: Evaluation unavailable for 2007-08 academic 3

year). 4