1

Journal of Geography in Higher Education Authors Accepted Manuscript

http://dx.doi.org/10.1080/03098265.2014.908275

3
4

Debugging Geographers:

Teaching programming to non-computer scientists

6
Catherine L. Muller1a and Chris Kidd2

7
8

Birmingham, B15 2TT.

School of Geography, Earth and Environmental Sciences, University of Birmingham Edgbaston,

10

11

USA and NASA/Goddard Space Flight Center, Greenbelt, MD 20771, USA

12

Earth System Science Interdisciplinary Center, University of Maryland, College Park, MD 20740,

Email: c.l.muller@bham.ac.uk

13
14

Abstract

15

The steep learning curve associated with computer programming can be a daunting prospect,

16

particularly for those not well-aligned with this way of logical thinking. However, programming is a

17

skill that is becoming increasingly important. Geography graduates entering careers in atmospheric

18

science are one example of a particularly diverse group who often require a better knowledge and

19

understanding of computing. Critically, there is a necessity in the field for people with a diverse range

20

of data analysis and modelling abilities. This paper outlines the module design and evaluation of an

21

introductory programming course for non-computer scientists within a UK geography department.

22
23

Key words: FORTRAN programming, R, Linux, module design, meteorology, postgraduate teaching

24

in geography

25
26

1
2

1. Introduction

3
4

We are currently entering an era of Big Data and Internet of Things (Swan, 2012; Kortuem, 2013)

educating tomorrows workforce with appropriate computer skills and capabilities is essential for

the UK economy. Industry workers, business employees and research scientists are increasingly

required to use coding and programming as part of their work (Robins et al., 2003), yet few are

sufficiently taught the basics (Slocum & Yoder, 1996; Merali 2010). A recent article in Nature

(Merali, 2010) explored trends and common pitfalls that scientists run into when they generate their

10

own code, stating that most scientists have no formal education when it comes to coding and almost

11

everything they know is self-taught. Various problems can arise from a lack of formal programming

12

training, with code-breaking bugs slowing down a scientist more than a professional programmer.

13

Basic training is therefore essential. However, due to the nature of programming, it is extremely

14

challenging to teach someone who has no formal background in the field (Dehnadi & Bornat, 2006;

15

Robins et al., 2003) and often computer science educators have no training in education pedagogy

16

(Holmboe et al., 2001), as highlighted by Laurillard (1993, p.3):

17
18

Teachers need to know more than just their subject. They need to know the ways

19

it can come to be understood, the ways it can be misunderstood... they need

20

to know how individuals experience the subject

21
22

Indeed, the dichotomy that the best programmers are the worst at enabling non-programmers

23

maybe be partly true, especially if teaching and learning is not addressed from a psychological or

24

educational perspective (Robins et al., 2003). Indeed, Pears et al. (2007) noted that although relevant

25

pedagogic research is conducted is disciplines such as education and cognitive science, this material is

26

often inaccessible to many computing educators due to disciplinary differences.

27

Computer science-related teaching, learning and implementation issues are commonplace within

broad, multidisciplinary academic departments, such as geography (Reeve, 1985; Rees, 1987; Slocum

& Yoder, 1996; Merali 2010). Most geography students are taught to use basic point-and-click

statistics packages in Windows, such as Microsoft Excel, SPSS, or GIS software with familiar and

user-friendly Graphical User Interfaces (GUIs). Command-line interfaces and programming are

therefore very unfamiliar territory for most people with a non-computer science background, yet are

important for graduates pursuing many physical geography careers, particularly those involving large

data sets (e.g. meteorology, earth observation science, earth system modelling). It has been noted by

others (e.g. Nulty & Barrett, 1996; Bradbeer, 1999; Chapman, 2012) that students are attracted to

10

geography because the soft, applied and active nature of the subject suits their learning style

11

(Chapman, 2012, p.205). The re-introduction of subjects such as mathematics, statistics and

12

computing at a later stage in their education can cause anxiety (Chapman, 2012). Indeed, a large

13

proportion of students will have never had any exposure to programming whatsoever, and as a result,

14

the inevitable steep learning curve will be a daunting and overwhelming prospect. Teaching computer

15

programming requires the integration of many learning sub-domains (Bloom, 1956) within a

16

supportive learning environment (e.g. interactive lectures, computer-based activities and assessments;

17

Biggs, 2003; Biggs & Tang, 2011) in order to be truly successful.

18
19

Although todays students are more engaged with, and exposed to computers and technology on a

20

daily basis (via the internet, social media, computer games, smart devices, touchscreen technology

21

etc), they are more detached from the underlying mechanisms and computer processes involved.

22

Previous generations were brought up using command-line interfaces from a young age in order to

23

access computer games on old games consoles and home computers (e.g. Atari, ZX-Spectrum), or

24

using it at school as part of computing lessons (i.e. Logo, Basic on the BBC Micro, Visual Basic)

25

(Dagiene et al., 2013). Many students are now unfamiliar with traditional computer language and

26

command-line Operating Systems (OS) (e.g. MS-DOS, Unix, Linux) since most popular OS adopt

27

GUIs (i.e. Microsoft Windows, Mac OS10) while school-based computing classes have been mainly

28

focused on Information and Communications Technology (ICT) and using software packages for
3

creating databases, spreadsheets and documents (e.g. Microsoft Word, Excel and Access). As a result,

understanding of key computer concepts is lacking (Barnett & Windley, 1993). But there is more to

this understanding. Often programming is more than a single entity it is the blending of the

command-line, programming language, graphics system and shell programming each can be learnt

on its own, but it is when they are combined that computing really pays dividends. Computers are

essentially dumb; they wait to be told what to do and will do what you say, whether it is right or

wrong. Part of this learning process is preciseness knowing that i and 1, 1 and l, 0 and O, are

fundamentally different something that we (as individuals) instantly acknowledge as incorrect but

can carry on, whereas a computer will produce an error, not continue, or perhaps even worse, continue

10

erroneously. Introducing devices such as Raspberry Pi and Arduino to assist with computer science

11

teaching at both school- and university-level is expected to assist with such misunderstandings in due

12

course (The Royal Society, 2012).

13
14

Introducing a different, unfamiliar way of interacting with a computer to someone who has had no

15

experience with command-line interfaces and is only accustomed to GUIs, can therefore be a daunting

16

prospect. This may cause anxiety and frustration if not taught effectively, pitched at the right level or

17

delivered with clarity and patience. Occasionally, when students have had a negative teaching and

18

learning experience it detracts from the appreciation of what is being taught (Reeve, 1985) and in the

19

long term students may be reluctant to use those particular skills in the future. This has a potential

20

detrimental or restricting impact on their chosen careers, particularly if they wish to enter a research-

21

orientated or data-intensive field.

22
23

As previously mentioned, programming is not a subject that can be completely and wholly taught.

24

Only a small proportion of professional programmers would consider themselves experts in all aspects

25

of computer science and every programming language, which are wide-ranging and often very

26

subject-specific. Students instead need to be equipped with the basic skills for solving specific

27

problems, thus becoming self-taught in order to progress (like any foreign language, it is a real

28

example of the concept of practise-makes-perfect). This does not, however, mean that basic
4

programming and computer languages cannot be introduced using formal teaching methods often

students simply require background theory and step-by-step demonstrations to get started. However,

this must be taught effectively using appropriate pedagogic techniques and using real-world

examples and analogies that are familiar to them. Computer Science Education (CSE) research has

found that effective methods for teaching programming include the use of program plans (Soloway,

1985), implementation-independent pedagogic approaches (Ford, 1994), team working (Robins et al.,

2003), mathematical constructs (Elenbogen & OKennon, 1988) and sophisticated educational

software (Holmboe et al., 2001). However there must also be a realistic assessment of what is

possible and what is desirable (Reeve, 1985).

10
11

Since computing and command-driven, or command-supplemented, software packages (e.g. some

12

statistical packages, GIS software) now represent an important component of most geographical

13

degrees (QAA, 2007) and related careers, this paper outlines a strategy for improving the delivery of

14

an introductory module in computer programming and data analysis to masters-level meteorology

15

students in a UK geography department. This enables them to have sufficient experience of coding in

16

order to process and analyse data sets to at least a basic level.

17
18

The second Author of this paper initially designed and ran the module for several years, whilst the

19

first Author now teaches the module; she was also a former student on the Masters course and

20

therefore has used her first-hand experience of the module as a student, along with feedback from

21

other students from previous years, to incorporate some of the outlined improvements. The module is

22

taught as part of an Applied Meteorology and Climatology (AMC) masters course that draws the

23

majority of the students from a geography background, although each year there are a number sourced

24

from other non-computer-science fields, such as environmental science, maths and physics. The

25

techniques implemented here could potentially be altered and applied to other geographical and

26

environmental subjects, or other undergraduate courses. A range of operating systems, open-source,

27

free-licence software is also utilised where possible, allowing students to download software in order

28

to permit independent learning and practice during upon completion of the introductory module.
5

Student evaluation from the current module is also presented and analysed to illustrate the

improvements made.

3
4

2. Module Design

5
6

This section provides an overview of the module design and pedagogy. The AMC masters course

covers a number of modules designed to benefit those entering the fields of meteorology and/or

climatology field. The programming and coding element of this course have been designed to

complement other AMC modules for example, the statistics and analysis techniques that are

10

incorporated into the programming module are based on what theory the students are taught as part of

11

the Statistics module, whilst the exercises are put into context by relating them to the Atmospheric

12

Physics and Dynamics module. Furthermore, FORTRAN (FORmula TRANslation) is still the main

13

language used for meteorological and climatological modelling, and thus this aspect complements the

14

Climate Modelling module. As noted by Pears et al. (2007), course design and content are often

15

influenced by the history and culture of a department and the needs of prospective employers

16

(Extrinsic Criteria). The specific elements included within this module are therefore included for a

17

number of reasons:

18
19
20

21
22
23

The introduction and theory endeavours to bring all students up to the same level;
HTML (Hypertext Mark-up Language) is a simple, easy and familiar language which allows
students to gain confidence with computer-interpreted code;

Linux environment is used since it is common-place within the field;

FORTRAN is still widely used for meteorological and climatological modelling, and it is essential

24

that students are taught FORTRAN programming since it is a pre-requisite for many meteorology

25

jobs, PhDs and post-doctoral positions;

R is free data analysis software similar to MATLAB and IDL which are other standard analyses

packages allowing students to visualise data that has been processed or produced using

FORTRAN (which may occur in a real research job).

4
5

It must be noted that the module is not intended to deliver broad, expert computer programmers in the

time-frame of such a short module - indeed, expert programmers usually have several years of

experience (Winslow, 1996) - but rather an advanced beginner (Dreyfus and Dreyfus, 1986). It is a

bespoke module, designed with the course objectives in mind: to impart knowledge about the subject

(within the context of the meteorology and climatology course) and to train the students to a specific

10

level with the relevant skills required to pursue a career in the atmospheric sciences. However, this

11

module could easily be adjusted and used as a foundation for other geography-related courses (e.g.

12

geology, air pollution, hydroecology).

13
14

The module consists of 20 hours of formal lectures and practical workshops, plus additional non-

15

contact self-learning from each student. During each lesson example programs are demonstrated,

16

discussed and practiced interactively, before the students are given a number of exercises to allow

17

them to implement and practise what they have learnt, under the guidance of the lecturer and a class

18

demonstrator (usually a PhD student). The students are also able to liaise with the module leader for

19

assistance and explanations, both via email and in person. Table 1 gives a breakdown of the current

20

module for each session a number of resources are suggested (e.g. online material, sites, tutorials,

21

guides and useful library books) along with a breakdown of the learning objectives and what is

22

expected from the students that session. The module is assessed by four continuous worksheets

23

(worth 50%), which are set at various stages, and a final exam (worth 50%). The latter is an open

24

book exam that replicates reality where programmers consult books, online forums and guides in

25

order to assist with their coding, therefore there is no expectation for the students to memorise

26

everything, emphasis is placed on understanding how to use what they have learnt.

27

modifications to the module include incorporating R, adding in a dedicated session on Unix/Linux and

Recent

improving the methods used to explain specific concepts (e.g. through the use of diagrams,

visualisations and familiar, real-life concepts).

3
4

Another important aspect - and recent addition - is to provide feed-forward prior to the

dissemination of each coursework assignment, where students were advised on issues arising in

previous years in order to help them avoid similar mistakes (Sadler, 1998; Whitfield et al., 2009).

Feedback and example answers are also provided after the coursework is marked. Timeliness of

feedback is also important all worksheets are returned by the next class to ensure any problems are

rectified prior to proceeding onto the next topic. The first session includes an overview of the whole

10

module, including module description, key learning outcomes, the elements covered and the

11

organisation of the assessments, so that the students are aware of what material is to be covered each

12

week (Biggs & Tang, 2011).

13
14

2.1. Introducing Programming and Coding Using HTML

15
16

It is imperative that students, many of whom will have not thought about computers in this way since

17

school, are brought gently up-to-speed with computing basics. If this is not adequately achieved,

18

students may feel frustrated and disengaged from the outset. During the introductory session, an

19

engaging YouTube video [http://www.youtube.com/watch?v=nKIu9yen5nc&sns=em] is shown,

20

which contains well-known programmers (e.g. Bill Gates, Mark Zuckerberg) and other less-

21

obvious code-enthusiasts (e.g. sports personalities, musicians) explaining how they got into

22

programming and why it is important. Basic computing concepts are introduced to gently boost

23

learners confidence (Reeve, 1985), for example the structure of a computer, what programming is

24

and why we use it, basic terminology (e.g. bits, bytes, wordsize) and how computer memory works,

25

including an overview of data units (e.g. binary, hexadecimal systems). It is important that students

26

understand these basic concepts, since it will help them fully understand many of the aspects of

27

programming, such as memory, storage, etc.

28
8

One very successful way to introduce computer-speak to non-computer scientists is to start with

HTML, as web pages are readily accessible and HTML is an easy language to learn. Although not

programming per se, it is a simple way for students to gain confidence at the start of the module by

showing how simple code can be interpreted by the computer.

module in 2006, and has remained part of the introductory lecture due to receiving positive student

feedback. By creating web pages using HTML, the students begin to think in computer terms,

structure material and start to understand how code can be used to produce a desired result. Following

introduction and demonstration of how to use HTML (Table 1), students are given the opportunity to

produce some web pages, either personal or subject-related (which many subsequently go onto

10

This was first introduced to the

develop further).

11
12

2.2. Computer Platforms and Operating Systems

13
14

The majority of students will only have had access to PCs/Laptops and Windows OS (and in some

15

cases, Apple Macs) up to this point. The concept of different platforms, such as Unix and Linux, will

16

often be very new. It is important for students - especially those who progress towards a career in

17

programming - to be aware and have some experience in using a command-line OS, since most

18

programming is conducted on these types of OS. Furthermore, it shows students that computers wait

19

to be 'told' what to do next and it is the critical-level for dealing efficiently with problems,

20

copying/moving files, etc. It is worth noting that a point-and-click FORTRAN compiler within a

21

windows environment was previously used, but problems with this software/platform impacted

22

student confidence. Importantly, students still needed to know how to generate lists of files, merge

23

files etc. - something far more achievable with the command-line interface. The use of X-windows

24

software on PC-based systems to access remote Linux/Unix hosts is also akin to a real-world

25

research environment.

26
27

In order to provide students with some practice in using command-line OS, one whole lesson is

28

focussed on Unix/Linux, along with FTP, networking and x-windows environments (Table 1).
9

Previous feedback indicated that if this teaching is done parallel to FORTRAN, confusion can result

since students feel they are learning two completely new things at once (e.g. some students try to

incorporate Linux commands into the FORTRAN program and vice versa). Therefore spending

practical time focused on familiarising themselves with the Linux environment and Linux commands

is critical prior to learning the programming language itself. This provides a foundation and makes the

students learning and understanding of programming in subsequent sessions more straightforward

thus after this session, focus is primarily on teaching the programming language, not how to use the

new OS.

9
10

2.3. FORTRAN

11
12

FORTRAN is the high-level language that is taught on this module. The advantages of FORTRAN

13

are that it is easy to learn (essentially only two command structures - the 'do loop' and the 'if'

14

statements in FORTRAN 77), can be easy obtained with the GNU license, interfaces with other

15

software (FORTRAN can call C-routines - and vice versa), is relatively easy to learn since it uses

16

familiar English terms (e.g. for, if, then, else, do) which aids learning and helps in detection of

17

erroneous coding, and is faster when compiled than many other languages. But perhaps more

18

importantly for the AMC course, FORTRAN is still the standard choice of language (e.g.

19

Easterbrook, 2012) in the field of meteorology and climatology (e.g. for computer modelling and

20

processing large data sets). Therefore knowledge and experience of the language is essential for

21

anyone

22

http://gcc.gnu.org/wiki/GFortranStandards) is used to explain some fundamental program structures

23

and why we do certain things (e.g. explicit declaration vs. implicit types) that are not necessarily

24

required in future versions. However, this work could easily be modified for FORTRAN 90/95

25

(ISO/IEC 1539:1991 and ISO/IEC 1539-1:2010; http://gcc.gnu.org/wiki/GFortranStandards) or

26

indeed, other computer languages (e.g. JAVA, C++).

aspiring

to

enter

this

field.

Specifically,

FORTRAN

77

(ISO

1539:1980;

27

10

FORTRAN is taught using a central, networked-Linux machine which the students access from a PC

(using Open-Text - formerly Hummingbird - Exceed software; http://connectivity.opentext.com/), but

Linux OS or Unix machines could also be used directly, where available. A syntax-highlighting tool

Gedit is used to type in the FORTRAN code. Since the best way to progress with any language is

consistent use and practise, options are also provided for practising code off-campus using windows-

based compilers (Silverfrost Plato) that students can download free of charge to their personal

computers.

8
9

It is important not to rush through these fundamental elements of programming, since any

10

misunderstandings that occur at this stage may have detrimental impacts later on this is particularly

11

important for students who have no previous experience of programming, as it will be completely new

12

to them and as such, is a very steep learning curve. The five programming domains (orientation,

13

notional machine, notation, structures and pragmatics) introduced by Boulay (1989) were used to

14

inform the module design. Table 1 provides specific details of what is covered. As part of this

15

module, students are given the opportunity to work in pairs to role-play and talk through the

16

processes and stages of a program with one another to see the kind of steps used by a program from

17

start to end (i.e. one student gives the second student a value and the second students has to convert

18

that value using a simple equation and provide the output value to the first student). Flow-diagrams

19

are produced by hand, again in pairs, for specific tasks, in order to demonstrate the need for structure

20

in program development. This is not officially pair programming per se (Wray, 2010; Sheard et al.,

21

2009; Braught et al., 2008; Hanks et al., 2006; Mendes et al., 2006) since the students produce

22

independent code, but is similarly a useful and mutually-beneficial learning technique, which for

23

students who have never written any kind of code, is an excellent way to walk though problems

24

step-by-step. Indeed, many of the students use this method throughout the module and beyond in

25

order to understand problems and work out structured solutions. By working informally in pairs or

26

groups (as encouraged throughout the module) students discuss and identify issues, and observe,

27

review and debug each others programs using informal code walkthrough techniques (McKenney,

28

2011) to locate errors.

11

1
2

Figure 1 shows an example of the algorithm development for one of these tasks it is important that

the tasks are familiar to the students, so in this case, students were asked to first produce a

methodology for converting temperatures from Fahrenheit into Celsius, and then between Celsius,

Fahrenheit and Kelvin depending on what the input is. This is a very simple, yet important way of

getting students thinking of how problems are solved and the stages that need to be carried out in

order to reach an answer. Logical progression through a problem is a key element of programming,

so it is essential that it is broken down into its constituent elements. One way students are asked to

approach programming is to consider how they would view a cake recipe or flat-pack furniture

10

instructions the various stages of the recipe or instructions need to be carried out in the correct order

11

to produce the desirable result.

12
13

After producing the customary Hello world program, students then take the methodology they

14

composed earlier by hand and turn them into successful FORTRAN programs. Various text files

15

containing time-series meteorological data (see Table 1 for details of data files) are also processed by

16

applying the theory and programming learnt in previous lessons to a number of exercises which link

17

with other course modules (e.g. Statistics, Mathematics, Atmospheric Physics and Dynamics). For

18

example, a bubble sort algorithm (Knuth, 1997) is applied to a simple hourly temperature dataset in

19

order to rank the data in descending order and to subsequently calculate a range of statistics (e.g. min,

20

median, max, range, quartiles, percentiles).

21
22

Advanced concepts are examined later in the module, including arrays and subroutines. Arrays can be

23

quite a complex subject to grasp for those new to programming, therefore the concept of 1, 2, 3+

24

dimensional arrays are introduced once the students are comfortable with writing code and processing

25

data. In order to visualise the organisation of the data up to 3D-arrays, a number of diagrams are

26

used (e.g. Figure 2) along with a Rubix cube which is handed out as a visual, tactile aid to help

27

explain how the data is stored and accessed using three do-loops. Finally, students are asked to

28

modify programs they have previously developed to incorporate sub-routines. Once all elements of
12

the module are formally covered, there is a session dedicated to reviewing and revising previous

topics to assist with bringing all students up to the same level of understanding and to prepare them

for their third coursework assignment which involves creating complex programs. By the end of the

module each student should have sufficient knowledge and understanding of FORTRAN and

programming in order to extract, collate and process data in an organised manner, in addition to the

necessary tools and understanding to independently progress with programming.

7
8

2.4. Data analyses in R

9
10

Prior to the introduction of the revised module, students were taught how to visualise and plot data

11

using FORTRAN and UNIRAS subroutines. However, feedback from students indicated that this is

12

quite challenging to learn and apply in the time allocated, resulting in significant frustration.

13

Moreover, this is now less frequently used as the standard method to analyse data and produce

14

graphics (FORTRAN is mostly used in modelling and processing large datasets) more often,

15

command-line, visualisation packages, such as MATLAB, IDL and R are used to analyse and

16

graphically display data. Having an initial understanding of programming prior to learning such

17

analyses packages also assists with understanding of the coding that goes into the specific functions

18

used within these packages, and as a result, students often grasp R quickly. Therefore, over the final

19

three sessions of the module the command-line, code-driven data analysis package, R, is introduced.

20

This is valuable to the student in the short-term, since many progress to use this package as part of

21

their dissertation as it is relatively easy to learn. Furthermore, R is free to download therefore

22

students are able to install the software on their personal computers. RStudio (2011) is the integrated

23

development environment (IDE) chosen for learning R, due to its user-friendly interface (Torfs &

24

Brauer, 2012; Figure 3). Since it is an increasingly popular piece of software, there are many online

25

tutorials, help guides, code and packages that can be downloaded, providing considerable support

26

during the learning process. R was chosen over others such as MATLAB or IDL, since these software

27

packages have expensive licenses and there is a growing demand for training in such open source

28

software. Furthermore, students that are required to use similar packages such as MATLAB in the
13

future, find these easy to learn once they have experienced R (Note: there are numerous books

available explaining how code can be transferred from one language to the other). R also has a large

and growing community of scientists and researchers who contribute to its development, there is a lot

of readily available support for beginners online and it allows for professional-looking, publication-

ready plots and graphics to be produced with ease, (also R handles dates and times with ease, unlike,

for example, Excel). After just 6-hours of practical lessons, students with no prior knowledge of R

leave with an understanding of R data structures, reading in/writing out data, producing plots,

conducting statistics and performing spatial analyses (Table 1). By linking the R lessons to the

statistics theory which is taught on the AMC course prior to this module, the students gain a better

10

understanding of how to apply such analysis techniques using a coding environment. Meanwhile,

11

data which is familiar to the students (e.g. meteorological and atmospheric data sets - see Table 1) are

12

processed using FORTRAN are subsequently analysed in R, as may be required in reality. The wide-

13

range of activities incorporated provide a broad overview of R sufficient to build on for coursework

14

and dissertation projects.

15
16

3. Evaluation

17
18

In order to assess how successful new teaching strategies have been, data from two key indices,

19

student evaluation and overall module results, are often examined. Although the students results

20

have generally improved over the years, significant alterations have been made to the module over

21

time (e.g. different lecturers, module structure and content). Furthermore, the AMC course attracts a

22

very diverse group of students; although geography graduates comprise the single largest group each

23

year (e.g. 81% of the cohort in 2010-11; 38% in 2011-12; 69% in 2012-13; Figure 4), the numbers

24

with geography, environmental science, mathematics and physics backgrounds do vary each year.

25

Therefore it would not be a fair comparison to use the module results. From a teaching and learning

26

point of view, the educator is also more interested in the feedback provided by students in order to

27

improve the module and teaching methods.

Therefore, only data from the student evaluation

14

questionnaires, which are completed at the end of the module, are examined for assessing the module

design and pedagogy. These formal evaluations have been implemented and developed by pedagogic

experts within the school the main questions are based around:

4
5
6
7
8
9
10

Understanding of the module

Structure of the module
Learning materials and resources
Module organisation
How inspirational and/or intellectually stimulating the module is
Staff availability

11
12

The response rate to the evaluations is consistently high over the observed years, varying by just 4.3%

13

over the whole period, from 91.7% in 2006/07 to 96% in 2011/12. Figure 5 shows a bar chart of the

14

mean student evaluation scores from six academic years covering the period 2006 to 2013. Module

15

changes include the addition of HTML in 2006, whilst in 2011 a new lecturer took control of the

16

module, adding in a focused Unix/Linux session, modified pedagogic techniques and visualisation

17

methods for explaining complex programming concepts, and the R component. As evident, student

18

evaluation scores have varied over this time period, with changes relating to the introduction of new

19

components clearly visible in Figure 5. The mean evaluation score increased after HTML was added

20

to the module in 2006 (post-HTML), and then increased further after the addition of the new

21

lecturer plus associated module changes (e.g. addition of R, different pedagogic techniques) in 2011

22

(post-R). Furthermore, the standard deviation of the evaluation scores decreased indicating that the

23

general view of the module by all students has been consistent over the past two years, despite

24

changing student demographics (Figure 4). Indeed, there were (unusually) more non-geographers in

25

2011/12 (54%), but both 2010/11 and 2012/13 had more far more geographers (80% and 69%,

26

respectively) yet there were divergent evaluation scores in 2010/11 and 2012/13 (3.2 and 4.5,

27

respectively), thus supporting the view that changes to module content, design and delivery have had

15

more influence on evaluation scores over this time period than changing student demographics, and

thus student abilities, each year. In particular, this may be due to ensuring that students of all abilities

are engaged in the subject and focusing on explaining basic-yet-complex topics more thoroughly to

students, particularly those who struggle early on. At the same time, it is important to continue to

stretch those of a higher-ability.

6
7

In order to explore this further, the data for commonly asked questions are shown in Figure 6 for each

year (where available). It is evident that there has been a consistently high view of all aspects of the

module over the past two years. By looking further at module scores from previous years - which

10

were used to make the changes, as outlined in Section 2 - it can be seen that the organisation and

11

structure of module and the learning materials were viewed less-favourably in some years. The

12

exception was 2008-09, where scores were more consistently high without data on demographics

13

and detailed qualitative comments (unavailable for this year) however, it is not possible to ascertain

14

the precise reason why evaluation scores were high for this year in particular.

15
16

We can investigate these trends in more detail by analysing the qualitative freeform comments

17

provided by students (available for 2010-2013). Hazzan et al. (2006) suggested that quantitative

18

research is used for determining whether something is so, whilst qualitative research is to determine

19

why it is so (Sheard et al., 2009). The nature of the student comments have varied over the years and

20

have been instrumental in directing the alterations that have been made over the years. For example,

21

in 2010-11 and subsequent years, the methods of assessment were praised and these have remained

22

the same over the years, as was the HTML that was introduced in previous years, e.g.:

23
24

Methods of assessment well chosen (2010-11)

25

[Best aspect was] learning HTML (2011-12)

26
27

Whilst overall, the feedback on the knowledge, helpfulness and enthusiasm of the lecturing staff has

28

remained consistently high over the years:

16

1
2

Excellent teaching in class (2010-11)

Very good lecturing style made a hard subject far more manageable (2012-13)

4
5

However there were a number of requests in 2010-11 for more time of difficult aspects of the module

and more feedback, e.g.:

7
8

Spend more time on harder aspects of the module.

More detailed explanation of difficult concepts and explain how your [programs] have been

10

produced in more detail.

11

More helpful feedback [needed].

12
13

Whilst for 2011-2013, there were more positive comments about the module structure and

14

reorganisation, reflecting the changes that had been implemented (as outlined above), e.g.:

15
16

Completely new material eased in gently.(2011-12)

17

[The best aspect was] the breadth of packages/systems introduced. (2011-12)

18

There was enough time. (2011-12)

19

Simple and not over-complicated.(2012-13)

20
21

Furthermore, the R component that was added in 2011, has been particularly well received:

22
23

R is fun!(2011-12)

24

More R!(2012-13)

25
26

In general, there was an increase in the number and range of positive comments (e.g. Never though

27

programming would be so good!, 2012-13) as well as an increase in the evaluation scores, providing

28

an indication that students are engaged with the current format of the module. For example, many of
17

these students go on to use R as part of their dissertation, providing further evidence in support of

incorporating this particular topic. Therefore, from the data it is possible to conclude that on the

whole, students are happy with the current structure, content and delivery of module. The module

will continue to be improved and updated based on student suggestions and recommendations each

year for example, in 2011-12, a number of students requested to receive the handouts before the

lecture, and this was successfully incorporated the following year, whilst in 2012-13 there was a

request for some advanced exercises for more able students, which will be acknowledged in the next

delivery of the module. Furthermore the course will be adapted to incorporate new technologies,

software and techniques as appropriate, for example more formal inclusion of programming pedagogy

10

(e.g. code walkthroughs, pair programming) and other technologies (e.g. use of Raspberry Pi) could

11

be built into the current module to improve it further.

12
13

4. Summary and Future

14
15

This article provides an example of how the complex subject of programming has been successfully

16

taught to non-computer scientists within a UK university geography department. The languages, data

17

and analyses incorporated are specific to the AMC Masters course to improve subject-familiarity;

18

however these methods could easily be applied to other subjects. The approaches used have been

19

developed and updated based on student feedback and incorporate a range of pedagogic techniques

20

following the principle of constructive alignment (e.g. interactive lectures, computer-based activities

21

and assessments, team working and collaboration, problem solving, troubleshooting, applying

22

knowledge; Biggs and Tang, 20011; Biggs, 2003; Robins et al., 2003; Bloom, 1956) to avoid

23

alienating students who may struggle, whilst still keeping those of a higher-ability engaged (e.g.

24

Robins et al., 2003). Furthermore, the introduction of a new lecturer appeared to reinvigorate the

25

module as new pedagogical constructs were introduced (Fanghanel, 2007). Indeed, the first Author,

26

and current lecturer, had previously taken this course as a student and therefore had first-hand

27

knowledge of being on the other side of the teaching-learning experience. This was extremely

28

beneficial for assisting with module design, and could easily be applied to other courses. For
18

example, if previous students were approached as consultants to expand on any comments and

suggestions given on evaluation forms, additional modules could be improved in this manner.

3
4

Many university courses now contain programming modules, yet with a large number of students

leaving school with little knowledge of computers and programming, it is increasingly important that

these subjects are taught in the correct manner to avoid disengagement with the subject.

Furthermore, touch-screen technology is being incorporated into an increasing number of devices;

whilst this is making technology more accessible and user-friendly, there is potential for future

generations to become increasingly distanced from computing fundamentals. However, the outlook

10

does look promising. Following changes to the school ICT curriculum in various countries worldwide

11

(e.g. US: CSTA, 2005; Germany: Dagiene et al., 2013), recent reports (e.g. The Royal Society, 2012)

12

and articles in the national press have highlighted these issues in the UK, with new proposals for

13

traditional ICT lessons to be overhauled. As in other countries, there are now plans to revert back to

14

more computer science orientated lessons in the UK, covering computer theory and programming

15

basics (Vasagar, 2012). Indeed, as of September 2012 schools are being encouraged to include more

16

computer science lessons (The Royal Society, 2012). These changes recognise the lack of a basic

17

understanding of how computers actually work in current generations, perhaps brought-about by

18

modern computing systems. As mentioned earlier, it is hoped that with the proposed changes to

19

school ICT curriculum, and with educational developments and incorporation of innovative hardware

20

(e.g. the Raspberry Pi, Arduino, ScratchBoards) and programming languages and software designed

21

specifically for educational purposes (e.g. Scratch, Kodu, Python; The Open universitys Sense

22

software) , more learners will become engaged with computing at an early stage (The Royal Society,

23

2012; Wakefield & Rich, 2013; Dagiene et al., 2013).

24

understanding increases in future generations, the subject will become less-daunting and university-

25

level modules, even those aimed at students without a formal computer science background, can

26

evolve from a beginners level to a more intermediate level.

As basic computer knowledge and

27
28
19

Acknowledgements

The first Author is funded on a NERC-research grant (NE/O006915/1) whilst the second Author is

funded by the University of Maryland and NASA. The Authors would like to thank Dr Lee

Chapman for providing useful feedback during the preparation of this paper, as well as the five

anonymous reviewers - their feedback has been incorporated within this manuscript.

6
7

References

Barnett and Windley (1993) Dysfunctional Programming: Teaching Programming using Formal

9
10
11

Methods to Non-Computer Science Majors [www]

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2694 (Accessed August 2012)
Biggs, J. (2003) Aligning teaching for constructing learning [www]

12

http://www.heacademy.ac.uk/assets/documents/resources/database/id477_aligning_teaching_f

13

or_constructing_learning.pdf (Accessed April 2013)

14
15
16
17
18
19
20

Biggs, J. and Tang C. (2011): Teaching for Quality Learning at University, (McGraw-Hill and Open
University Press, Maidenhead)
Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain. New
York: David McKay Co Inc.
Bradbeer, J. (1999) Barriers to interdisciplinarity: disciplinary discourses and student learning,
Journal of Geography in Higher Education, 23, 381396
Braught, G., Eby, L. M. and Wahls, T. (2008) The effects of pairprogramming on individual

21

programming skill, 39th SIGCSE Technical Symposium on Computer Science Education,

22

Portland, OR, USA, 200-204

23
24
25

Chapman, L. (2012) Dealing with Maths Anxiety: How Do You Teach Mathematics in a Geography
Department? Journal of Geography in Higher Education, vol. 34(2), p. 205-213
CSTA (2005) The New Educational Imperative: Improving High School Computer Science

26

Education, Final Report of the CSTA, Curriculum Improvement Task Force,

27

February 2005 [www]

20

http://csta.acm.org/Communications/sub/DocsPresentationFiles/White_Paper07_06.pdf

(Accessed January 2013)

Dagiene, V., Jevsikova, T., Schulte, C., Sentance, S. and Thota, N. (2013) A comparison of current

trends within Computer Science teaching in school in Germany and the UK, Informatics in

Schools: Local Proceedings of the 6th International Conference ISSEP 2013Selected Papers

[www] http://opus.kobv.de/ubp/volltexte/2013/6450/pdf/63_75_dagiene_etal.pdf (Accessed

July 2013)

8
9
10
11
12

Dehnadi, S. & Bornat, R. (2006) The camel has two humps (working title) [www]
http://www.cs.kent.ac.uk/dept_info/seminars/2005_06/paper1.pdf (Accessed December 2012)
Dreyfus, H. and Dreyfus, S. (1986). Mind over machine: The power of human intuition and expertise
in the era of the computer, New York: Free Press
Easterbrook, S. (2010) What makes software engineering for climate models different? [www]

13

http://www.easterbrook.ca/steve/2010/03/what-makes-software-engineering-for-climate-

14

models-different/ (Accessed July 2013)

15

Elenbogen, B.S. & Kennon, M. R. (1988) Teaching recursion using fractals in Prolog.

16

Proceedings of the 19st SIGCSE Technical Symposium on Computer Science Education,

17

20(1), 263-266

18

Fanghanel, J. (2007) Investigating university lecturers pedagogical constructs in the working context

19

[www] http://www.heacademy.ac.uk/assets/documents/research/fanghanel.pdf (Accessed

20

January 2012)

21

Ford, G. (1984). An implementation-independent approach to teaching recursion. ACM SIGCSE

22

Bulletin - Proceedings of the 15th SIGCSE technical symposium on Computer science

23

education, 16(1), 213-216

24
25
26

Hanks, B. (2006) Student attitudes toward pair programming, 11th Conference on Innovation and
Technology in Computer Science Education, Bologna, Italy, 113-117.
Hazzan, O., Dubinsky, Y., Eidelman, L., Sakhnini, V., and Teif, M. (2006) Qualitative research in

27

computer science education, 37th SIGCSE Technical Symposium on Computer Science

28

Education, Houston, TX, USA, 2006, pp. 408-412.

21

Holmboe, C., McIver, L., & George, C. (2001) Research Agenda for Computer Science

Education, 13th Workshop of the Psychology of Programming Interest Group, Bournemouth,

UK, April 2001

4
5
6
7
8
9
10

Knuth, D. (1997) The Art of Computer Programming, Volume 3: Sorting and Searching, Third
Edition. Addison-Wesley, ISBN 0-201-89685-0, 106110
Kortuem, G., Bandara, A., Smith, N., Richards, M. & Petre, M. (2013). Educating
the Internet-of-Things generation. Computer, 46(2), 5361.
Laurillard, D. (1993). Rethinking University Teaching: a framework for the effective use of
educational technology. London: Routledge.
Mendes, E., Al-Fakhri, L., and Luxton-Reilly, A. (2006) A replicated experiment of pair-

11

programming in a 2nd-year software development and design computer science course, 11th

12

Conference on Innovation and Technology in Computer Science Education, Bologna, Italy,

13

108-112.

14
15
16

Merali, Z. (2010) Error...why scientific programming does not computer, Nature, vol. 467, p. 775777
McKenney, P.E. (2011) Is Parallel Programming Hard, And, If So, What Can You Do

17

About It? [www]

18

https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2011.08.28a.pdf

19

(accessed July 2013)

20
21
22

Nulty, D. D. & Barrett, M. A. (1996) Transitions in students learning styles, Studies in Higher
Education, 21, pp. 333345.
Pears, A., Seidman, S., Malmi, L., Mannila, L., Adams, E., Bennedsen, J., Devlin, M.

23

and Paterson, J. (2007). A survey of literature on the teaching of introductory programming.

24

SIGCSE Bulletin, 39(4), 204223.

25

QAA (2007) Subject benchmark statements: Geography. [www]

26

http://www.qaa.ac.uk/Publications/InformationAndGuidance/Documents/geography.pdf

27

(accessed Feb 2013)

28

Rees, P. H. (1987) Teaching computer skills to geography students, Journal of Geography in Higher
22

1
2
3
4
5
6
7
8
9
10

Education, 11(2), 99-111

Reeve, D. E. (1985) Computing in the geography degree: limitations and objective, Journal of
Geography in Higher Education, 9(1), 37-44
Robins, A., Rountree, J., & Rountree, N. (2003). Learning and teaching programming: A review and
discussion. Computer Science Education, 13(2), 137172.
RStudio (2011). RStudio: Integrated development environment for R [Computer
software]. Boston, MA. [www] http://www.rstudio.org/
Sadler, D.R. (1998) Formative Assessment: Revisiting the territory. Assessment in Education. 5(1),
77-84
Sheard, J., Simon, M. Hamilton, and J. Lnnberg, Analysis of research into the teaching and learning

11

of programming. Proceedings of International Workshop on Computing Education (ICER

12

2009), Berkeley, California, USA, 2009, 93-104.

13
14
15
16
17
18
19

Slocum, T.A. & Yoder, S.C (1996) Using Visual Basic to Teach Programming for Geographers,
Journal of Geography, 95(5), 194-199
Soloway, E. (1985). From problems to programs via plans: the content and structure of knowledge for
introductory LISP programming. Journal of Educational Computing Research, 1, 157-172.
Swan (2012) Sensor Mania! The Internet of Things, Wearable Computing, Objective Metrics, and the
Quantified Self 2.0, J. Sens. Actuator Netw. 1, 217-253
The Royal Society (2012) Shut down or restart? The way forward for computing in UK schools

20

[www]

21

http://royalsociety.org/uploadedFiles/Royal_Society_Content/education/policy/computing-in-

22

schools/2012-01-12-Computing-in-Schools.pdf (Accessed January 2013)

23

Torfs, B. & Brauer, C. (2012) A (very) short introduction to R [www]

24

http://cran.r-project.org/doc/contrib/Torfs+Brauer-Short-R-Intro.pdf (accessed February

25

2013)

26

Vasagar, J. (2012) Michael Gove to scrap boring IT lessons [www]

27

http://www.guardian.co.uk/politics/2012/jan/11/michael-gove-boring-it-lessons (accessed

28

January 2012)

23

1
2
3

Wakefield, J. & Rich, L.J. (2013) Google to give schools Raspberry Pi microcomputers [www]
http://www.bbc.co.uk/news/technology-21243825 (accessed January 2013)
Whitfield, A., ODoherty, M., Mony, A., Hetherington, R. (2008) Write it Right: Developing

academic writing within the discipline of computing using feedforward feedback, 9th Annual

Conference of the Subject Centre for Information and Computer Sciences, 26th 28th

August, Liverpool

7
8
9

Winslow, L.E. (1996) Programming pedagogy A psychological overview, SIGCSE Bulletin, 28, 1722
Wray, S. (2010) How Pair Programming Really Works, IEEE Software, 27 (1), 50-55

10

24

Tables

2
3
4

Table 1: Module overview (Approximately 2 hours per session although this can be flexible
depending on how capable the student group is i.e. certain sessions may take more time, therefore
may extend into the following session).
Session

Lesson

Datasets

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
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
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
FORTRAN Basics 2:
Program structures
Data types (real, integer, character)
Variables (implicit and explicit)
decisions (if-then-else-endif, regional operators)
loops (do-enddo)]
FORTRAN Basics 3:
Handling data files - using real and familiar data files
(input/output).

N/A (but students can source their

own data/images to include in their
webpage

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).

FORTRAN recap/revision

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.
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.

10

R Basics 3

Coursework

Students create their own sample

file using Gedit to test FTP

Worksheet 1a:
Linux
directories

N/A

Worksheet 1b:
Variables and
simple
programs

N/A

Worksheet 2:
Assignments &
Algebra,
Formatted I/O,
decisions and
loops

Various simple text files containing

data (e.g. hourly temperatures,
daily minimum and maximum
temperatures)
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

N/A

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)
A netCDF file of hourly air

Worksheet 4:
Analysing and
visualising
data using R

25

11

Exploring a spatial dataset of modelled air temperatures

Complex dara sets: NetCDF files
Plotting and analysing spatial data.
1.5 hour open-book exam

temperatures for a range of

latitude and longitudes over four
summer months in 2006
N/A

1
2

26

Figures

3
4

Figure 1: Example flow chart showing the algorithm for converting between temperatures

27

1
2

Figure 2: 3D array diagram and rubix cube visualisation

3
4

Figure 3: The editor, workspace, console and plots windows in RStudio.

28

1
2

Figure 4: Student demographics by year [(2010-11 (13 students in total)); 2011-12 (25 students);

2012-13(16 students)]

29

1
2

Figure 5: Bar chart showing the mean overall evaluation score with standard deviation whiskers

[2006-07 (12 students); 2008-09 (13 students); 2009-10 (21 students); 2010-11 (13 students); 2011-12

(25 students); 2012-13 (16 students). See main text for response rate.]. 0 = poor (strongly disagree

with questions) 5 = excellent (strongly agree with questions). Grey-scale indicates the years when

specific changes were introduced to the basic course (NOTE: Evaluation unavailable for 2007-08

academic year; standard deviation unavailable prior to 2009).

30

1
2

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

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

year).

31