While you're in school is an excellent time to form good work habits. Making sure your stuff is that you are delivering what you are being expected to deliver, its done on time, and the work you do has been done well. All of those points are really important but the one I would like to stress for the moment is first on the list. Sometimes you are being told exactly what you need to develop at that moment and other times you might have the freedom to make your own schedule. With the latter its important to remember that you are still on a schedule! The reason I bring this up is because in game development everything is done on a schedule. It tends to be really difficult to impossible to do things out of order and have everything still do what you need it too. Everything you do is part of a greater whole, and if the pieces can't be constructed in a meaningful way then it leads to nothing but problems.
For example, a team decides that they want to start working on the Enemy AI. The Enemy AI is what tells the enemy what to do and when that it can provide a challenge to the player. Developing this AI is an iterative process, so it's going to take a few weeks to get right. So your artists start creating some projectiles for the characters so the team can see what they attack, the designers are boxing out a very simple level for everyone to move around in, and your programmer needs a simple script to find the players position within a certain range and fire that direction. What usually ends up happening (at least here is school) is someone in that group will decide that they can do something else. For the sake of argument lets say its the programmer in this instance. Instead they wanted to refine a system that they had worked on the week before and at the end of the week deliver that instead. Often this is done either because it's easier or frankly they just don't want to work on that part yet. Now when that team meets up again at the end of the week to put it all together but the enemy will just stand there and do nothing even though all the other assets are in place and the team can't test anything. So everyone gets upset with the programmer because now they're suddenly a week behind. Meanwhile, the programmer can't seem to understand why everyone is upset because after all he did work on SOMETHING that week.
I've seen nearly this exact thing happen before and the frustration of everyone else on the team at that point is really high. What this really boils down to is understanding that you are part of a team. It's not about about just delivering "something" but delivering what the team needs and when they need it.