
The challenges of teaching software engineering - ingve
https://www.sicpers.info/2019/07/the-challenges-of-teaching-software-engineering/
======
dzink
You seem to be starting too abstract. Analogs help and so does starting from a
point where the students can experiment and get feedback on their mistakes
from their own code, not from abstract concepts. These are lessons I learned
when we designed and taught a 8 week coding course for Graduate students who
had never touched code before. Feedback for us as teachers was instant.
(Analogs. Analogs. Analogs.) Imagine learning about structural engineering -
would you rather start by prototyping bridges with different materials and
seeing how different structural designs hold up better, or would you prefer to
be lectured about conflicting philosophies on proper road arrangement,
materials and tensile strength first.

Analog example I used (explain like they're five): Front end, backend,
middleware, databases are like a Macy's animated window display. HTML is
choice and order of the mannequins in the window. CSS are the colors and
positioning. Javascript is the string that makes visible characters move.
Middleware (Python, Go, Java) are the sales clerks grabbing goods from the
warehouse (database), serving customers, and updating the window panes.

The course did a lecture on HTML/CSS first day, Javascript second, dug in
deeper by debugging a snakes game in JS, Git on day 3 (failed for same reasons
you mentioned), Ruby on Rails (immediate productivity was key), Wordpress
installation, then PHP deeper dive, etc. One student said "I can't believe I
paid someone $20k to build me a Wordpress site that I can now set up and
customize myself after a few days."

Always start with immediate productivity for non CS students - let them sink
teeth into the ideal outcome, then modify that ideal, then learn how to break
and fix it, then dig deeper into why and how things work before going to best
practices. If they don't know why something broke, they can always go back to
figure out how it should work first.

~~~
dzink
If I was to do it again, I would teach Git with paper - have the class augment
a paper tree with paper nodes or something else tangible. You can even have
them write a collective story instead of code. The more abstract the topic,
the simpler the analogs to get the largest subset of users to grasp it.

~~~
haggy
I have to strongly disagree with this approach to teaching git. I've been in
software engineering for a decade now and have taught many entry level and
experienced devs about git. If you start out with trees and other git internal
concepts you're just going to lose them. Have them create a directory, put
some files in it, `git init`, add all their files and commit. Have them make
some changes, add and commit again. Then ask them how their fellow devs would
see their changes. This leads into the distributed nature of git and pushing
to remote repos. Continue from there with more practical work and repeat. I've
seen it take devs months of working with git daily to start to understand some
of the more advanced concepts so it needs to be practical up front.

~~~
newen
If you've seen devs take months of working with git daily to start to
understand some of the more advanced concepts, then maybe the problem is the
current teaching method. They might learn the more advanced concepts a lot
faster if they learn the concepts first.

~~~
flukus
You're assuming they want to learn. I've seen devs work with svn for years
which is conceptually much simpler and they still don't know how branching and
merging work, they'll do things like checkout each branch separately and copy
files over rather than merge.

Edit - also a favourite interview question for anyone that claims to be
familiar with svn is "what does the switch command do", a quick and easy
filter to seperate those that know from those that claim to know.

~~~
slavik81
I felt their attitude towards SVN was silly, so I decided I would make my
change the right way. But when I went to merge, I got a bizzare error about a
'missing revprop' and it knocked the wind out of my sails.

I'm ashamed to admit it, but I ended up copying the files just like everyone
else on that project for the brief stint I worked on it. :(

------
steven2012
No offense to the OP but the syllabus is ludicrous. This isn't teaching
anything. It's so packed with random software technologies, they will leave
the course with nothing. Cut down on the syllabus and focus on a few topics.
Make it project based so that you're building on the same project over the 4
days and learning more about programming.

Split the other stuff like git, databases, OOP, functional programming,
machine learning my God, for another course. There is no way anyone taking
this course will get anything from this, it will just be a confusing mess of
information that is quickly forgotten.

~~~
alexgmcm
I read it assuming it was a semester long.

Then I saw it was four days.

------
DarkContinent
I'm sort of curious how one could "learn" software engineering in a week.
Judging from the article, it seems the course assumed very little prior
knowledge about SWE (teaching OOP at the beginning). Wouldn't it make more
sense to teach a course assuming some basic background knowledge (like OOP and
command line utilities) and use the teaching time to discuss architectural
patterns, testing practices, etc?

~~~
highwind
Biggest thing that needs to be taught as one of the fundamentals for software
engineering is approaching problems with scientific method.

Design, testing, and debugging (which takes up more resources than writing
code) require skill in forming good hypothesis and methodical way to test that
hypothesis.

These type of courses should be designed more towards those skill sets than
just learning to write code.

~~~
sreque
I've actually been thinking at work recently that our work is very much in
line with making and testing hypothesis. When we add code or edit existing
code, we hypothesize that the program behavior will change in specific ways,
and then we test those hypothesis via various means of manual and automated
testing.

I would actually add to the above though that I think it's important people
learn to approach problem-solving from a mathematical perspective.
Unfortunately, a lot of people that get into software engineering don't like
math, and they would generally be averse to learning about software
engineering this way, but I think a lot of bad code gets written because the
person writing it didn't approach the problem with the right structure or
rigor.

~~~
chrisweekly
Where you say "mathematical" I'd suggest "logical". Also, formal logic
(Aristotelian, sentential, predicate...) is distinct from mathematics per se.
Agreed that fundamental problem-solving skills are in too-short supply.

------
invalidOrTaken
I don't know exactly what the goal of the course is, or where he's teaching,
but...

it seems like a really hard problem.

Making working computer systems---like a drawing program, or an Amazon deploy
---can be really hard, or really simple. You can teach someone enough Python
for fizzbuzz in twenty minutes. Teaching them enough... _everything_...to get
a web version of fizzbuzz, that checks a database for the words (it might be
"nargle" and "gargle" by user preference, after all), with a Python install
that they manage, a postgres install that they manage, that they don't feel at
a complete loss about if something goes wrong, and to collaborate with others
on this...is another matter entirely.

I'm not one of those who believes programming ability is innate, but there are
absolutely compounding effects that can certainly have basically the same
effect. In retrospect, I thank my lucky stars for my 6th-grade computers class
using HyperCard.

------
jkingsbery
I taught a 2-hour session to a group of middle schoolers and high schoolers
back in December - obviously, not as big a deal as the author, but still
something I'm proud of - and ran in to the same issues. These were all
students who either had done some programming or were interested in it. I
started with "ok, so, first, go to your command line..." and it went sideways
from there.

One thing that the students taught me that helps overcome some of these things
is a site called [https://repl.it/](https://repl.it/) . I stopped my plan,
started using it, and taught the rest of the class using repl instead in order
to focus on the concept I was trying to teach. Obviously, as a professional
software engineer you need to know about git, command line, etc., but those
aren't what software engineering is. They _rarely_ excite new comers to the
field. Using repl.it helped to get to the core ideas faster for people who
don't really know as much.

~~~
rpeden
If you enjoy repl.it, you might enjoy StackBlitz as well. I've had fun using
StackBlitz to put together some prototypes of React apps.

I love repl.it too, of course! It's nice to have several great tools to choose
from.

~~~
jkingsbery
Interesting, thanks for the reference!

------
coldcode
What is software engineering anyway? I've heard this term for almost 40 years,
and still wonder what it really means since everyone has a different idea.

~~~
carapace
Dr. Margaret Hamilton coined the term while developing the software for Apollo
11. She went on to design a system that permitted bug-free software
development ("Higher Order Software" or HOS) and attempted to market it. It
was panned by e.g. the Navy and Dijkstra, and languishes in obscurity to this
day.

The basic details of the system are described in a book called "System design
from provably correct constructs: the beginnings of true software engineering"
by James Martin (he mentions Hamilton in the references.)

In modern terms you work directly with an AST and the UI only permits
modifications by operations that preserve the correctness of the AST. It
eliminates all sources of bugs, and it was simple enough to teach normal
people to use it with just some coaching.

Anyhow, _that 's_ "software engineering". The rest of us are just pushing text
around in buffers and _hoping_ it isn't broken. There are a few people using
math to make software, and it works out really well (E.g.
[https://www.categoricaldata.net/](https://www.categoricaldata.net/)), but
mostly "software engineering" as it is usually used is an oxymoron.

~~~
Jwarder
> you work directly with an AST and the UI only permits modifications by
> operations that preserve the correctness of the AST. It eliminates all
> sources of bugs

With the caveat up front that I know nothing about this beyond what you have
written: wouldn't this just catch compilation bugs? The compiler tells me if
the blob of text I gave it is incorrect in terms of any syntax errors.
Business logic bugs and accounting for bogus data seem more important to me.

~~~
carapace
Yes, you and skybrian have got the idea. It wasn't magic, it just prevented
entire categories of preventable bugs, syntax and semantics.

You could still use it to write correct programs that did the wrong thing. In
other words, it couldn't catch bugs that occur "between the keyboard and the
chair".

FWIW the tech has a bit of a Wikipedia page now:
[https://en.wikipedia.org/wiki/Universal_Systems_Language](https://en.wikipedia.org/wiki/Universal_Systems_Language)
but it doesn't seem very informative to me. YMMV

~~~
Jwarder
I can imagine this being useful for people new to programming. I've seen
plenty of times where students get overwhelmed with all of the different
keywords/syntax they just learned and don't know where to apply it. Being able
to give a list of possible actions available from the current node(?) could be
a huge help.

~~~
carapace
Apparently they sat down, like, accountants in front of this thing and they
could derive trees (programs) that automated tasks just fine with a bit of
coaching. _shrug_

(But that also worked with Lisp+Emacs!

> programming new editing commands was so convenient that even the secretaries
> in his office started learning how to use it. They used a manual someone had
> written which showed how to extend Emacs, but didn't say it was a
> programming. So the secretaries, who believed they couldn't do programming,
> weren't scared off. They read the manual, discovered they could do useful
> things and they learned to program.

[https://www.gnu.org/gnu/rms-lisp.html](https://www.gnu.org/gnu/rms-lisp.html)
)

------
jillesvangurp
When I was doing my Ph. D., I also ended up teaching some software engineering
related courses. One thing that struck me and that I've since fixed by
becoming a software engineer was the notion that here I was teaching Software
Engineering without any experience whatsoever actually engineering any
software professionally. This is the big problem in academic education on this
topic: the teachers typically have little or no relevant experience actually
engineering software because they have been in university all their life and
as such lack experience working for extended periods of time with an actual
team on some actual non trivial software. Lets just say that I learned a lot
about this stuff after I left the academic world.

A good practical introduction to software engineering should cover a lot of
ground and most of it is going to be non technical. Learning how to program is
mostly out of scope for a software engineering introduction. Assume the
students have already learned some programming language and have some
experience building small programs and maybe have already had some algorithm
courses, etc. It doesn't really matter what language or tools they use. For
the purpose of an introduction, pick something simple where the focus is
mostly not going to be fighting with the tools.

The key thing to learn as a software engineer is working with multiple people
and the project dynamics that are associated with that. So:

\- project management and different roles in software projects, different ways
of structuring teams, etc.

\- overview of different process methodologies common in the industry and
where they came from: scrum, kanban, watefall (don't do this), etc.

\- different types of testing and their importance for continuous integration
and deployment

\- different strategies for estimating cost, complexity, duration, etc. and
their flaws and pitfalls.

------
BeetleB
Most of the problems he is having seem orthogonal to software engineering,
which he is trying to teach. It's clear he's teaching it as an intro course.
In my opinion, SW engineering absolutely should be taught as a later course -
after the student has had quite a bit of exposure to programming.

I wouldn't expect a SW engineering course to require _teaching_ much command
line usage. That's a thing for lower level courses. Same with editors.

Don't use git if it is confusing to students. Mercurial is as good and much
friendlier. The potential benefits to git are fairly advanced and will not
have any impact at an introductory level. Your goal is to teach the concept of
revision control, not the internals of git (which every git advocate says one
should know if one wants to use git well - just search any HN thread that
comes up about git).

As for Python vs Python3: Again, I would not expect a SW engineering course to
teach any language. The course should let the student pick a language of
his/her choice.

------
dnprock
I think there's a hype in quickly training software engineers. This article is
an example. We poke around with tools to find quick and easy ways to create
software. Tools have been improving quickly but creating software remains
challenging. The tool race is influenced by market more than software
engineering.

The discipline of software engineering has not changed much for decades. To
teach effective software engineering, we need to start with the principles.
Some fundamental questions:

\- How do we create functional and scalable software?

\- Given an existing (complex) software system, how do we maintain and
incrementally improve?

One important principle I learned outside of school and training: software is
never just code, we always need to think about the user ecosystem around the
software. Failure to understand this principle leads to wasteful effort. For
example, attempt to rewrite of the code.

These principles are very abstract. We cannot teach them easily. People use
tools and new technology to cover up their lack of understanding.

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

In college, the way my professors got around this and other things like it was
by creating an alias file and scaffolding code. We would get a project that
was 1/2 done with all they annoying crap, and then only have to implement the
algorithms. Then we would save our work with a single simple command with no
options, that was just a shell script for all the source control steps (rcs at
the time, but the idea is the same).

They never actually taught us about source control. We just learned it on our
own when we stopped having access to their aliases. But at that point we had
enough knowledge that we could figure out it (or we were in our first job and
the senior devs taught it to us).

------
fogetti
If it's an introduction to software engineering then I think leaving out
software craftsmanship or functional programming, etc is not necessarily a
sin.

And git (the cli not the versioning approach per se) never made sense to begin
with. It is extremely user hostile. So no surprises there.

~~~
spraak
I have heard often people's view that git is not user friendly, but it's
always confused me because that hasn't been my experience compared to any
other tool I need to learn. Can anyone explain more this view? Perhaps I'm too
accepting and forgiving.

~~~
fogetti
`git merge`, `git rebase`, `git rebase -i`, `git revert`, `git checkout`, `git
reset`, `git reset --hard`, `git log`, `git reflog`, `git stash`, `git cherry-
pick`, `git add`, `git rm`, `git status`, `git commit`, `git push` and squash,
reword, fixup, pick and f@ck knows what else. Who wants to really use all this
bullshit just to do versioning?

Especially if you are a beginner, this doesn't make any sense (and not even
later in many cases)

In my experience during the last two decades or so in the industry, there is
always a special kind of person in the IT field who takes pride knowing all
the nitty-gritty details of the latest shiny versioning tool. Should it be IBM
Clearcase or SVN or CVS or Git or Mercurial. Even though that most of these
softwares only slightly improve the user experience and only claim to solve
the users' problems, so they over promise and under deliver. But there is this
special kind of person who takes pride in it.

To me this seems like someone who takes pride in knowing all the details of
his toaster. Might be impressive, but also completely irrelevant for the 90%
of the toaster users.

~~~
eitland
> Who wants to really use all this bullshit just to do versioning?

Nobody. It is a strawman or should be.

You can teach _everything a beginner need to know_ about git _as an ordinary
team member_ in less than one A4 page and less than half a days work.

Of course this means part of what you teach then is when to talk to the git
expert on the team but as long as beginners _stay away from_ squash, rebase
etc they should be fine.

Ok, add another half day about effective diffing and merging too, it is a big
topic and useful outside the context of git too (local history etc).

~~~
BeetleB
>Of course this means part of what you teach then is when to talk to the git
expert on the team but as long as beginners stay away from squash, rebase etc
they should be fine.

The thing is, if you ask 10 git experts what should be taught to a beginner,
you'll get 10 different A4 size pages. As an example, when my team (finally)
switched to git, the expert on the team made a tutorial on what commands to
use, and what to avoid/ignore. Looking at it now, he taught that rebase is
almost mandatory and gives problems you're guaranteed to run into if you don't
use rebase.

Not saying I agree with him, but that is one problem with git - no clear
consensus on beginner friendly features.

------
bsder
> git, in particular, is decidedly unfriendly.

Why do people _persist_ in pushing one of the most user unfriendly tools to
ever exist?

------
hyperpallium
It's very difficult to teach software engineering because you need a big
project to create and/or modify.

Another reason it's difficult to teach is because of a complete lack of a
legitimate discipline to teach.

------
colemorrison
Having taught software, devops, and the like for years at this point, while
this article touches on some difficult parts of teaching, they're all just
side effects of bigger difficulties of teaching software.

a) Everything is the "tip of the iceberg" \- which makes teaching what you
actually want to teach tricky. Which is why so many resources do the whole "we
won't go into it, because this is a large topic." For example, Linux. Most
projects and resources require this, but barely any actually go in-depth.

b) Everything is always changing - and so you have to either support your
students in the face of these changes or constantly keep the materials up-to-
date. This is one of the largest challenges, if not the largest challenge.

c) Everything has to be engaging - it's not enough to know what you're talking
about. You have to know how to talk about it in a way that creates engagement
and thus learning. This isn't something you learn how to do when slinging code
left and right.

d) Everything needs to be TAUGHT, not said - the ability to teach is often an
after thought for folks looking to educate. If you want to really help your
students, you have to learn how to teach so that they can think independently.
Not rely on cheatsheets, prep tests, and step-by-steps.

e) Every student needs the motivation to learn - usually instructors' will
stop at spitting out their knowledge. The best instructors help their students
push through their barriers, whether personal or professional, and get the
learning done. It's easy to learn in a structured school system. It's hard to
learn when you have multiple kids, a full time job, and all the emotional
baggage of being an adult.

Now, to be clear, I'm talking about teaching modern, practical implementations
of software...not CS theory or other things that are far more evergreen and
less technical.

------
angarg12
I was a teaching assistant for the Introduction to Programming course on the
first year of a CS degree. At the very least I can say it was a humbling
experience.

One thing I learned while teaching complete novices is that it is really hard
for experienced engineers to get into the mindset of students. You need to
forget everything you know and start more basic that you think it's necessary.
You will need to teach people what are variables, list, functions, and so on.

As an example an student got confused when we wrote something like the
following:

let X = 1; let X = X + 1;

How could X be X + 1 at the same time? Maths don't work that way!. It might
seem absurd to a programmer, but if you are in the mindset of someone who is
only familiar with maths equations, it makes sense.

So yeah, I would forget git, command line, tangents and whatnot, and focus on
very basic concepts instead.

------
ilaksh
This is the course he is talking about: [https://github.com/OxfordRSE/rsd-
engineeringcourse](https://github.com/OxfordRSE/rsd-engineeringcourse)

So to become a "real software engineer" and not "just a programmer" one needs
to know how to create requirements, use source control, do modular, and/or
object-oriented and/or functional design, deploy your software, and take
advantage of open source?

Those are things that all programmers need to know (assuming "programmer"
means someone whose primary job is programming). Which is why the distinction
between "programmer" or "developer" and "software engineer" is bogus. Its
usually just an attempt to justify higher or lower compensation.

------
codingslave
The secret of programming, and it's greatest challenge, is that the ability to
get "good" at it is largely innate. Just like you can't teach people to prove
math theorems (the ones that one encounters in an elementary college proof
class), you can't teach great software engineering. Near anyone can learn to
build a javascript app, beyond that, to higher levels of abstraction and
complexity, things become murky. It's why large tech companies ignore past
experience, it proves nothing. They need to see you use abstractions from
memory on the spot to ensure you have the capability. It's not perfect, but
nothing is.

------
dijit
Software engineering at least has a fundamental underlying educational system
supporting it (comp sci, EE).

I think the harder thing is training sysadmins, there’s no real formal
education. I know we’re downplaying a lot of the traditional sysadmin roles
and pushing for more development in sysadmin but the sysadmin approach is
still required, and the only thing that keeps it going is the corpus of
industry knowledge, a myriad of vocational or vendor based certs and a
willingness to teach.

Or am I wrong?

------
jpnelson
I'd love it if there was some sort of "helper terminal" that could teach
people things like git, and basic command line stuff as they went.

It could catch common errors and provide useful explanations. It could
possibly even go as far as attempting to understand plain text commands, eg
"delete the file file.txt" and suggest commands to do that.

~~~
eitland
Clippy, as orginally designed before they gimped it? ;-)

Or just contextual help as it existed in many Windows applications (and
certain current iOS apps).

------
gambler
Sounds more like "the challenge of using a mish-mash of non-integrated tools
with no interface". Developers could definitively solve this by moving away
from 70+ year old abstractions (files, terminal) towards things more in line
with Smalltalk ideas. But I guess it's better to make thousands of beginners
suffer each year, instead of admitting that the current way of doing things is
conceptually flawed and outdated.

[https://www.youtube.com/watch?v=I9LZ6TnSP40](https://www.youtube.com/watch?v=I9LZ6TnSP40)

[https://alumni.media.mit.edu/~mt/thesis/mt-thesis-
Contents.h...](https://alumni.media.mit.edu/~mt/thesis/mt-thesis-
Contents.html)

[https://www.youtube.com/watch?v=QTJRwKOFddc](https://www.youtube.com/watch?v=QTJRwKOFddc)

[https://github.com/pharo-open-documentation/awesome-pharo-
ml](https://github.com/pharo-open-documentation/awesome-pharo-ml)

(And no, there is nothing special about copy-pasting commands and Unix
pipelines that cannot be easily recreated in UI if the UI is designed to be
programmable. )

------
kouzant
I hope they don't add Jupyter notebooks to the syllabus. One day we'll wonder
what went bad and whole programs are written in a single module/file :)

Jokes aside, Jupyter and relevant projects are great tools but they drive
programmers towards wrong paths.

------
cryptonector
> \- you need to either tell people how to set their core.editor, or how to
> quit vim.

You'll pry vim from my cold dead fingers.

