Every year, thousands of new graduates flood in to the work force eyes wide-open, ready to program. Unfortunately, most of them have no idea what they’re getting themselves into. These inexperienced developers only know a life of coding in the structured environment of their schools and have no knowledge of what it’s like to develop in the real world.
Time and time again, I have seen the stark differences between developing a program in the school setting and one in the business setting and I’m going to share my thoughts with you today.
Program Requirements (or lack thereof)
One of the biggest differences I noticed when starting my job as a Web Developer was the fact that our clients didn’t give us any requirements. It’s not that they don’t care about how their product turns out in the end, it has more to do with the fact that the client assumes that we can read their minds.
When you’re in school, the teacher lays out exactly what they want and how you’re going to be marked. You’re given realistic, measurable goals that you can program towards. If only it was this easy in the business world. This really only affects the developers who are making a specific program for a client. If you’re developing a piece of software for your own internal use or for the general publics use (firefox, open office, premiere pro, etc…) you’re making your own requirements based on what you think the consumer wants.
One thing I can say for sure, is that I sure do miss the days when my teacher would hand out a sheet of paper saying exactly what program they wanted, it made life easier.
Working with a Group of Developers
Once you start developing with more than one person the way you go about doing things changes greatly. When you’re in school, you only worry about yourself and what you can accomplish; you don’t need to worry about other people getting their code done in time (or not). Depending on others to get their code in on time and with the required quality is hard to do and takes practice (believe it or not).
One of the best skills that a developer can have is ability to interact with other people. Having technically brilliant people is great, and every team needs them, but if your team doesn’t have people that can cooperate with each other, your project will fail. Having a good mix of social programmers and technical programmers will make sure that your group works as best as it can. The best programmer I’ve ever worked with wasn’t the person with the most qualifications, but he was the friendliest person.
The hardest part of working with a group that I’ve found is integrating all of the separate parts that the programmers create. One of my University professors once said “Programming is 75% of the development process, Integrating is the other 25%”. Now I know she didn’t include testing, bug fixing and things like that but she has a point. Integrating the separate pieces is very hard. If your team has good communication, you won’t need to worry about this as much since each developers code should mesh well. The easiest way to get around this problem is to communicate with your team members, making sure that if your code interacts, it does so properly.
Testing your Finished Product
Lately I’ve been working at a large media firm deploying web applications and making sure the websites don’t come crashing to a halt. If there’s one thing that I’ve learned about the real world of development, it’s that people don’t like testing. I know, it seems crazy, but when the clients want their product quickly and don’t want to pay the extra little bit, testing gets cut very quickly.
When you’re in school, your teacher makes you test your product, you get marked for it. This isn’t as impressive as it sounds however, since most students just leave testing to the end and don’t have time to fix anything that they have found. For students that are used to doing a lot of testing however, going into the business world and realizing that, when the money is scarce, testing is the first thing to get cut.
Consequences of a Poorly Designed Program
What happens when you have a poor design for your program while you’re at school? The worst thing to happen to me was I got a very low mark of the project, but it wasn’t the end of the world (I didn’t even do poorly in the class). In the real world, if your program is poorly designed or implemented, you’re going to have to answer to your client.
When you sign a contract to deliver a program to a client by a certain date, you’ve entered into a legally binding agreement and you have to deliver your end. If the client feels that your program isn’t up to par in any way, they can legally take you to court and sue you for the cost of the project (and more if they feel you’ve cost them money). This means that a poorly designed can cost you a lot more than a poor mark.
So, in school, the worst you can do is get a poor mark. In the real world, you can lose a lot of money, time and respect if you botch a project.
Making the Transition from School to Work
So what can you do to get ready for the workforce? Here are a couple of things that I did to get ready to program in the business world.
- Ask a friend or family member for a program that they would want developed. Once they have an idea try to get a basic set of requirements from them. This can help you understand how difficult it can be to get requirements from a non-technical person. Once you’ve developed the program, ask your “client” to see if it’s what they wanted. This will give you a sense of how well you formulated the requirements.
- Pair Program with a friend. Pair Programming is a technique where you and a friend program with each other, taking turns on who actually codes and who sits beside. It’s a good way to catch bugs, keep the code consistent and learn to program with a group. While two people aren’t the same as an entire group, it will give you an idea of what working in a group is like.
- Take a course where you are forced to work in a group. One of the best courses I’ve ever taken forced me to program with a group. It was a very challenging and rewarding experience that taught me a lot about working with a group.
- There really isn’t any way to get yourself ready for the consequences of messing up a design. Take your time and learn from your superiors and you shouldn’t have a problem with this.
If there is anything I’ve missed or any tips that you can think of to add to the list, feel free to drop us a comment to help others.