Over the last 10 years I've been working in the IT industry.  There are a lot of dos and don'ts, but these are the most important lessons I've learned so far.

1. Know your business/customer

Well... you are an expert in developing solutions. Solving problems. But what problem are you actually solving? And how do you communicate your solution? You must know what your clients value. The priorities they value. Know the business of your customer and understand what they do. Only then you are able to come up with the best solution for their problems. Only then you are able to sell your solution.

2. Don't over design

Thinking about the best way to solve a problem and to design an application is fun. Here lies one of the best parts of the job! Be you must be able to contain yourself. The best solution isn't always the best design. Be careful with using patterns. Be pragmatic in the way you design your software:make sure it is build to change enough, but not to flexible. Make sure it performs enough. Make sure it is user friendly enough. You see: the emphasis is on the word enough.

3. Use and write documentation

If you don't recognize this one you must be a genius. Do you really understand code you've written a week ago?What about a month or a year? Enough said.

4. Never program more than your customer wants

Make sure you know exactly what your customer want. If you have more time than you need: go back to the customer. They will be happy with either less cost of more functionality to be added to the software. Never add functionality on your own. Easter eggs are untested functionality and therefore a security risk. Handy functionality maybe handy in your mind, but the customer may (and probably will) think otherwise.

5. The quality of a developer isn't in technical skills

A good programmer develops good software. A great programmer is able to communicate about complex solutions. Communication is the key. Without it your software will never be able to fulfill the users need. Soft skills are what makes an engineer a great one.

6. Be pragmatic, but always prepare for the future

Actually this rule is quite similar to rule 2. Be pragmatic in the choices you make. You can't predict the future (can you?), but you are able to know the point in which the software will grow. Build to change, but make sure your software is easy to use for users and in maintenance.

7. Peer review is essential

You know your stuff as other developers do. Performing peer review is a great way of learning from one another and gives you the time to discuss solutions and differences.

8. Never exchange computer time over human time

Optimizing your code is a great exercise. Make one loop a few milliseconds faster may save seconds in a function. Sometimes this is essential. But this is only when you have strict performance requirements. In most cases optimization takes a lot of time and the optimization isn't noticeable for your users. They don't mind waiting a few milliseconds and most of the time small performance issues can be solved by upgrading the hardware or infrastructure. Computer time is cheaper than human time. Think about the cost of you optimization and what the gain is.

9. Simpler is better (the newest technique isn't always better)

A simple solution is far more better than a complex one. Simple is easy to understand and implement. That leads to less errors. Developers love new stuff (don't you?). In my experience Microsoft developers are the worst. New techniques aren't silver bullets. It's cool to try new things, but realize that you should only implement new techniques if they have a clear advantage for you solution. And be realistic about them.

10. Users aren't dumb, software can't solve everything

This is one of the most common errors. It comes in two forms. The first one is blaming errors on the users (yes, sometimes it is true, but at first think of a problem you've caused). The second is trying to make your software completely foolproof. You will fail and make you software more complex. Make sure you give good and understandably error messages that help your user correct the problem. And sometimes it is better to solve a problem in the work process of your users than to solve it in the software. Your users are smart. They may not understand technical stuff as well as you do, but they know how to do their stuff (see rule 1: do you know how to do their stuff?). Users are smart and able to solve problems: you just need to make clear how to use the software and if an error occurred give enough information to solve it.