Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to teach software development fundamentals.
In college I took two courses that were creatively named Software Engineering 1 and Software Engineering 2. Software Engineering 1 divided everyone into teams of 5 to work on a 10 week project. This was the middle of our second year and this was largest project we were going to work on to date. You can only imagine the quality of those projects.
That is where Software Engineering 2 comes in. The course was described as a course on software design patterns, and that is indeed what the lectures were based on. But the interesting part was that the faculty had curated the worst project in Software Engineering 1 and made refactoring this project the main assignment for the course.
Once again we were divided into teams of 5, but instead of writing our own code from scratch like we were used to, we were given software that was already working. The underlying code just happened to be a disaster.
This was by far the most important course I took in college. Up until that point, the only “refactoring” we did as college students was rewriting our own non-working code into working code. That isn’t really refactoring either, it’s just normal development.
Most developers don’t get to write code from scratch. They go into a company that already has a code base. Their job is to learn how it works, build on top of that existing code, and hopefully make improvements/refactor.
For those who are lucky enough to start off building code from scratch, a successful project is one that’s going to have to be maintained. That means building on top of existing code and hopefully making improvements/refactor. A successful project will be around for years and in that time, one can only hope that the original developers for that project have learned and improved their skills. That means they would know how to build things even better than they did when they started the project. They would look at the existing code and see all the ways it could be improved.
In short, they would be doing the work every other developer does. The exception is that the existing code is from their younger selves. The code would be just as flawed as if someone else wrote it and in some cases it would look just as foreign. I’ve definitely looked at code and gone “Who the hell wrote this garbage?!” only to see that it was me two years previous.
Since a developer is dealing with existing code most of the time, no education could possibly be considered complete without learning to refactor. That’s what made Software Engineering 2 so valuable. In the real world, you get all sorts of code where the quality is extremely subjective. One developer may think it’s fine while another may think it’s garbage. Either could be wrong.
With a college course, the faculty can curate a project that is unquestionably awful. This provided the perfect playground for us students to practice our craft. It was easy for anyone to find over a dozen things that could have been better. There couldn’t have been a more perfect setup for our success.
In addition to giving us critical development skills, we also gained a lot of confidence. Despite our mockery of the original authors for the project, most of us saw that we had made many of the same mistakes in our own projects. Knowing how to improve those flaws showed how much we had grown as developers in a short period of time.
Personally, this course also set me up for the rest of my career in many ways. I had struggled a lot with college up until that point. Even though I was learning and getting better, it never felt like it. It was only until after Software Engineering 2 did I start to develop confidence as a developer. Instead of struggling, I started to enjoy the rest of my college courses and the craft of software development. That only helped me learn faster. I was excited and constantly needed to find ways to improve even more. Improving as a software developer is addicting.
Maybe I just needed time to gain that confidence, but I think it was important to see how much I grew. Nothing does that better than looking at flawed code and thinking “I used to make those kinds of mistakes. I can make that better!” It was also important to learn that writing flawed code is ok. Every line of code a developer writes is flawed. Realizing the flaws in our code is a sign that we have become better developers because we have learned something. There is no limit to how much better we can become.
P.S. If you’re thinking “wow that’s a really mean thing to do to the students who worked on that project!”, have no fear! The faculty was smart enough to realize how immature and mean we were. They picked a Software Engineering 1 project from a previous year so none of us knew who wrote it.