Why am I qualified to write this?
I have been an independent software developer in India since 1992 and I always knew software was my calling in life. I started out by writing customised applications for the healthcare industry. This was in the days of MS-DOS – no Windows, no internet, no GUI. Today I write and develop apps for global clients. Sometimes I do it alone , other times I manage teams to do the work. The only time when I wasnt in business was when I did a 4 year stint as a Team Leader for a dot-com company. Working in a job was a piece of cake after having worked as a developer-entrepreneur. In fact I never realised that life in software could be so easy. But anyway I went back to my true calling before long and the last few years I have been doing pretty good.

I have made some good money in the last couple of years, and though I dont claim to be a millionaire , I have earned enough to take a vacation for a year if I have to, and still pay all my bills with ease. In the last 14 years as a a software developer, I have learnt a lot of things the hard way, screwed up a lot of times and gained a lot of insight into this profession. I think it would be nice if other developers who are starting out as entrepreneurs or others who find themselves in a similar situation, are able to benefit from my experiences and not have to make the same mistakes I made.

I have tried to distill the entire process of attaining success as a programmer into 11 rules. Probably there are more tips and tricks to be followed, but these 11 rules are worth their weight in gold. So lets get on to the main stuff….

Rule 1: You’re not really in the software business

“What! How can I not be in the software business. I write code for a living, man”. I know thats what your reaction is going to be when you read the first rule. I am going to take it even further and say that Boeing is not in the airplane business, Microsoft is not in the software business, McDonalds is not in the fast food business, FedEx is not in the document delivery business. All of them, including you , are in only one business and that is PEOPLE BUSINESS. Yes, everyone on earth is in the people business. You must not forget the basics. I have never seen anyone do business with animals and birds. People do business with other people. The whole point of business is to give the other person something he wants and you get something in return. Thats how the barter system started in the Stone Age days. Can you think of doing business in a world where you are the only human being left alive? Would you really bother to write code if you are the only person left alive?

So, why do you write code for a living? So that it will be useful to someone on this planet. It doesnt matter if you’re a Six Sigma black belt, or you are a PHP guru or a master in Device Drivers or a certified Java Architect, if your code is not going to be used by anyone, you may as well go home and mow lawns for a living. I know we programmers get all excited about using the latest technologies and being proficient in algorithms and try to use the latest AJAX trick. We get so involved in the actual technicalities of writing code that we forget the big picture. We are more used to interacting with the computer than with people. We feel very cool about ourselves if the computer executed our code flawlessly without any bugs. Thats one big mistake to avoid. Dont forget the basic facts of life. Somebody out there is paying for your code. And generally he doesnt care if you used design patterns or a recursive algorithm or if you used stored procedures. As long as the software does what he expects it to and as long as you did it in the expected deadline, he is happy.

So think from the point of view of the end user or your customer. As long as he is happy , you get paid and as long as you get paid you are happy. And its important that you remain happy. An unhappy programmer writes crappy code. To come to the actual point, you have got to think beyond the computer and the compiler. Stop living in an isolated world. Interact with the person who will ultimately use your software. Find out what he expects, what he likes and fulfill those needs. It will save you a lot of recoding and frustration. In other words, focus on your end-users’ needs and make sure your code does what he expects it to. Often you will find that he needed something quite different from what you thought. Faulty specs are the major cause of aborted projects. Dont fall into that trap. Get your end user involved in the development process; dont show him the app in the end after its all done and sealed. Think about the project from the viewpoint of the end-user. Above all, focus on the basics. Get the app working first, add in the frills later. Your client wont mind so much if the combo box in the ASP page is not sorted, but he will definitely mind if there is no combo box at all, because your were busy writing fancy client-side validation which he didnt really need.

The first rule is the most important and the hardest to follow, because it requires a change in mindset. It requires you to look at your software from the point of view of a human being and not the computer. If you follow this rule, you are made. You dont have even to read the rest of the rules.

Rule 2: Form a support network

This rule applies to mostly coders going it alone. Its always wise to have friends in your industry or skill domain . Keeping in touch with other people in your skillset enables you to catch the pulse of the market and industry. More important, if you get a project, which you cant handle alone or requires skills which you do not have, then delegating it to other people helps a lot. You CANNOT survive long in software if you dont have people who are willing to back you up with their skills when you need them. The support network works on the principle of “I scratch my back, you scratch mine”. I dont do web design or Flash stuff. So when I get a project for a complete website, I pass on the design work to designers who I know. They do the work and get paid from me and I realise the cost from the client. Everybody goes home happy. The designer earns money for his work, I plug in the design to my backend code, the client gets what he wants. Thats a perfect world for you. The reason for having a support network is that no one can learn everything and often a project requires multiple skillsets. In such a case, it makes sense to sub-let the work which does not involve your core skills. You may have to share the money in the end, but it causes you less stress and gets you more business in the long run. Remember Rule 1: the client wants the project completed, how you do it is your own problem. If you do a good job of the first project, he will give you more work. So even if you share your revenue with others, in the long run you make more money than if you had got stuck with the first project and the client didnt pay you.

Rule 3: Having no customers is better than having a bad customer

There are good customers and bad customers. When you start out in the software business (or any business for that matter), you are often not in a position to choose your customers. Anyone who is willing to pay for your skills is God for you, and you will bend backwards to please him, often at a ridiculously low rate. Dont! A bad customer is to be avoided like the plague, even if he offers you a million dollars. A bad customer is a liability. He is a drain on your time, money and resources.

So what is a bad customer actually and how do you identify him? Anyone who sets a lot of conditions at the first meeting or your first email with him, is a bad client. “I wont pay if ALL my specs arent working. I demand complete documentation and well commented code. etc etc”. Its not what he says , its how he says it. There are two kinds of bad clients:

1. The born grouch. He is never satisfied with anything and thinks that if he has paid you money he owns you for life.
2. The ‘Once bitten twice shy’ person. He has burnt his fingers with moronic programmers who took his money and delivered a dud. Ever since then, he considers all coders as enemies and will treat you as such.

Any customer or client who treats like you are on the other side of the fence, is someone to be avoided. Always find out info about the client, if possible, before you take the project. Find out if he is a good paymaster, if he is very particular about small details etc etc. You will burn your fingers a few times for sure, before your sixth sense will tell you when a customer is wrong for you.
So, to sum up, dont take up a bad client knowingly. You may get your money in the end, but you would have paid a far greater price in terms of losing peace of mind, stress, effort and time. A bad client is a dead end. You wont do further business with him, and he wont recommend you to others. Having no client is better- you wont earn more, but at least you are not losing time and effort for nothing.

Rule 4: Who you know is more important than what you know

One of the harsh facts of the commercial world. You may be the most brilliant programmer on earth, but if no one has heard of you, its pointless being the best. You have to let other people know how good you are. You might have to do some pro bono work, you might have to take some time out to get in touch with people who are relevant to your field of work. Network. Build up a clientele. Knowing the right people often leads to the life-changing break you always wanted.

You might get a $20,000 project because you happened to know the brother-in-law of your friend’s uncle and he was looking for someone who could handle his company’s software project. You have a better chance of making it big in software if you are a mediocre programmer but you are Bill Gates’ nephew than if you are a crack coder in Assembler but dont know the right people. Of course, you are not Bill Gates’ nephew, so how do you get to know the right people. Network, talk to other people. How do you catch fish? You go to the places where you know they live in abundance and then dangle a bait. Same case applies to software. Go to where your prospective clientele is and dangle your bait. Dont expect them to come looking for you. Get to know the right people, you wont ever find yourself out of work again.

Rule 5: Realize the difference between Visible Progress and Invisible Progress

Unless you are a web designer or a UI specialist, most of the code you write will be invisible to the client, because it never shows up on the UI. There are also cases, where your work requires no UI like embedded systems, device drivers, or database scripting.

A Visible Progress is not really to do with UI per se. Visible progress is progress to which the client can relate to , within the context of his project. You have been coding for 2 weeks and have added a lot of code, but somehow the client feels you are behind schedule. What is the problem here? Why cant the client see and appreciate all the code that you have written? This is a case of difference of viewpoint. The client has his own checklist against which he measures your progress. Your checklist of progress turns out to be quite different from his. Take this example for instance:

Client specs:

1. Write a module which captures all my conversations on MSN Messenger every time I initiate a conversation
2. Save every conversation into a separate text file.

Your work so far:

1. Hooked into the MSN Messenger Private chat window
2. Captured keystrokes in the chat window as long as the window is active
3. Ran into some Unicode problems while trying to convert the captured data from a byte array into char array and fixed that
4. Stopped keystroke recording when the chat window was minimised.
5. Extra code to capture data from multiple MSN windows if user is talking to several people at the same time.

Review date comes. Client is screaming “Why isnt the app saving the chat into a text file like I wanted it to?“. You say “Hey, I wrote code to capture multiple conversations, that wasnt even in the specs. This app is almost done and its doing more than what its supposed to“. Client says “What do I care if it captures one conversation or a hundred. I dont see even one saved conversation“. Lesson to be learnt here. You should have implemented the ‘save chat to file’ function before you went in for more exotic features. The saved file is the only point where the client can actually see some progress. You have code to capture 10 conversations together, but because the client cant see it for himself, you have not scored any brownie points with him. What you made is Invisible Progress-progress which only you can see, not the client. If you want to give the impression that you are making good progress, give him Visible Progresses. Worry about the Invisible Progresses later.

Rule 6: Honesty is still the best policy

Simple things like honesty, integrity, sincerity, reliability still count. Its very hard to find trustworthy people in the world today, so if other people find that you are a man of your word and you dont bullshit, they will give you first preference. Remember the first rule, you are in the people business. How people perceive you as a person is important. If you turn out to be a crook in spite of being good at your work, you wont get any work. Dont steal other people’s code and pass it off as yours. Dont overcharge. Its ok to charge $10 for a work which you feel is worth $5, but its not ok to charge $50 for work which is worth $5. Its more important to be a good human being first than to be a good programmer. People like good people – people who have ethics and stand by their word. Whatever your grandmother told you about the world still holds true – Do unto others as you would have them do unto you.

Rule 7: Looks Matter!

I dont mean the way you look – I mean the way your software looks. Packaging makes all the difference. A book is sold by its cover. If your app is great, but has a crappy look then you will have a hard time convincing people that its actually good. I dont mean that you must have a Web 2.0 look for your website or that you should have a draggable toolbar interface for your c++ application. Just dont make your app look clunky. A clean and elegant interface gives a great impression to the end-user even with bugs.

Looks do matter a lot! What about apps which dont have a user interface- The code/script should look good. Believe me, if your coding is sloppy and bad, it will show up to the end user. Correct code always looks good when you see it in the IDE or the editor – it looks beautiful with correct indentation and formatting. Make your app look good. First impressions matter. If you are involved in face-to-face client meetings, then you need to look good too. Again rule 1 is of relevance here. You must give the client what hes looking for: Does he want to hire a hardcore hacker to check if his ecommerce site is secure enough, then look like a hard-core geek in jeans and tshirt and a laptop. Does he want to add a module to his ERP app, look like an ERP expert with a business suit. Show the client what he wants, and you will reap the rewards in the end.

Rule 8: Price should not be your only bargaining chip

If the only way you can get a project is by quoting lower rates and prices than others, then believe me, you wont last long. How do you stand out against thousands of programmers out there? You need to have something more or different. Either you claim better qualifications or better work experience or some rare skillset. Price cannot be and should not be your primary negotiating tool.

You need to decide in your mind a minimum rate or price below which you wont work. What that figure should be, is something only you can decide. You might lose a few customers, specially who are very price conscious, but sooner or later people will pay you price if you stick by it and they perceive you as being worth the extra money. Software developers are all unique, no two people write a piece of code the same way. Its not like computer hardware, where 100 guys are selling the same motherboard and whether you buy it from Tom or whether you buy it from Harry, you will still get exactly the same piece of hardware. Software is different. If Tom makes a YouTube clone, you can be very sure, it will work differently from Harry’s version of the same thing. It will be stupid if both of them make the same pitch to the client: “Hey, I have worked with streaming media servers and I know AJAX and Mysql. I can do this in Ruby on Rails. I can build you a clone in $5000.” The client finds that both the guys have the same expertise and he is going to choose the guy who comes up with a lower price, thus leading to a price war. How to avoid a price war? Make a different pitch obviously, project yourself as someone unique. You can get a better price because of any number of reasons, some of them being:

1. You are locally based in the same city as the client.
2. You have a better work portfolio to show.
3. You have more experience than others.
4. You have got better references than others.
5. You have a better team or a work setup at your disposal.

So, dont hide under a bushel. Project your uniqueness and get a better deal.

Rule 9: Use the Pareto Principle to your advantage

The Pareto Principle is also known as the 80-20 Principle. Its applicable to almost anything in life. In the context of software development it says “80% of your revenues will come from 20% of your clients“. Out of your entire customer base, there will be only a few who will give you big business, others will give you small routine projects. So concentrate on the 20% of your clientele that gives you the big work. Dont waste most of your time writing code for small stuff. You end up working more and get paid less. Its better to work lesser and get paid more.

Using the Pareto Principle, it stands that “80% of your code will fetch only 20% of your revenues.” Find out what that 80% of your software development is all about and either outsource that part or reduce the time you spend on it. The trick is to work smarter and not harder. To use myself as an example, way back in 1993 I used to work 18 hours a day and get paid only 1/30th of what I earn today. Today I work 7 hours a day and I get paid 30 times more than what I used to earn in 1993. Over a period of time I have cut down on work which does not fetch good dividends and I have stopped taking work from clients who dont pay well or are a pain to work with.

Rule 10: Have some monetary milestones

Stick to a gameplan. Decide how much money you want to earn in the next 6 months or a year or 2 years and evolve steps to make it happen. There will come times when you will be forced to take on boring projects since there’s nothing else available. At such moments, its tempting to let the project pass in the hope that you will get something more exciting to do . Don’t. This is where your monetary deadline comes in.Your prime objective is to reach that figure at the end of the month, come what may. In the end, its money that pays your bills, helps you buy more computer stuff and pays for your broadband connection. Once you have enough money saved up, then you can afford to be choosy about what work to take. You need to stop thinking like a programmer and start thinking like a businessman if you want to make it as an entrepreneur. And for a businessman the bottom line is ‘Keep cash flowing in, screw the technology.”

Rule 11: Dont be ‘just a programmer’

Ok heres whats this rule actually means – You need to be an expert in at least one more field, apart from programming. Lets face the facts – programmers are a dime a dozen (much as it would hurt your ego to read this). You need to be something more than a programmer. You need to either increase domain expertise or level of skill or both.

Domain expertise is getting to know the intricacies of a vertical domain like healthcare or aerospace or insurance or inventory mgmt or the garments industry etc etc. You become a specialist in developing applications for a particular industry or field, by learning how that industry works. That will increase your value as a software professional a 100 times. Take for example:
If a shipping company wanted to get an inventory app made, and it had the choice of training a shipping executive to learn Oracle Apps and then develop the software OR getting a software developer to learn the intricacies of the shipping business, it would choose the first option. Why? Because its easier for a shipping guy to learn app.development and create a customised application than it is for a software guy to learn shipping and then make the software.

Domain expertise is something learned from time and experience. The shipping exec has that expertise. He knows about the little nuances and tips and peculiarities of the shipping industry and he would incorporate that into the application. For you to learn that expertise would take a couple of years if not more. Your argument: I can always sit with the shipping exec and he tells me those tips and tricks and I code it into the app, cant I? You certainly can, and thats how a lot of software is still developed. But here we are talking about you, not the software. You could utilise that opportunity to learn about the inner workings of the shipping industry and project yourself as an expert in shipping software to future clients. Doesnt ‘shipping software expert’ sound better than ‘c# programmer’?

Increasing your level of skill means moving up from coding to architecting or designing software. Learn how to develop software without writing any code – learn UML specs, project documentation, software estimation. The coder is the lowest life form in the software food chain. You need to move up the food chain if you want to get better results. Learn how to manage projects so that you can delegate the actual coding to others. Learn how to re-use code so that you reach a point where all you have to do is choose the right classes and components and assemble them to finish your project.
Writing code for fun and writing code for profit are two different ball games. You wont be having fun for very long if you dont get profits.

Well, that about sums it up. If you have been with me so far, I hope you found something useful somewhere in this article. Even after being so many years in the software industry, I still goof up sometimes..but I dont really worry about it, because we are all human and its human to make mistakes. The important thing is to realise that you screwed up and put yourself back on track again.

Writing code for a living is one of the hardest occupations known to man. Its certainly not for the weak hearted. But if you really love what you do and are determined to make a better life out of it, then you can do it. Hell, if I could do it, believe me , you surely can.