These are some of the principles I strive to apply constantly in my work :

1. Talk, talk, talk
   I constantly communicate with my clients. For example, before I say yes or no to a job, I want to talk about the project’s goals, restrictions, limitations and peculiarities.  I want to talk about your company’s best coding practices. I want to know what your expectations are regarding my services. When I’m working on something, you’ll receive periodic updates on my progress. And after I deliver the goods, I’ll always ask you for feedback and suggestions. Communication is always good.
2. The customer is NOT always right.
   When you hire me, you hire me to do a job to the best of my abilities. As such, if I can think of a better way to accomplish a task than the one you presented to me, I will politely suggest it to you. The final call is, of course, yours.
3. You don’t pay me for writing code
   Anyone can learn to write code. Writing code is irrelevant. What is relevant is the logic behind the code, how well that logic does its job and how easy that logic is to understand. That’s what you really pay me for: good logic that does what it’s supposed to do and is easy to understand.
4. Plan for the worst case scenario
   During software development, a lot of things can go wrong. From unwanted delays to hardware problems, things may not always go according to plan. Because of this, I have two work computers (not one), I make periodic backups of my work and all my time-related estimates are at least 20-30% higher than what it will likely take me to finish the job. All these things insure that the only surprises you’ll get from me are pleasant ones, like finishing a project 5-7 days ahead of schedule.
5. I don’t overwork myself
   A tired and stressed developer leads to tiring and stressful code. Except extreme cases, I plan my work so as to avoid becoming tired and stressed. I’ll never say I can deliver a project within 72 hours and then work 16 hours a day to do it. Code quality and health are primordial to me.
6. I comment my code
   When it comes to paid projects, I know I am not the only person who will look at and use the code I write. As such, I comment all my code clearly. I explain what my code does and why. I try and explain programming tricks or at least provide a hyperlink for further reading. This might add 2-5-7 hours to the development time, but it will save you at least twice as much in the long run. Even my personal projects have a few comments embedded in them (though not nearly as much as my paid ones), in the hope that someday they will be useful to someone.
7. I’m looking for a long term relationship
   Even if we’re talking about an one-off project, I like to believe that we will meet again in the future. I will strive to keep relations between us professional and tension-free. I won’t disappear off the map the next day after the project is over. Feel free to get in touch with me one week, one month or one year after a project is over. I’ll still be here.
8. Diversity is good
   If you always take up the same kind of projects, pretty soon you’ll get bored with your work and you will no longer improve your skills as a professional. You’ll stall. In order to avoid this, I try to diversify the kind of projects I accept.
9. I am not alone
   If I can handle the technical aspects of a project but need more man-power in order meet the deadline, I will ask you to either provide me with it or let me hire my own. Often times, especially for medium to big projects, hiring 2 or 3 developers instead of just one is a good idea. If you choose to let me hire my own help, I will take care of all the details myself.
10. Have fun while working
    I want to have fun while I work on my projects, I want to feel like I am really accomplishing something. This is of immense value both to you and to me: things always turn out better if you enjoy doing them. Corollary, I will usually turn down hopeless, frustrating projects (ex: write a Google-killer search engine) or projects that are a real chore (ex: maintenance work for poorly-written Visual Basic code), regardless of how much it pays.