I've posted this in the Java forums because it's about the most taught language, at least by academic institutions here in the UK, but it will apply to any taught language at any level really, such as PHP, C++ or even variants of BASIC. Please feel free to comment and add your own suggestions. Anyway, let's begin.

So, you're several weeks into your first semester of your Computer Science-type degree, and you may be struggling. Here are a few suggestions that you might want to consider.

Firstly, always test and try to understand the examples that you are given, and most importantly ask questions during lecturers. I've sat through so many lecturers where I've been the only person to speak during the whole hour or two other than the lecturer. Taking notes doesn't mean that you understand anything. Programming is fairly easy once you get your head around some basic programming principles, and a good mathematical and problem solving skills help but all of these will come with practice: believe me... if I can do it then so can you.

When you start your assignments (which are usually made up of the work-shops/practical tutorials), make sure that you read each question within it carefully. It's already broken down into manageable chunks for you so don't start another chunk of code until you've finished the one that you're working on and you are satisfied that you have met the criteria to the best of your ability, and don't be afraid to ask for help from your tutor.

Remember to comment your code. At the top of your code, put some C-style comments (or whatever is typical for the language) in with the date or version number, and a to-do list. Adding your name at the top is good practice, but sometimes Universities prefer for your work to be anonymous other than your student number. Check with your lecturer as to what to use. Explain what that chunk of code (class/method/function/sub-routine) is doing in the comments at the top. Never believe that just because you understand what the commands do within a particular syntax that you don't need comments. Good clear commenting means that you've explained your code to yourself and to anyone that's reading through it (ie, the person marking it) and therefore you understand it clearly. If you can't explain it simply then you don't understand it well enough.
Java Code:
 /**
 * Here is an explanation of the class
 * The explantion continues
 * @author: student number
 * @date: 2012-10-26
 * @version: 1.0.0a
 * @todo: I need to fix something
 **/
public class theClass
{
     // Code here...
}

Remember to align your opening and closing braces so that your source code is readable. If it makes sense to you to open the brace on the line of the declaration, then ensure that you do so throughout your code. If you prefer to put the opening brace on a new line, then again keep everything consistent. Source code is for Humans to read, the compiled code is for the computer, so keep everything as tidy as possible at source. Avoid 'over-coding' anything. Okay, so you've added a load of clever functions/methods that do great things, but if it's not in the marking criteria then you've basically wasted a load of time doing so. Think of programming like this: K.I.S.S (Keep It Simple and Stupid).
Java Code:
// Same line opening brace
public static int theMethod(int x, int y) {
     for(int i=0; i<x; i++) {
          // Some code
          for(int c=0; c<y; c++) {
               // Nested loop
          }
     }
}

Java Code:
// New line opening brace
public static int theMethod(int x, int y)
{
     for(int i=0; i<x; i++)
     {
          // Some code
          for(int c=0; c<y; c++)
          {
               // Nested loop
          }
     }
}

If you are asked to do group projects in Java or whatever, agree from the start a coding standard which will include where to put the opening braces, where to declare your variables and all of those silly little pedantics that some people spend hours arguing about. Once it's agreed and everyone sticks to it, then the source code that the group produces will be consistent and therefore one member can more easily work on another members code (provided they have commented it clearly).

If you are feeling confident with your programming, try the examples that are on Black Board (or whatever your Uni uses to post assignments and examples) in another language. Java code is often fairly easy to convert to C especially when going through the basics of programming principles, so give it a go. The more languages that you try, the more they'll become the same, and not being afraid of another language is good for when you get your first job. If you don't have time during your studies, dedicate some of the Summer in between your first and second or second and third year learning another language.

Don't be afraid of using Integrated Development Environments (IDEs). It might be cool to do all of your code in NotePad++ or something, but unless expressly told to do so, you won't get any kudos from your lecturer if you do. You wouldn't write a piece of academic writing with NotePad, so think of an IDE as a good word processor for programmers. Remember: work smarter, not harder. The time it'll take you to learn how to use an IDE will pay for itself as you continue your studies, and the more IDEs you try, the better prepared you'll be should you work as a developer.

The University is likely to only teach you so much, the rest you have to do for yourself. Universities seem reluctant to teach best industry practice sometimes, and I'd wager that many academics have spent much of their lives as academics, and little real time in the industry as developers. That doesn't mean what you're learning is a waste of time, but be aware that how you do things at Uni and how you'd do them in a real job for a real company are likely to be entirely different, so the more you do for yourself, the easier the transition from Uni to the world of work will become.

Ask yourself this... have you ever lost or misplaced a pen drive, or accidentally deleted or lost an important file? Most likely the answer will be yes. Don't keep your important assignments on a pen drive and ALWAYS use version control. This is not merely an important point, it's imperative! In fact, if you don't use version control then good luck. I hope nothing happens to your code that you can't fix or redo from scratch. Remember to commit your changes after you meet each piece of criteria on your assignment, and push those changes regularly. I have a bit bucket account and use mercurial with TortoiseHG Workbench it really did save me hours and hours of debugging on something that was turning into a rather big project. Also, when you go out to the world of work, you will already be familiar with version control as all companies should also use it. If they're not then it's something that you can recommend to the company as best practice, especially on big projects.

Please add any other suggestions or observations :-)

Regards,

Shaun.

*IMO