It’s hard to believe, but it’s been 3 years since I graduated from Mohawk College’s Software Engineering Technology Program. That means that it has been 3 years where I’ve been able to reflect on what the program taught me, and some of the things that I wish I had learned. There are many things that I am happy that I now know, however I also feel that there were some key elements that were completely overlooked. I don’t want this to be a rant piece, that’s just not my style, I just feel that if I had graduated knowing about the following things I would have entered the professional world a much stronger developer.
1. How to use source control
This one is huge, everything I know about source control and version control systems I have had to teach myself since becoming a professional developer. I’m not saying that every software program should have an entire course dedicated to this, but at least knowing the basics would be nice since it’s so critical to the development process. Perhaps this is specific to the program that I went though, but when I graduated I had no idea what version control was, only that Visual Studio had something called Source Safe that I never bothered to install. Perhaps if it were a requirement for the larger final semester projects to be submitted through a source control tool, don’t even force students to use a specific tool, but use SOMETHING.
2. How to write secure code
When I was in school the web application world was still in it’s infancy so perhaps this isn’t as much of an issue now. Never once did I hear the term ‘SQL Injection’ or ‘Cross-site Scripting,’ but now they are serious issues, especially for developers working in web applications. The only parameter checking that we did were the ones that were enforced by the compiler/interpreter. We would never go so far as to verify that if your code expects a 4 digit number, a 6 digit parameter causes an error.
3. How to do automated testing
This is another big one, and in my situation as a PHP developer, one that I still don’t have figured out yet. We were taught that as long as our programs gave a specific set of output for a given set of inputs, it was correct. While the idea seems rational, our test inputs were more often than not insufficient to catch even the most glaring of errors (like the example in the previous section). Most software shops these days do some sort of automated testing so I think graduating school having never written a unit test puts us at a major disadvantage.
4. Agile development / Extreme Programming
I can’t completely blame them for this, but I think it’s important to mention anyway. The only SDLC that I was taught was the old-school waterfall processes. You know the one, design the entire system using a binder of varying diagrams covered with boxes of arrows, write code to make the boxes do stuff, test that it does what it’s supposed to do, then release it to the world at large. Fortunately for us, the software world is changing, people are starting to realize that software development is a more fluid process than building a bridge for example.
For anything large it’s nearly impossible to figure out every last detail without writing any code at all. This is where Agile/Extreme programming comes in, shorter release cycles, small increments or features between each release.
The other problem with the old methods, as I’ve learned from experience, is that most of the time customers don’t really know what they want to begin with, so how are you going to design it for them?
5. How to write modular software
This is another important one, most of us were taught to write our code as self-contained methods and/or classes. The idea was that it could be swapped out at some later date or extended with new functionality. This is totally fine, but what if you wanted to add functionality without having to change the base code? Not many of the developers I know were actually taught how to make their code extensible through add-ons or plugins.
I think it would be a great idea for students to have to write a base program with extensibility in mind. Later projects could modify it via plugins without touching the original base code.
I have a feeling that this topic wasn’t covered for two reasons, one being that the faculty assumed that all their students would be working on mainframes in banks. The other is that this sort of stuff isn’t exactly trivial code, from my limited knowledge of it anyway. I am still just at the beginning stages of this journey, walked through how systems like WordPress implement hooks in their API.
So there you have it
I’ve tried my best not to bitch too much. I think each of the 5 things I’ve mentioned are valuable tools for any software developer to have under their belts.
Please feel free to add to the list or let me know what you think through the comments.
