The Destruction of the Head Hunting Industry

This is a random thought that just popped in my head.

With information becoming increasingly available, I’ve been thinking that the head hunting business will go through a major destructive phase in the next few years. There’s two things the Internet changed:

  • Better distribution of information on job openings
  • Better distribution of information on candidates

Definition: For those of you who are unaware, head hunters are professionals that search for employees and pair them up with open positions in companies. In a typical scenario, a company will pay a recruiter (head hunter) a fee that equates to 2-3 months of that employee’s yearly salary. Companies pay this because recruiting employees is expensive. I’ve done a lot of hiring in the last few years, and I know how time consuming it is to review hundreds of resumes and then interview. A head hunter is basically an outsourced HR department. Additionally, candidates often approach head hunters who re-post job openings in various job boards.

And there’s a third trend that will come based on increasing information available to the public:

  • Automation of job and candidate pairing

A long time ago, I was business partners with a man who was formerly a head hunter. I remember him telling me how wonderful the internet made his job. He told me that when he was my age, recruiting meant shaking a lot of hands, memorizing every face and name you ever met, and storing large piles of business cards. For him, recruiting was now about posting jobs on Craigslist and Monster and referring the candidates. To him, he was still the gatekeeper. These days, anybody can be a headhunter with a little Internet know how.

head hunter productivity chart
head hunter productivity goes up first, then down (we are in the middle stage now)

However, sites like LinkedIn can change all that. The one true value proposition that head hunters provide is that they serve as match maker. But as more information is available and technology improves, this process should become more and more automated. For example, right now, LinkedIn has job postings. On its own, it’s just a new competitor to Craigslist, but what makes things interesting is that LinkedIn also has the data points to find all of the candidates out there that might fit the job requirements — without anybody lifting a finger.

Right now, the information stream is mono-directional: job postings (and recruiters) broadcast information. The goal is a bi-directional system where seekers fill out their requirements (a.k.a. their resumes) and both sides let the system do the matching. This can only work if both sides have maximum information about the other. Think of it like dating site for job seekers. It’s a hard problem to solve given the time-sensitive nature of job searches, but it’s an inevitable outcome as more and more information centralizes onto the Internet.

5AM thought of the day.

A Great Web Developer is a Great Application Developer

After being a part of the developer hiring process for a while now, I have begun to see what distinguishes an exceptional web developer (the ones that get hired faster than we can even make an offer) and everybody else. Things have changed since 1995 – web development requires actual knowledge of programming!

The problem is that people think web development is somehow easier than other types of development. Nothing is inherently easier about developing an application in PHP than in C++. While I could accuse people who say this as being naive, the truth is that web developers themselves seem to hold this as the truth. In order to excel at being a web developer, one must understand how to develop an application. In other words, there are very different skills required in programming something like Facebook or Digg than for updating Mom’s store website.

First, you must actually understand object oriented programming (OOP). Everybody these days says they “know” OOP. I don’t mean “you read about it in a book” or that you can use a class when necessary; I mean being able to write extensible, modular libraries. This takes time and practice. When people first begin writing classes, they mistake the process for “grouping up functions under one class name in one file.” This is dead wrong and actually counter productive in some cases.

Classes are about automation and simplification. The classic analogy for OOP is a car because it has many parts that make it a whole. But just like the driver has no idea what a crank shaft, piston, or fuel injector does, people using your class should have no idea (nor need to learn why) about the inner workings of your class. All they need to know is that calling one of the few public methods (turn_ignition(), step_on_pedal(), steer()) does a whole lot of cool stuff behind the scenes that makes their life easier. And just like how you wouldn’t want the entire car engine welded together (instead of using bolts and screws), you shouldn’t write humongous class methods that do 1000 things — break it up into digestible parts so that other people can enhance just the pieces they want (see “overloading” below).

When you design a class, you start by listing out things that the class will be used for. Then, you figure out the lowest common denominators between these actions to remove “special, one time cases.” You now have a list of your primary public functions. Everything else in your class should pretty much remain protected or private (discretion is learned with experience). The entire point is that classes are not a group of similar functions, but rather a single conceptual unit.

And when you’re all done with understanding why object oriented programming exists, you must then learn to use Inheritance, and Overloading (some languages) and Interfaces.

Second, you must understand and demonstrate competency with design patterns. At the very least, you should be aware of the Singleton and Factory patterns, which are very commonly used, and for (arguably) good reasons. Knowledge of basic design patterns goes a long way because a time will come when you may need to borrow from one of these concepts when developing your web application. It also means you have a wider exposure to the different types of architectures available to someone writing a library or application.

Last, you must understand scaling issues in growing web applications and how to resolve them. This is probably the rarest trait, but if you have it, you will shine like a rock star. It is important to realize that certain operations are much more costly than others. In today’s world, the CPU is rarely the bottleneck, but there are still bottlenecks. A common instance of this problem is when Word Press blogs go offline because it is slammed by a spike in traffic. That said, the most common type of bottleneck involves the database and often manifests in one of three ways:

  • Each query sent to the database involves some small amount of lag between the web server and the database server. Hundreds of queries on a page will slow down your page loads. On high traffic pages, one less query means thousands of queries a second. Make sure you learn how to do JOIN statements.
  • Each query must use an index in the database. Without this index, a query looking at a large table will bottleneck the hard drive (because it has to search large portions of the disk). Learn how to use the MySQL command: explain.
  • Database tables using MyISAM (instead of InnoDB) risk facing table locking issues. When you run a big or complex update on MyISAM, no other updates can occur on that table until the first one is done. If that table is very large, this may mean someone’s page sits there and loads for a long time (or times out). Typically, one should use a transactional database such as InnoDB.

Other types of common scaling issues are:

  • Session management on the database instead of letting PHP handle it. This is an issue because any large web application has more than one web server which means when a person hits a new page they might be loading from a different web server each time.
  • Managing files generated on the server – such as when a user uploads a file. The issue here is that if a file is created on one server (in a cluster of 100), how do the other servers know it exists? Obviously the solution is to somehow centralize this with a synchronization process or store all of the files somewhere else.
  • How queries can start acting different (much slower) when your tables reach 1M+ rows without proper precautions. Larger tables change things because indexes sometimes stop getting used or slowness that wasn’t apparent before is now very noticeable. (A book could be written here…)

Merely reading and understanding these issues has put you ahead of a bunch of people out there. 🙂

In conclusion, you must re-think the “web developer” as an application developer that happens to work in a browser. I often hear the excuse that these types of advanced concepts can’t be readily applied in small-time applications (such as a simple store-front), but I believe this is simply not true. Virtually every site requires a database connection or a template system (for easy inclusion of header/footer files). Database abstraction and template systems are probably the single best place to use OOP concepts. It simply makes no sense that one would use the raw mysql_query() function in any website, even if it’s just Mom’s baby pictures. Putting these ideas in classes reduces security vulnerabilities and makes development much faster. If the notion of abstracting templates or databases is totally foreign to you, I suggest you start by looking at Smarty or EzSQL.

Happy studying. 🙂

The Difference Between a Smart and Dumb Entrepreneur

Do you have the business intelligence to bring on a smart technical partner? Let me share with you a little story so you can answer that for yourself.

A year ago, I was approached by a person who was doing a start up. He invited me out for dinner to talk about the venture. He made me sign a non-disclosure and then told me all about his idea. As I listened, I became convinced his idea hadn’t been thought through. It lacked a solid revenue model and had no business plan. He had failed to do research such as costs of operation, primary competitors, and whether or not there was even a demand for his idea.

I politely told him all sorts of issues he needed to address before I could consider his opportunity. I gave him a lot of free technical advice as well as some suggestions for revenue streams. He wrote it all down, shook my hand, and the meeting ended.

A week later he emails me a document. The document was clearly rushed (grammatical errors abound). Nevertheless, it contained a business model, use cases, and other important considerations I had asked him to make. I was a little taken aback that they were rushing such critically important steps, but I let it slide. He offered me a substantial stake in the company in exchange for technical guidance and some (relatively easy) development work.

I took a week to think over the idea. I decided the idea was simply not good enough to succeed. I declined his offer and told him I would be happy to give him advice as he needs it on a casual basis.

I received no reply.

Months go by and I read news about another startup doing something very similar to what he was doing. I sent him information about this startup in hopes of helping him out.

I received no reply.

That was the last time I decided I would offer any form of help to this individual.

My story illustrates some important things this man did wrong:

  1. He rushed a business plan on an idea that didn’t sell itself.
  2. He decided I wasn’t worth his time since I wasn’t going to join his company.
  3. He made no attempt to leave me with “good feelings” about the company.

The point of this story isn’t whether or not his business succeeded (it did not, as far as I know); rather, the point is that good will shouldn’t be needlessly ignored. If you plan on starting a business one day, I hope you are taking notes! Allow me to address each mistake:

  1. He rushed a business plan on an idea that didn’t sell itself. Some ideas are so revolutionary that a business plan tends to write itself without much thinking, but most aren’t. His wasn’t. The planning stage is crucial to the long term success of your company. Without a full understanding of your market, you are driving blind without any knowledge of obstacles (competitors) or a destination (customers).
  2. He decided I wasn’t worth his time since I wasn’t going to join his company. Business is just as much about who you know as what you know. A contact may not come through this time, but you never know in the future. Burning bridges with people who aren’t your competition is what dumb people do. Kevin Federline has a rap CD because he married Britney Spears. iTunes has content from Disney because Jobs is on Disney’s board of directors. Kevin Rose gets attention for his newest startup because he founded Digg.
  3. He made no attempt to leave me with “good feelings” about the company. It should be the #1 priority of any business owner to make sure every potential customer, partner, and employee feels positively about your company. There is no reason to be pissing away positive karma. You never know when someone you were a jerk to might later be in a position to (not) help you when you need it. Again, it’s who you know and if they like you (see #2).

The sad part is that this isn’t the only time I’ve seen someone make these mistakes in front of me. A few times a year, I receive offers from entrepreneurs of new business ideas they want to “share” with me. Some people do this well, and I gain respect for them. But most people suffer from extreme self denial. The problem is that people get too caught up in their own world/ego to realize that they need the help of others far more than those people need them.

In summary:

  1. When trying to recruit, make sure that the other person walks away feeling like they might have missed out on something really great.
  2. Someone you are a jerk to now might be your boss, partner, or competitor later. Be nice. The business world is smaller than you realize.
  3. Success is in the execution, not the idea itself. Good execution begins by building a positive, professional image.

If you’ve ever wondered why highly successful CEOs tend to be extremely friendly people, now you know why.

Why Being Hard to Replace is Bad

I read something I’ve always followed without realizing exactly why:

Don’t be irreplaceable; if you can’t be replaced, you can’t be promoted.

I once worked with two programmers who told me they purposely wrote convoluted code. When I asked why they would do that, they replied, “Job security.” I always wondered why that company let its employees do that despite the impending likelihood that they would eventually quit and leave their mess for someone else to clean up.

Ever since then, I’ve always advocated for strict adherence to coding standards and frequent code ownership swapping. I’d like to add to the advice:

Nobody will choose to promote an individual who screws the company over – on purpose – on a daily basis.

I thought that was a neat tip to share on a Friday. 🙂

10 Questions to Ask Yourself before Doing a Startup

I know a lot of people who have dreams of striking it rich on the web. Unfortunately, a shocking majority have frighteningly similar “business” ideas. All things being equal, here are some questions you should ask yourself before starting a business:

  1. Did you share your idea with others? Your idea isn’t going to make you rich; the execution of it will. Thus, spreading your idea around to get feedback is very smartAnd nobody is going to steal it: they know they are already months behind you – if anything, they will ask to join you. Spread your idea and get feedback from people you might call a casual acquaintance. They are your best source for honest feedback. Make sure it has appeal before you waste time doing something that nobody wants. (See #7 for more on why you shouldn’t be afraid of idea theft)
  2. Name the top five largest companies in your market. Can’t? You lack market research. It is important you recognize the current top players in your market so that you can avoid being trampled by them. If you don’t know the top five, you are substantially more likely to be doing work one of them is already doing. Aiming for #1 is great, but to get there, you have to pass #93,513 all the way up to #2.
  3. How much revenue do you expect one customer/user to generate, on average per month? If you are just guessing based on what sounds reasonable, you are essentially hoping your business plan is viable — And no investor would ever back you. Good gamblers stick to calculated risks; bad gamblers play roulette.
  4. Does a Facebook group cover your “niche?” If your idea is a social networking service, quit now while you’re a head. Sure, there’s some untapped niches out there, but I would wager money that the odds are in favor of starting a restaurant (10%) over a social networking site (less than 1%).
  5. What happens when the #1 player in your industry notices you and copies your idea? Are you screwed? If you have no contingency plan, you need to address if your idea is viable. It also shows how unsafe your business idea is from other businesses that will inevitably copy you. In order to keep others away from your idea, you need a leading expert in your field, a unique client base, a large initial audience, or a significant technological (or patented) edge.
  6. If your goal is to be bought out, ask yourself why they wouldn’t use that money to build an in-house clone. As in, if you want to sell for $5M, maybe you should ask yourself if your technology is so incredible that they couldn’t reproduce it for $4M and 12 months. The larger the company, the faster they can reproduce your work. Think about it. Features are worth nothing when you are measuring a buyout price since it’s trivial to copy them.
  7. Are you the best person to be executing your business plan? You better believe it. If a business owner is inept, his poor decisions and management skills will kill the company. If his employees are dumb, the same follows. If you don’t see yourself as exceptionally talented at hiring other exceptionally talented people (and keeping them) then I don’t think you’re ready to be leading a company. Please note that great programmers don’t necessarily (and often don’t) make great CEOs.
  8. Do your revenue projections assume profitability to be attained within six months? If so, your projections are entirely unrealistic. You should expect zero revenue the first month, for starters. You should have enough money saved up to run entirely at a loss for the first year. If you haven’t even done revenue projections, you are in bad shape.
  9. Do you already have your first user/client lined up? The answer needs to be yes. Without real users, you are assuming what they want. Your users are not you, and what you find acceptable or straight forward will often not be the same to them. Without a real user to act as a tester, you will end up producing something that nobody wants to use, even if it tries to fill a real need.
  10. If you are doing social networking: are you assuming an ad click rate of 0.5%? If so, you are already in trouble. Myspace reported their click rate is 0.10% and Facebook’s is 0.05%. Also, abysmal click rates tend to come with abysmal click prices. Make sure you know the reasonably expected click rate, which fluctuates greatly depending on the industry.

The bottom line is to ask questions. Starting a business involves an exceptional amount of time and money. If you can’t do the due diligence to make sure you are investing your time wisely, you are setting yourself up for failure.

Five Things New First Time Employees Should Know

Just out of college? New to the work force? Here’s five tip that you should keep in mind.

  1. Assume the world is tiny. Perhaps the biggest eye opener is just how small the working world is. People in the same industry routinely work together at different companies over their career. But this also means your reputation at one company will likely follow you to the next, and the likelihood of this increases as you work at more places. It doesn’t just stop there. Managers and executives at companies often know each other through their careers. This means one bad piece of history might haunt you at several potential jobs in the future. As such, don’t burn bridges, ever. Even if you are the guy firing somebody, be nice. You never know if next time they’ll be your boss (no, seriously, this is more common than you think).
  2. Respect seniority of everybody, especially those below you. This sounds obvious, but sometimes you work with people that seem less intelligent, less capable, or less motivated than you. First of all, that’s based on your limited understanding of the business, and second, you haven’t figured out the political state of the office. As such, don’t step on the toes of co-workers, regardless of their position. Some times, the people below you have the ears of the people above you. Besides, being nice is a Good Thing (and, see #1).
  3. Make your suggestions count by limiting them to a few good ones, rather than many poorly thought out ones. As in, don’t give suggestions early at a new job. I know some people might disagree, but let me explain. You might see it as a cost reduction measure, but others might see it as quality reduction or removal of an important sanity check. Anybody can walk into a bank’s mainframe and give a million reasons to upgrade the 20 year old UNIX build to something more modern, but this only makes you look naive and misguided. Before you suggest using Ruby on Rails instead of ASP, it’s better that you yield the decision until you have a fuller understanding of everything happening beneath the business hood. Business decisions are often limited by constraints that result in less than ideal solutions – but this is reality. The key is to understand which constraints can be manipulated. This can’t possibly be done effectively by somebody who just started.
  4. Assume your Internet activities are being watched. If you work for bigger companies, it is highly likely that the computer you are using has key logging or other “big brother” software on it. How likely? According to PC World, 60% of companies monitor where you visit, 50% monitor your email, and 20% monitor IM chats!
  5. Don’t engage in side projects. When you’re still learning the ropes, it is expected that you are committing 100% of your professional time to the new job. So save yourself the headache and preemptively decline all side jobs for the first six months of your employment. If you have time to be doing side jobs when you are just starting out, you are probably not focusing enough on your career. And this is exactly how your boss will feel if they catch wind (see #1) of this activity.

Agree? Disagree? Let me know.

Programming Contract Work Tips Part 2

In my other article about contract work, I gave general tips on what to watch out for when defining a contract. This article will:

  • Discuss intellectual property concerns most of you probably never even thought of
  • Give tips on how to build your portfolio if you are just starting out as an aspiring web developer
  • Expand on points from the previous article based on the feedback I received

This article is geared heavily toward web developers and will no longer apply as readily to other types of technical contract work. For example, for design related contract work, it is very common and standard that you own no rights to the works you produce (such as a logo) whereas such a point is not always the case in web development. Nevertheless, I tried to keep things generalized so more people can benefit from reading it. 🙂

Intellectual Property Concerns

  • Before anything else is hammered down, negotiate for joint ownership of the code that you will write. This isn’t always possible depending on your client, but I believe this is worth discussing. If you do not state this up-front, and don’t have a written record of the conversation, you just did work-for-hire, which means you own nothing. I am talking about retaining copyright. They retain ownership of trademarks, trade secrets, or patents they already own that you might leverage during your contract. You’re really only interested in the libraries, not the implementation portions (non-class/function files). Clients won’t – at first – like the sound of this whole “sharing” of rights business, but in reality, it means they can distribute and modify your code any way they please. It affects you because you are able to use snippets or libraries without liability in future projects. If they are not sold at this point, I always point out that the reason I am able to promise them faster development with less buggy code is that I have a well-tested library from past jobs that they will be benefiting from. Frankly, if they still can’t accept the idea of a mutually beneficial agreement, I move on. But most clients usually don’t care after I make that last point. Again, this will depend largely on the type of client you are dealing with (big bad corporations versus mom-and-pop-shops).
  • Make sure you have a discussion with the client about open source software (OSS). Remember that you can’t promise that they can keep the application proprietary if you use certain OSS licenses. Make sure they understand the ramifications of you incorporating OSS into the code (i.e., they may have to distribute the source). If you are developing a web application, this will likely not be a concern. If they don’t plan on distributing the code you write, this won’t apply either. Remember that there are many open source licenses out there and that one may suit their needs (check the MIT license).
  • Even if your client approves of using OSS, decide on your own if that is a good idea. Know the differences between the various licenses. Typically, I avoid licenses that “infect” my entire code base when I am only using a library. As such, I try to stick to licenses like LGPL when I’m using libraries. This is so that I can retain 100% ownership of the code. Please, respect license terms of code your borrow. 
  • Always remember to add your signature in the source code, especially in libraries. This is so that future maintainers can contact you and disputes about ownership can be proven. This would include:
    • Your full name
    • An email address
    • Licensing or copyright terms, if any
    • Date
  • Make sure they own and register any domain names. You do not want to be bothered or responsible for owning their trademarks!

How to Build a Client Base – Web Developer Style

I had a fair amount of success when it came to getting clients long before I had my first programming job, and without any prior experience to show for it. This section is for aspiring developers hoping to gain experience and build a client base at the same time. Here’s how.

Disclaimer: Before I say anything, understand that contract work will not be a full time job, or even pay rent, for some significant amount of time until you build a client list and a decent portfolio. Many people keep contract work as a side income.

  • Partner up with a designer. It’s best if you know this person in real life. Agree that you will split the pay 30/70 on sites with little or no coding, and 70/30 on database applications. The work won’t always be 50/50 or even 70/30, but it will help both of you build your portfolios, which is critical for mutual long term success. This is a fair deal for anybody starting out. Also, agree that you each own 100% of your parts of the project, but retain rights to claim the entire finished product as something you worked on. Picking a good designer is crucial.
  • Now ask friends and family for anybody that needs a website, and do it for cheap. Here’s the catch that will help you get the ball rolling: if this is your first job, offer to do an entire site, with two design drafts, for only a couple hundred dollars (my first one was $250) with free support for a reasonable timeframe (a month). But the catch is that they must allow you as much time as you need. Almost anybody will take your offer. This is awesome for you because you are able to essentially learn and work on a hobby project at your leisure, but then get paid at the end! Make sure you do it in a timely manner (under 6 weeks).
  • Choose your first project carefully. You will underestimate how difficult a project is. Do not, under any circumstance, agree to do a full content management system, forum, ticket system, or other heavy database application. You might finish it some day, but not without a ton of frustration and lowered expectations. It’s your first project: start small and grow organically. Try to do them a company or personal website that has a comment form, PayPal order system, or other relatively simple concepts. The moment you try to duplicate a major commercial product as your first project, you should realize you are probably shooting yourself in the foot.
  • Each time you complete a project, up your rates by a hundred dollars. The beginning is slow, but if you are good at what you do, you will receive new business in no time. Eventually, you will start to see what your market hourly rate is.
  • Part ways with the designer once you complete half a dozen projects, but stay in touch. Hate designing, but the job pays well? Sub-contract it out to your designer buddy! Is the job 90% design work? Just give it to the designer and take 10% of the pay for your part! The point is, you can each build up your own client lists while maintaining a mutually beneficial relationship with someone you have a proven work history with.

Closing Points

  • On getting things in writing: all communication should be done over email. If something is said in person or over the phone, always follow up with an email confirming what was said. This goes back to the idea of having things in writing. Email records will act as evidence if you have a dispute. It’s a clever way of making sure everything is in writing without needing signatures and lawyers.
  • On getting paid: host the code on your servers until full payment has been received. Don’t develop on their servers unless you really trust them or need the development environment. This is because underhanded clients may try to screw you. If you have all of the source on your servers, in a worst case scenario, you spent three weeks writing a cool application on your free time to add to your portfolio. If they screw you, keep the code and make sure to give back any money they fronted you.
  • On getting feedback: when web-developing, always start with a mockup. Create some basic HTML pages to show the client. Keep it bare and ugly, but functional. Tell them to ignore the ugly look, but instead comment on how the page looks like it would work. Are there the correct input boxes? Are all the fields there? Are all the pages to be expected in place? You will use this mockup code later when you fill it in with real processing code. I can’t stress the importance of this development concept in terms of saving yourself time. Oh, and keeping it ugly will force them to pay attention to the stuff that matters: functionality.
  • On aligning their expectations: after you pass the 85% completion mark, begin focusing your attention on how it works, not what it can do. Clients may initially judge your product by how it looks, but in the long term, they will judge it by how it works. This is different from what it can do. You might make the most advanced car ever made, but if the driving experience sucks, next year’s model will not sell. It’s the how, not the what. Non-programmers will always choose “easy” solutions over “difficult but more functional” ones. Just look at the iPod. When trying to figure out the user interface, always ask yourself, “Is there a better, more intuitive way to present this so even my mom could understand what this page does?”

As a side note, I am a developer today, thanks largely in part to my early contract work. It taught me a lot of important skills about managing deadlines, predicting development timelines, and interaction techniques with clients. Most of all, I graduated college with real stuff under my belt, unlike many of my peers who only had homework assignments to show for their experience.

Programming Contract Work – Tips on Protecting Yourself

I did contract work for three or four years before I finally threw in the towel. It’s a lot of work, and very frustrating at times. I was very fortunate in that I never got screwed over, but many people have. Here’s my tips on the subject:

  • Everything must be in writing. Especially the points in this list. You don’t need a contract; just make sure things such as pay, deadlines, support, and features are written down for reference in the future during a dispute.
  • If you can get hourly pay where you bill them what you work, do it.
  • If you can’t get hourly pay (99% of the time), take an entire extra day to think about how long the project will take in terms of hours. Don’t guesstimate – actually tally it up hour by hour, feature by feature. Add in 10% for the fact that you will have to break up the work over many days, slowing down your train of thought. Add in another 30% for bug fixes (even if you already added it in, trust me). Add in another 10% for features they are going to toss after you’ve already decided on a “final” version. Don’t tell them about any of this extra time you are calculating. Demand that many hours paid for the project. You will very likely still end up going over what you expect.
  • Now work forwards and figure out by what day you will have the project completed. Add a week and round it forward to the nearest Tuesday and give them that day. Trust me. This gives you two extra weekends if you get caught up on something else.
  • If you are being paid a lump sum, be paid 1/2 up front with the rest, in writing, to be given on the date agreed (the Tuesday mentioned). Make sure you have their name and address in case you have to use the court system. Remember that if they didn’t keep their end of the bargain and pay you what was agreed upon, they are committing intellectual property theft.
  • Fight feature creep. Agree, in writing, on what constitutes “completion”. This requires a breakdown of all features and pages that must exist. Make sure it is very detailed, and make THEM do this work since creating the specifications for what the product should do is not your job! This will be the bible of your obligations to the other person. If they “forget” something, that’s not your problem. You will live and die by this list, and it will determine when you can say you are finished. Once you agreed on a price and start writing code this list is written in stone. Make sure you make this clear to them up front. Allowing them to add to this list is like letting them push back your pay day. This is not to say I never throw in free features, but at least I made them aware that next time, I might charge them.
  • If they insist on adding a major deadline-altering feature that is not on your feature list, they have two options: pay you on the original date so long as the original pieces are done, or tack it on as an additional project after your second pay day. The point here is that you want to make sure feature creep is as expensive to them as it is to you. One “little” feature goes a long way in delaying a project if it happens 30 times. This sort of talk will make them think long and hard before making you add in a new feature. I always give this sort of warning up front, and my clients have been very good about refraining from wanting new features that they think of. They’ll even say, “We can do it on the next version or something…” If you let your clients walk on you, that is your fault.
  • As for the rate to charge per hour, take your normal hourly salary that you get paid at your day job and multiply it by roughly two. Because you have to worry about your own taxes, the income is not steady, and the project might take longer than you anticipate, this is a very standard thing to do. Again, don’t reveal how you arrived at this number. Keep in mind that when you are first starting out, people will be weary of a high rate, so be sensitive to that when determining your price. As a point of reference, I had a friend who had to pay a sys admin $300 for two hours of work. Contract work is like that. A programmer should charge anywhere from $20/hr (high school student) and up. If you have kept a job as a professional programmer for long enough not to be “junior”, charge no less than $45 an hour.
  • If you get a weird feeling that they can’t be trusted, don’t do it.
  • Make it clear they are getting the code from you “as is”. They will know what this means. For your reference, it means you are not responsible for it breaking, being buggy, or not doing what they hoped. As a courtesy, I usually provide free bug fixes and support for the first two weeks. After that, I charge them hourly. Of course, all of this is also mentioned up front.
  • Don’t agree to make something you aren’t sure you can do in time. If it’s beyond your skills, tell them. They will either find someone else, change the specs, or let you lower your rate in exchange for more time. Things are always negotiable, but never agree until you know you have sufficient time.
  • If you are doing design work, agree up front on the number of “drafts” that will be reviewed before a final non-refundable revision is given. A typical number of drafts is two.
  • I have used the “draft” concept with programming work as well. This means presenting them with a half-working “draft” 3/4 of the way into the project. This helps to ensure I create what they are expecting. I usually allow for minimal improvements or suggestions to be made at this point, but if a big change is made, I always point back to the original document and ask that I be compensated for the new work. Usually, you will find people just shout out cool features without thinking about if they are worth paying money for. Putting it into perspective will always help in keeping feature bloat down.
  • Expect follow up support requests for months. Code is never 100% bug free. Just as an example, I had people emailing me about support requests three years later because they wanted the email address on the site changed! I only do free extended service when the bug is critical or due to my own oversight of the original specifications. The rest, I’m afraid, I can’t do for free. Neither should you. If you do it for free anyway, you’re either a chump or a really nice person — they’ll know the difference by this point. Let’s hope you do too.
  • Make the customer happy. I know the above makes it sound like you’re going to be a jerk to the customer, but in honesty, a customer will be happiest knowing all of the little details up front. Keep an open and accommodating line of communication and I promise your clients will be pleased. Remember that it’s not about who-needs-who, but rather, it is a symbiotic relationship. Bending the agreement in their favor (doing touch up work for free) is at your discretion, but always make sure they realize you’re doing it because you are a nice person, not because you are obligated to. Remember that they aren’t going to give you money just because you ask, just as they shouldn’t expect you to give them work for free.
  • Be prepared to get screwed if this is your first contract job. If you don’t know the ropes, you will underestimate the project difficulty, underestimate how often your client will change their mind, and miss your deadlines. Additionally, many of the hardliner approaches I list here will be more difficult when you have zero experience to prove you are trustworthy. On your first project, make sure you learn from your mistakes and be prepared to get stung a little. It’s normal.

I hope this helps! Don’t get scammed (NEVER WORK FOR FREE)!

Dating and Job Interviews

This post is short and sweet. Hopefully, this is self explanatory.

Jackson: Hey Michi, if cover letters are that important, why do almost all the ads I’ve seen only ask for resumes?
Michi: It’s like going on a date… You COULD bring flowers and it WOULD make a nice impression… But who does?

(Of course, the answer is: the really motivated people.)

Social Networks Usher in a New Era of Mankind

I read an interesting article about social networks and privacy today. The article explains how damning social networking can be to an individual. I agree.

It doesn’t matter if you think photos of you licking tequila off a person at a party seem “okay” to you now. It may seem “fun” to you now that there’s a photo of you streaking across the street. It may seem totally “normal” for you to be breaking the law and drinking when you’re only 20. And if you’re lucky, all these things will remain “okay” for years to come. Unfortunately, it’s increasingly likely that an innocuous “joke” comment you left on someone’s profile will later come back as damning evidence against you in a job interview, a political career, or marriage. You simply don’t know, and it would be stupid of you to ignore that possibility.

I’ve tried to explain this to my friends the best I can, but it seems people just don’t get it (at least those my age).

Most people would agree they were pretty immature only a few years ago. Well, it’s no news flash that you will seem pretty immature to yourself in five years too.

But the Internet doesn’t have a memory of five years — no, it’s more like forever. There is a damn good chance my kids will some day find a cache of this page. Possibly even my grand kids. Have you thought about that when you make a profile somewhere?

People think just because their data is in a “private” network, it is safe. Sure, it’s safe from predators – for now – but give it five years. Give it 10. All it takes is one leak and it’s all over. All it takes is one person to see a photo of you drunk out of your mind making out with somebody to copy it and blog about it in their publicly accessible journal.

People these days are posting about their bad grades, unstable love life, frequent usage of drugs, and other things that nobody wants their employer to know. The point is that you just don’t know who will look at what you are writing. It doesn’t stop at a potential employer. There are already documented instances of the police using it to nab criminals. I have heard first hand from a friend working in the government that Facebook is used during security clearance screenings and many people fail due to photos of them breaking the law. Sometimes they were even prosecuted.

It will be very interesting in 10 to 15 years when the first major political candidates emerge that have gone through the Myspace and Facebook generation. Something similar to what I am thinking already happened recently. Tons of under age drinking photos will emerge. Some will involve rampant nudity, drug use, or illegal activity. None of it will be helpful to their image. Some of it may destroy marriages and careers.

Luckily, the net is still young and undeveloped. Sometimes, if you are lucky, you can get away with removing your content if you do it early enough.

I’m not trying to advocate avoiding social networks since I also think they will become an inseparable part of everybody’s social life. But they should be used cautiously. The rule of thumb I use is this:

Would I want my boss to see this? How about my parents?

Think about it.

Foot prints on the Internet are like foot prints on the moon (rather than the traditional beach) — they should be regarded as permanent. This isn’t like anything humanity has ever had before. You really can make a permanent mark. It’s your job to make sure you do damage control now, because you probably can’t later.