There’s lots of things that you do as part of your job as a software engineer that you don’t learn in school.
When you’re first starting out as a software engineer, you probably don’t really know what it’s like to work on a team. You might have had group projects in school, but their scope was limited to whatever you could accomplish in that semester, you’re working on it from the very beginning through to its completion, and everyone in your group had roughly the same amount of experience that you do. This is very different than delivering real software.
In the industry, you usually start out working on a project that’s already in progress, and if it’s software that’s been available for more than a couple of years, it’s got a history that you know nothing about. You have to learn where the project is today, you have to learn how to contribute to your project, and your deliverables or your deadlines1 are going to change at some point. You’re virtually guaranteed that you’re not there for the beginning of the project, you’re coming in to complete the work that someone else has defined.
There’s often not an actual end of a software project. You finish this version, you start working on the next version, and you have to go back and patch bugs from this version while you’re working on the next version. At some point, you’re going to stop working on this project (either moving to a different project in your company, or moving to a different company altogether), and the project is going to continue on. This means that you’re going to have to figure out how to help whoever is taking over your work understand where you are and what needs to be done next.
Your project team is probably bigger than the ones that you had in college, and there are more roles on it. Your college project team probably had everyone contributing code. Now you’ve got to figure out how test fits into your world, and program management, and documentation, and user experience, and then there’s this marketing person that suddenly appears and you don’t know what this means. In addition to all of these specialized roles that you haven’t had to deal with before, you’re also working with a much higher degree of variance of experience. In college, everyone probably had roughly the same level of experience. When you’re delivering software, you’ve got everyone from fresh college grads all the way up to the person who’s been working on this software since it was first shipped N years ago.
Deadlines are fixed in your college project. You know exactly when the semester is going to end. You might decide to change the scope of your project when you realize that you had planned more than you could actually fit into the semester, or when the person who said that they’d do this important piece of code never actually came through, but the deadline is immutable. When you’re working on on a software project, you’ll learn very very quickly that your deadline can get changed without any notice.
Also, your project might change mid-course. When you’re working on a project in a college course, you don’t have to worry about your competition changing, or about the market suddenly deciding that this new technology is an absolute must-have. That list of features that you thought were going into the next release can change at any time, and it probably will. Not only are you going to have to accept this change, but you’re going to have to accept that a feature that you were working on yesterday that was very important might not be important tomorrow. In fact, you might stop working on it entirely so that you can work on something else that’s now more important. That’s okay, it’s the nature of the business.
None of this is meant to say that group projects in college courses are useless. You learn a lot by having to work with other people to get your project done, and that does translate well to your first software engineering job. What you learn in your group project in college is limited, and doesn’t give you the full story of what you’ll experience when you start working for a company on a software project.
- Note that this isn’t an XOR. It’s actually most likely an AND, but I’m going for OR because OR doesn’t preclude AND. ↩