10 Mistakes I made hiring programmers that you should avoid

Here are some of the biggest mistakes I made hiring programmers. To an average person, they might not look like mistakes. But, once you get a little experience in this domain, you will understand why what I did wrong was so wrong!

(1) Initiative (or the lack of it thereof) The Los Angeles Programmer
The first programmer I hired was actually the best I have ever hired. However, he lacked a desire to get things done for me. I had to crack the whip, and visit with him regularly to coerce him to finish work. My mistake here was that I didn’t shop around to see if there was anyone else who had comparative skills accompanied by a little more initiative.

(2) Interviewing without testing: The North Coast Programmer
Many years went by and then my first programmer quit, and his helper got fired. I was left high and dry. No programmers, and no way to find good ones in a world-wide situation where there was an acute shortage of programmers. I interiewed several companies I liked. I tried to decide which company to hire purely based on an interview which was a huge mistake. The interview only tells you one dimension about a person — how they communicate when they are trying to impress you. It doesn’t tell you how they work, or if they get things done on time. The company I hired disrespected all deadlines, and even tried to cheat me several times. After that I learned that you have to try companies out with small inconsequential test projects before giving them the passwords to your main sites. Additionally, they tried to get me to communicate with the “project manager” instead of the programmer. But, the project manager didn’t make sure anything got done and was completely useless. So, when anyone tries to block critical channels of communication — fire them.

(3) Knowing the boss, but not getting to know the programmers: An India programming nightmare
I had a bad feeling about this, but I had no choice. I needed my site to be in someone’s hands who I trusted. I had known Deepak for years. So, I offshored my project to India. The first programmer he gave me was very acceptable and did good work. So, I handed my project over to Deepak. Little did I know that his programmers had gone far down hill in the last few years because the big companies worldwide had been poaching quality programmers. So, I started out with a programmer who just couldn’t function, and then fired him and moved on to another one of Deepak’s programmers who was better. She left on maternity leave and then I got a third one who was somewhat capable of doing my assignments. Had I interviewed these programmers by phone individually, and tested them on small test projects before allowing them to work for me, I could have avoided the dysfunctional results given to me. Now I know.

(4) Communication seemed open, but was blocked: The Arizona dry spell
I gave assignments to a number of other programmers who all went on strike until I found a company who seemed promising. First of all, they answered their phone. I was happy that they kept their channels of communication open as closed channels can ruin projects and have become a deal breaker for me. The trick was that they changed their willingness to communicate the minute I put my reliance in them. I could talk to the receptionist who assured me that she could relay any critical information to me. The problem was that they forbade me from talking to the programmer in critical situations and the contact person was never given any critical information unless I harassed them many times. The result was that the programmer either didn’t finish work correctly or at all, or made some serious blunders which never would have happened if he would just double check his steps with me. But, his attitude was that I didn’t know anything so I should just stay out of it. The reality is that he doesn’t know a lot of things about my site that I do know that he could have found out if he would just answer is damn phone! This was one of many deceptive things programming companies have done to me.

A quick note – Open Channels of Communication are imperative
I have a rule that all channels of communication need to be open. I need to be able to reach the programmer, the boss and the project manager if there is one. If one of these channels is blocked, then I fire the company immediately. However, if the programmer is busy and doesn’t want to be bothered — I don’t mind communicating with an intermediary some of the time if it will make it easier for them providing that they don’t cut me off completely from communicating with the programmers. Most companies don’t want you talking with their programmers, so this is a constant issue. I just tell them I’ll fire them if they don’t cooperate on this front, or that I won’t hire them for any serious work if they block communication even once. You have to stand your ground or they will keep you behind a barrier nine times out of ten.

(5) Silence at an interview: The beach programmers
The boss said that none of his seven programmers were willing to show up at an office. Later on I suspected that there were no seven programmers, just the one who showed up at the interview and sat silently for three hours while the sales manager chatted me up. I didn’t realize that someone who sits silently for so long is a huge risk. Such people do not like humans and don’t care to interact with my species either. They are dangerous if you put them on a project. Here’s what happened. We did a little test job and looked at the site at a cafe. I drove down to see them. After he had agreed to take my project and give me 20 hours a week, he delayed finishing the test project, and after I spent $800 on hotel rooms he uttered the words, “Another project” and just quit altogether. Antisocial people do antisocial irresponsible inconsiderate things. Beware. Nobody is perfect, but antisocial people are much more dangerous than the average person. Additionally, these programmers went on vacation all the time and “brought their work with them.” I don’t know if their vacation schedule caused a problem, or just their attitude of doing whatever they felt like, but too many vacations could be a warning sign.

(6) Giving the code without a deadline in Orange County
I met a nice guy in Orange County. I really liked him and he really liked coding. He described himself as a cracker jack of coding. He seemed like the gentleman of the business. Sociable, smart, nice and trustworthy. After waiting six weeks he informed me that he couldn’t start my assignment because it was in PHP and he didn’t know PHP. The code was in ASP Classic, and he had not even looked at it because he had, “Another Project.” Now, where have I heard this before. If I had given him a 20 day deadline to fix some code which only would take a few hours, then I would have been able to give the job to the next guy in line without such a long delay while my website wasn’t functioning correctly.

Another Quick Note – “Another Project”
The biggest reason why a programming company will not finish work for you, or talk to you is because there is, “Another Project.” If you test programming companies out, see how well they get your work done if they have, “Another Project.” Otherwise you will be on the back burner until you dump them for another company who does the same thing.

(7) Not getting a bid
There was yet another programmer who I really liked. He was decent to me for the most part. He had done several small projects for me. They weren’t necessarily done on time, but they got done. So, I gave him another slightly more complicated project. It took twice as long as I thought necessary and was done wrong. If I had had him give me a formal estimate for the project, I would be able to hold him responsible for fixing it and getting it done according to specifications by a certain date. yet another mistake on my part because I had developed trust in someone. Even if you trust a programmer, for well defined tasks that take more than 10 or 20 hours, get a formal bid.

(8) Testing them on easy stuff only
I learned the hard way that you have to test companies out before using them. So, I tried yet another California company out. I really liked the boss. They got 100% on my project and finished it quickly. Then, I gave them a complicated assignment and asked them to bid on it. Their bid was double or triple what I thought a top-notch programmer would charge. Were they cheating me? Were they just being careful? Or was their programmer not as senior as they portrayed him to be? A junior programmer would realistically require as many hours as they bid. The problem was that I tested the company out on easy work, but didn’t test them out on complicated tasks before hiring them. It is good to have a comprehensive score sheet on any company you hire that covers communication, meeting deadlines, efficiency, cleanliness of code, and how they function on different levels of complexity. I made exactly the same mistake with another company in India who did exactly the same thing. They did great on my test project, but then bid 800 hours on a 100 hour project that was slightly complicated. Once again, I fell into a pitfall and learned the hard way.

(9) Not having backups
I hired programming companies without having qualified backups. The result was that when they started being irresponsible I couldn’t just fire them because I had nobody else to dump my project on. I had already run through my supply of people I thought were my backups. They wouldn’t call me back or cooperate. A backup is not a backup unless you know they are going to perform reasonably. Otherwise it is like walking on a frozen pond. You put your foot on the ice and it breaks. Then you step to the left to your backup spot on the ice which also breaks, then you go back one foot and it yet again breaks. You need to find ice that doesn’t break even when you pound on it — then, you have a back up. If Warren Buffet were hiring programmers, he would probably have at least four meticulously tested backups at all times for security if he had a serious project as an entrepreneur.

(10) Giving deposits without a contract in the Bay Area
I have given many people deposits. One company in the Bay Area took my deposit and left me high and dry. I couldn’t get the programmer to return calls. I had to keep calling his boss just to get him to get back to me. What is the problem? I finally gave up. I let them keep the deposit. But, honestly, you have no leg to stand on if you give an unreputable company your deposit. And you have no way to know if the company is reputable unless you work with them. Most companies don’t have that many reviews on the internet, and those are not always trustable interviews in any case. If you have a contract that stipulates that work must be done to specifications by a certain date otherwise you not only give the deposit back, but pay a penalty for wasting my time, then it is easier to sue them when they screw up. Getting them to sign such a contract might be close to impossible, but you need some device to ensure your safety, otherwise you are gambling. Programmers are so busy these days that if you don’t pay up front, perhaps none of them will work with you! So, you are not in much of a bargaining position. So, having a contract is just a thought.

This entry was posted in Semi-Popular, Software Development and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *