The one change I’d make to software engineering courses

There's a lot of content out there on the Internet discussing the shortcomings of software engineering courses, and what the authors would like to see changed in order to 'fix' them. And in general I think a lot of the suggestions made are good ones! Virtually every software company on the world is using Git to manage their source code, and that's been the case for probably a decade at this point.

So when folks say that students should be taught how to use Git as part of their degree, I don't think that's an unreasonable suggestion and it could even be worked in amongst the rest of the curriculum. Git repositories are giant graphs and I think having a semester-long project where students implement a minimal clone of Git would accomplish a number of goals simultaneously: solidifying the theoretical knowledge students have about graph data structures & algorithms, getting familiar with how Git works, and actually building a really practical piece of software.

But if I could only make a single change to software engineering courses, it would be to create a paper about reading and understanding code. Code is read so much more often than it is written, and so it seems odd to me that at no point in the computer science / software engineering curriculum are students taught how to do it. Aside from being a necessary skill to have in order to work a software development job or to be an effective researcher, I also credit most of my improvement in writing code to going through open source projects and reading proprietary codebases I've had access to through the course of work. This isn't unique to programming -- reading books is often cited as a good way to improve your ability to speak and write.

In my mind, this paper looks really similar to literary studies. Every so often (every week or two?) the lecturer would assign a codebase to analyze, and students would need to answer questions about the codebase and potentially make some changes. By looking at a variety of different codebases, the expected outcome is that students become familiar with searching through unfamiliar codebases, start to recognize common structures and patterns, and passively assimilate knowledge about how "real" software is architected.

Some example problems could include:

1. What code path is triggered when a user clicks the "save file" menu item?
2. There is a buffer overflow in this project -- find it and fix it.
3. This piece of software exports financial data from a ledger to a csv file. What happens if the export is interrupted partway through?
4. Here is a chunk of code responsible for providing some service X. How testable is it, and what could be some possible ways to restructure it in order to enhance its testability?

It takes a long time for newly added developers to become productive as they need to spend time getting to grips with how the code is structured. This "ramp up" time occurs right after an expensive and time-consuming hiring process, and the duration of it depends on a number of different variables -- but the two big ones are the experience level of the developer and the complexity of the codebase.

Hiring newcomers to the industry is risky, then, because by definition they have no experience and therefore require significant resources diverted from other parts of the team in order to onboard them. Undoubtedly, this is a multifaceted issue: being a valuable software engineer involves more than just being able to understand and write code, and that's where other suggestions for software engineering courses come in to play.

Bearing that in mind, being able to read and understand code, ask clear questions about it when necessary is still fundamentally important. Currently the only time software engineering students are expected to read code is when it is scribbled on a blackboard or when they're debugging their implementation of LZW for an assignment. The current reality is that (outside of internships) you can go through the entire higher-education system without ever looking at "actual" code and I think being in that situation is massively detrimental to one's ability to go on and actually leverage their education.

I reject the idea that we should expect people to study code in their free time as not everybody is in a position where that's realistic. Leaving tertiary education with an ability to read and reason about foreign code seems like a reasonable baseline for a four-year course when so much of what you do as a software engineer involves reading code.

There's a an understandable reticence to teach specific tools due to educators' concerns about universities being reduced to job mills, the ability to read code is fundamental to the role of a software engineer. This particular skill will never diminish in importance, and it should absolutely be taught as part of software engineering courses. It being a skill that is continuously developed over an individuals' career does not take away from the value a university could offer through such a paper -- if that were the case, humanities courses wouldn't engage in literature studies as analyzing literature is also something you continously get better at doing.

This one change feels like it would be hugely beneficial for students, and would be relatively easy to implement due to low resource requirements -- although that could be naivety on my part.