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, teachinggituse 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 quitvim. -
similarly, there’s a world of difference between
python foo.pyandpython3 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.
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.
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 ;)
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:
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.
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/)
On the git front, perhaps https://gitless.com/ might help as a bridge? It’s a git porcelain that aims to fix infelicities in git’s model. (There are a couple conference papers that go into more depth on what that means.)
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.
Pingback: Professional Development – 7/08/2019 – 7/14/2019 – The Software Mentor
Pingback: Professional Development – 2019 – Week 29 – Geoff Mazeroff
Impressive post. Thank you so much for sharing this post with us. Great Job