The challenges of teaching software engineering

I’ve just finished teaching a four-day course introducing software engineering for the first time. My plan is to refine the course (I’m teaching it again in October), and it will eventually become the basis for doctoral training programmes in research software engineering at Oxford, and part of a taught Masters. My department already has an M.Sc. in Software Engineering for commercial engineers (in fact I have that degree), and we want to do the same for software engineers in research context.

Of course, I can also teach your team about software engineering!

Some challenges that came up:

  • I’m too comfortable with the command-line to get people past the initial unfamiliar discomfort. From that perspective, command-line tools are all unusably hard. I’ve learnt from various sources to try foo --help, man foo, and other incantations. Others haven’t.

  • git, in particular, is decidedly unfriendly. What I want to do is commit my changes. What I have to do is stage my changes, then commit my staged changes. As a result, teaching git use takes a significant chunk of the available time, and still leaves confusion.

  • you need to either tell people how to set their core.editor, or how to quit vim.

  • similarly, there’s a world of difference between python foo.py and python3 foo.py, and students aren’t going to interpret the sorts of errors you et if you choose the wrong one.

  • Introduce a tangent, and I run the risk of losing people to that tangent. I briefly mentioned UML while discussing diagrams of objects, as a particular syntax for those diagrams. In the subsequent lab, some people put significant time into making sure their diagrams were valid UML.

  • Finding the trade-off between presentation, tutorial, and self-directed exercise is difficult. I’m used to presentations and will happily talk on many topics, but even I get bored of listening to me after the ~50% of the time I’ve spent speaking on this course. It must be worse for the students. And there’s no substitute for practical experience, but that must be supported by guidance.

  • There are so many topics that I didn’t get to cover!

    • only having an hour for OOP is a sin
    • which means I didn’t even mention patterns or principles
    • similarly, other design techniques like functional programming got left off
    • principles like Agile Software Development, Software Craftsmanship, or Devops don’t get a mention
    • continuous integration and continuous delivery got left off. Even if they didn’t, the amount of work involved in going from “I have a Python script” to “I run my tests whenever I change my script, and update my PYpi package whenever they pass” is too damn high.
    • forget databases, web servers, browsers, mobile apps, desktop apps, IoT, or anything that isn’t a command line script or a jupyter notebook
    • and machine learning tools
    • and concurrency, processes and process improvement, risk management, security, team dynamics, user experience, accessibility…

It’s only supposed to be a taster but I have to trade off introducing everything with showing the value present in anything. What this shows, as I found when I wrote APPropriate Behaviour, is that there’s a load that goes into being a programmer that is not programming.

7 Replies to “The challenges of teaching software engineering”

  1. Thank you for your article. I have been thinking about this subject for some time so it was nice to have a “sparring partner”.

    If I may be so bold as to offer some insight I have gained being a teacher.

    you can’t teach it all. –

    When I was starting as a teacher I wanted to teach it all. My passion for the subject matter at hand, were it English (my main subject), technical photography, or examination training for teachers, could easily get in the way of me teaching. I wanted them to absorb all the intricacies, awesomeness and the full scope of my subject matter. I taught with passion and that does help a lot, but I forgot about the journey I had made in order for me to appreciate all I wanted to gift them in that moment. I forgot about the steps I had to take to get to here. Not to mention the fact that some people just weren’t and would never be that interested in my subject.
    This all was a major let down for me as a young teacher and made me feel I wanted to quit. Having put that aside for now, I later on realised that it is okay to teach bits and pieces. Seeing that you cannot teach it all you need to pick and choose. This is not cherry picking though, no, it is finding out what really is necessary for them to continue on from there on and start teaching there.
    I realise I am ranting a bit here, and that is because I really am very passionate about teaching, and I would like to help out, but I have fallen in the same trap as before.
    Being a teacher is not something that happens overnight and a lot of the intricacies of teaching I cannot convey in a few lines here (typed with a baby in the other arm).
    I would for now suggest you take a look at the curriculum of the course and start removing stuff. Keep it basic and remember it is often easier to add to a “too empty” curriculum than it is to remove from a “too full” curriculum. Plus a slightly empty curriculum gives you room to add a bit of you into the mix.

    Good luck with developing your course!
    And if you ever want to “spar” then feel free to contact me on brave0tea@gmail.com (brave”zero”tea)

    Once again thank you for the article.

  2. Welcome to teaching, and/or presenting a project. In both the most difficult thing is to know what to leave out, and what to insist on.

    The most important question then gets the following: “what should they know after this course?” You seemed to have “create a program from scratch, starting with the concept, followed by the planning phase, choice of language, revision management”, and I’m glad you did not include “CI/CD” in the pack, too ;)

    Anyway, looks pretty significant for four days. As you mention rightly, each of those subjects take longer than just the time to show how you do it.

    Or you decide that you want to have a course with a big breadth, but then you shouldn’t be sad if they don’t get git-pros within the hour. Be honest, it took you longer than that, too. At least I did. And after 10 years of git, I’m still learning new tricks.

    Good luck on your next iteration! It’s a wonderful way. And in 20 years you’ll still be making the same mistakes, believe me ;)

  3. Alexander, thanks for your comments! You’re right that this is a really broad course and the syllabus needs rearranging. I think there are two “target markets”, and it actually needs to fork to work for them:

    • for people who are researchers, who have software projects, and who aren’t following engineering disciplines, it should be the gateway drug. Here are all of these awesome things, here’s how they can help you, now you make a list of the ones that will help you most or are most interesting. We know you’re already a self-motivated researcher, so now you know these things exist you’ll learn more about them (including coming back to us).
    • for students who are new to this, it should be a collection of good practices that they can follow now, without necessarily understanding the philosophy or the nuance. For this audience, the course as written fails for the reasons you describe. A smaller course focused on the biggest impact (off the top of my head: problem decomposition, software construction, version control) would be more helpful.
  4. but then you shouldn’t be sad if they don’t get git-pros within the hour. Be honest, it took you longer than that, too.

    True, my problem with git is that you can’t even be a git novice after an hour of teaching :). What I want to do is to get people using version control, but because that’s widely synonymous with using git I have to teach a really complicated tool. RCS on a local filesystem, svn, or even hg would all be much simpler tools for getting from MyProject_v1.1_finalfinal_2.zip to version control.

  5. Just skimmed the readme.

    Some good points in ‘Testing research software’, more time needs to go into this.

    Readability issues are just personal opinion.

    No mention of cost/benefit tradeoffs.

    No mention of trying to be evidence driven (check out http://www.knosof.co.uk/ESEUR/)

  6. There is a trade-off involved. If I teach vanilla git, then it’s harder, but they learn real git which is what they will see “in the wild”. If I teach gitless then it’s easier, but they learn gitless, which sweeps real git under a rug.

    The middle way I was thinking of taking was to show enough real git to know that the words exist, then switch to the version control view inside an IDE. Other trade-offs abound.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

This site uses Akismet to reduce spam. Learn how your comment data is processed.