If you think bottom line for your customer it will be noticed. At Telvent, I worked not only on projects but also how to make design itself better and faster so that Telvent could hire lower paid designers to use the higher paid engine design that I developed. This creates a demand for what you are doing since you are so far ahead of the curve because your designs start designing themselves that you will always be in demand. It is a win-win. Here are some other tips that keep you looking like a professional and never like a bafoon. One caution however is to market what you are doing. If you don’t the extra time you spend upfront getting the customer better and faster might make you look like you are wasting time. Show the customer how it is a win-win or a triple win which it usually is – the last win is the customer being able to design the next iteration with cheaper staff or in half the time.

At first this seems to take more time, but as you get successive wins under your belt (and hence the customer’s too) it starts to get noticed that you can do just about anything.

Here are some tips for designing in a win-win way

• think modular design – how can what I do be a class or a reusable part. How can once piece of lego have just one more hook that I can use in the future. Watch out that the complexity stays easy to configure though
  • think toolbelt. The more tools you have the faster and more stable was the design
• document document document your code. Blog so-to-speak what you do day to day and explain to yourself what you are trying to accomplish. In the immediate it helps you even explaining it to your customer or others who interface with what you are trying to accomplish, in the long run it helps your customer
  • for .net for example, learn the sandcastle documentation rules. It takes an afternoon and about 4 days of using it and you have all the rules in your head. Keep it up or you will start to lose it
  • learn the rules for php doc, Java doc or what ever else you are using to document your code so that a machine can cobble it together
  • document on the side with Word (words and final pics) and Powerpoint (generating pics) since they are so prolific and seemingly universal. You can use proprietary software but Work and Powerpoint are everywhere your customers are and hyperlink quite well
  • use wiki’s for communication between collegues – they can edit the doc to be even better than you alone can accomplish – the power of  collaboration
• Use a code repository. I have used SVN, GitHub and Mercurial. Using a back up program does not cut it – I have tow of my own personal prize apps for iOS – luckly these were personal projects
  • SVN is the best for versioning binary files since you can lock others out while
  • GitHub and Mercurial are great for multisite collaboration or a regimented distribution system to the end customer. Slow and steady wins the race.
  • be verbose in your comments
  • never procrastinate with getting code into a repository and schedule time at then end of each day. Once a VM went on the fritz and many fellow coders had to redo the code – not so with my code – thank goodness I followed the golden rule
• Never hard code – no matter what the pressure. If you do – use the well known phrase “TODO” in your code and schedule a time in the future to work this code from hard coding to dynamic design. This makes you look like your intentions were pure which they are. Document when you hard code and mention ideas to work this out to a config file or config-array in the future
• keep todo lists
• keep people informed of what works and what is left to go in black and white. This is where wiki’s or published excel sheets are so handy to clarify what is done and what is to go
  • write down – I repeat – write down where struggles are occurring so others can help with experience or with pulling strings to get items out of your way
  • never ever assume the other person has heard you – it takes 7 times on average before someone ‘gets what you are really saying’
  • keep track of your hours and publish/communicate them frequently
• put larger goals aside to get quick wins for you and your customer/boss. If it is important to them, it should be important to you. Agree to disagree sometimes and get items done that satisfy others if they deem it important

These are some of the basics of programming and half has nothing to do with coding itself but the practice of communication, politics and being organized. If you practice these thing then good things will come.

Please add comments and I will work them into the text above for others.