I started teaching at the University of Winchester in September. I teach an introductory module about cyber security and how to design secure systems. My expectation was that students were rather technical (being in a BSc Cyber Security track) and have a good understanding of how computers generally work, what programming languages are and know some very basic programming. It's a second year module after all.
To my surprise there wasn't much programming they did in their first year. That's fine, I was prepared for this possiblitiy. I started with very basics... how to open a terminal or powershell, type commands, etc.
Then we got to some coding in python. Here's something interesting that I found out and I think many people get confused when they start learning to code. I'm describing a few things people seem to get wrong when they start learning to code or learn how computers work in general. For this I mainly blame many online tutorials claiming coding is easy and the type of teaching to code that doesn't require users to manually compile and run their code.
Most of my students use Windows, this is where this section is coming from. The same filesystem thing happens on Mac I believe, I just don't have enough Mac user students to tell if it's the same thing. When you don't program and are using your computer for very simple things like email, browsing the web, writing some documents and maybe some gaming you don't really need to understand files. I mean it. You open Word and all your Word documents (files) are somewhere in Documents/. You don't need to know Documents/ is a folder on your computer (you may know that, but you don't need to know it's in C:\Users\<your-username>\Documents or wherever it might be). Or that Word saves .docx files. Windows is even kind enough to hide all extensions for you by default.
So I'd say averate computer users are very confused when they have to navigate the filesystem without using their favourite programs/apps.
This has a lot of implications:
- you can't possibly understand what things like Dropbox do exactly,
- you don't really know where your things are in your computer but you may have ways to get to them,
- you make a strong connection between the program/app that you use and the things you save with it (Word and word files, but you could really edit Word files with other programs [like LibreOffice Documents] if you wanted to).
- in your mind, maybe Word files are something only Word manages and you can't really do anything with them outside of the world of Word.
Maybe I'm taking this a bit too far. Some users understand those things more than others, but let's just go with this assumption.
It's hard to the understand why text files are different than Word files. They look similar, and in fact you might be able to open text files with Word. Text files just look boring, have no formatting options and so on. Text files are something Notepad opens.
The real thing about plain text files is that what you see in Notepad is what is actually stored on disk (let's ignore bytes and character encodings for now). What you see in Word is not quite what's saved on disk, because Word needs to save all the things about the presentation of the text (like fonts used, text size, and so on). The .docx file format has ways to arrange all those things, as well as the text content, into a .docx file (which you could open with Notepad, it just won't look like the Word document).
What's a file? In the most simple definition, a file is simply a list of bytes stored on disk.
What's a filesystem? A way to store files on disk. It goes a little deeper than that but effectively it lets you (and your operating system) save/read/edit/delete files on your computer and organise them (put them in folders and give them names).
Internally there's a lot more going on and there are many file systems out there. Not important for this post.
In Windows you mount drives, CDs, USB sticks and so on as letters (A, B, C, D, ...). In UNIX, everything starts at / and you mount media to specific locations (like mounting your primary partition at / and a secondary one at /home).
Back when we were using Windows 95, 98 or XP, the default file explorer looked a bit like this:
The whole experience of going around sucked, but we didn't have good search (it sucked) and apps that do so many things (simple ways to save, open and share documents) that you won't even know what files are. We also had small hard drives so deleting things was important. Also due to slow search and bad file browsing we kind of kept files a bit more organised.
We also had tools like Total Commander (screenshot below), which by default allowed us to easily manipulate and organize files and folders but also show things like the file extension and size. It also had useful keyboard shortcuts (by default, and showed at the bottom) to make things fast. Full paths are always visible, and you can navigate to folders by typing the paths. I used to spend a lot of time in Total Commander on Windwos 98, ME and XP, mainly copying things around for games or small programs I was trying to make.
Now what used to be My Computer looks like this:
I'm putting this here because, as an average user, you don't need to know that what you see there as Documents or Pictures are actually in the C:\ drive (or D, or E, or some networked drive, depending on configuration; default is C). The average user doesn't know that or at least not intuitively.
And this makes it very hard for them to go to Documents/MyFirstProgram from the PowerShell or Terminal. They just don't know where it is!
The terminal or PowerShell
In Windows you now have a nice-try of a terminal that's much better than the original command prompt but still a joke. It's called PowerShell. Since I can't get most of my students to use linux (it's for another post), I try to use what's available. Turns out you can run stuff like openssl or python from the PowerShell without too much hassle. And there's chocolatey as a package manager for Windows; it misses some stuff still, like adding to the PATH environment variable automatically, but once you figure out what it missed you can figure out how to do the rest, still saves some time. Enough with the rant.
In my opinion in order to do anything related to programming you need to first be able to navigate the local filesystem from the command line (command promot, PowerShell, bash, whatever). You know, basics like cd, ls/dir, pwd.
Also you need to be able to do basics like copy files, move files, delete files and create new (text/empty) files.
Also generally being able to run commands is important, because this is how you'll compile (if necessary) and run your program(s).
But doing these things is so confusing for anyone who's never used the terminal or PowerShell before. And just to make it worse, remember that most users aren't even comfortable navigating and understanding the concept of files and the filesystem by using the usual GUIs.
I think using the command line is a critical skill for learning to program. You don't have to be a bash ninja or live in the terminal but you do need to understand it enough to be able to run your programs with some command line arguments.
The programming language, the interpreter/compiler and the IDE
They're not the same thing but people get them confused all the time. I blame bad teaching and bad online tutorials. They keep claiming that all you need to program is SomeAmazingProgram and to press the GreenRightArrow button to run your code.
Sure, you can write print("hello") in your IDE and it will run when you press the GreenRigthArrow. Some problems with teaching programming this way are
- students understand that SomeAmazingProgram (the IDE) is the same as the programming language interpreter (and/or compiler), and the programming langauge itself,
- students get really confused about running their code outside of their IDE,
- students never really grasp the fact that the IDE is just a fancy text editor.
I really suggest that teaching programming should start with making the clear difference between:
- the programming language itself (the specification of the language),
- the compiler (if compiled language used) or the interpreter (if interpreted language, or both if both needed),
- and the IDE or text editor.
Actually, I highly recommend NOT using IDEs for teaching programming. You can introduce them after people can AT LEAST confidently solve fizzbuzz with n as a command line argument.
Software development processes
Introducing things like SCRUM, Agile, whatever? Or things like class diagrams? Or things like gathering requirements? I don't understand why this is ever done. Students who aren't yet fully introduced to programming do not need to go through this. It's useless. It seems like a good idea, maybe to someone who never took that module, but it isn't. What's the benefit? Any benefit at all?
I can tell you what's the con: it's a waste of time and brain capacity for the students to learn useless crap.
Some stuff might be useful, but not when learning to program. You should be able to turn what client wants into software requirements. But you can do that using common sense, no formal training needed. Tell me one person who really felt like they couldn't translate what clients wanted to software requirements without formal training to do this. I'm not saying reading about this stuff won't make you better at it, but I don't think it's important for first or second year CS students. I suggest focusing on the fundamentals: programming (OOP and other paradigms), algorithms, data structures, computer systems, operating systems, networks, this type of stuff.
Wireframes and other things like that, for UI and user interaction, are important. But they're important not for the coding and programming, not for understanding for loops, if statements, variables, how to run your code and some algorithms and data structures. No. They're important for a different purpose. They're important to learn how to design a software project that people will [be able to] use. Also to teach how to think in terms of the user experience and how to do some basic user interaction and user interface design. Note that the user interface can also be via command line, designing good CLIs is not easy, we should not forget that. Other programmers or power users are still users.