Don't trust the nice guysThis is the academic equivalent of "Give him an inch and he will take a mile." There are deadlines and guidelines. Both are there for a purpose. Sometimes, people ask you for an extension of a deadline. And if you think the person will be able to meet the new deadline and deliver something of high quality, you agree -- even more, if you think it's a nice person and everything will go smoothly. But then people start negotiating this and that and you spend a lot of time discussing and explaining that of course you expect guidelines to be carefully attended.
Don't make verbal contractsAlthough in Switzerland (and maybe in Germany, too?) contracts don't necessarily have to be signed by the involved parties, it's not a good idea to only have verbal contracts. I made this error twice. The last time, I accepted a job without even asking about the payment. I was lucky enough that the payment is OK. Before this, I got an offer including a statement about payment. I agreed, resigned my former job and started the new one. I hadn't signed a contract for the new job. Two weeks after my first day I got the contract -- with a much lower payment. It turned out that even the salary stated in this contract wasn't correct. I could negotiate a bit, but I regretted having resigned my old job.
Don't procrastinateThis is easy, you should start a task as early as possible and necessary. Most of the time I estimate the time a job will take. And I start just the estimated amount of time before the deadline. Sometimes it is easy and my estimation is correct. But most of the time it is not. Some jobs or projects take longer and then I have to work until very late, I get tired, and I'm angry about myself. Sometimes I get a job done a lot faster than estimated -- but then I'm angry about myself too, because I spend more time planning and thinking about the task and defining the best point to start than for the task itself. If I would have started immediately, I could have had more time for something else.
You always underestimate the time needed for a software project"Software project" refers to every kind of programming task, may it be small or large. Even with a lot of experience, every project is something new and every project comes with surprises. Clients change specifications on the fly, you start without any specification at all, nobody is available for beta-testing -- it just has to work now! --, you don't have a backup structure or even a backup strategy. You spend hours with debugging, because you have been interrupted in the middle of programming a structure. You work with a not-so-mature framework. Documentation is only available for a different version of the framework than you are using. The data you work with is bigger than expected and interactive processes have to be transferred to batch processes.
But what to learn from all this -- don't program at all? The better lesson is probably to learn to estimate better. Somewhere I read that for programming you estimate the time needed, then double the amount, and then take the next larger time unit -- for a task estimated to be done in one hour, this will result in two days you should allow for.
End then you have to take into account the user of the code you produce. If it is only you, you can skip comments and keep it simple (like using default variables, anonymous datastructures, short versions of control structures, etc). For other programmers being the users, you need to add more information and you should do error handling. The next step would be a program someone will call from the command line. Even more effort is needed for a web application. And even more time you need for adding a nice GUI and converting it into an actuall application. I think there was an article in the Communications of the ACM some months ago basically saying that each step increases the time needed by factor ten. And of course being a computational linguist, most of the time your "clients" will be linguists or other non-technical users -- so whatever you program it has to have some kind of interface and user guidance. Meaning that you are creating actual applications, not scripts that just output a number or a string.