Back to General Articles

Do Your Research Before Hiring!
by Princeton 23 Apr 2006
Rating: (1 vote - 4.00 average)

Not sure who you're listening to but money doesn't grow on trees!
You work hard for your money. So, why in the world are you throwing money away?

If you want to hire a programmer[1], do not hire based on "lowest bid" only. If you do, you'll end up with a product that has not been thoroughly tested, optimized, or worst--the program does not do what you want it to do.

Just like everyday life - you need to do some research before you act. Only after you have completed your research should you hire.

Below is a guideline of what you should do when making a request and what you should expect.

THINGS TO CONSIDER WHEN MAKING A REQUEST
  • If it's a large project do not expect it to be finished in a couple of weeks. A good programmer will take the necessary time to test the product before adding it on a LIVE site. Testing a large project could take weeks even months.
  • Experienced programmers are usually busy ... if you place a request for something that needs to be done right away ... you will most likely be declined or ignored due to time constraints. A good programmer thinks about the business at hand not the business that could be.
  • It's always best to pay per project not per hour. For example, a large project could take up to 100 hours or more. The hourly pay for a good programmer averages $65-$150 per hour. Do you still want to pay per hour?
  • An individual creating and releasing a popular modification here in vb.org does not mean they are an "expert" in the field.
  • Do not base your choice on the "usertitles" that are found here. These titles are set automatically by the system and are based on "install counts". In my opinion, if you base your choice in "usertitle" you will most likely come out losing.
WHAT YOU SHOULD INCLUDE WHEN MAKING A SERVICE REQUEST

The more details you offer the better chances of getting a response.
  • Budget - If it's a large project add your budget. You're only wasting your time if you don't
  • Mockups[2] - Provide mockups of how you envision your project ... the more mockups you provide the better the estimate. In some cases, it will lower the estimate. For example, a programmer could be thinking something more complex when you want something simple. NOTE: A mockup can be done on your favorite HTML editor, graphic editor, or pencil and paper. It doesn't matter ... the goal is to give the programmer something to visualize so that they can base their estimate on what you want NOT on what they think you want.
  • Expect to pay a deposit of at least 50% down. Only when the "Trust Factor" exists should you consider paying 100% upfront.
  • Provide a full description, goals, bulleted list of features, examples, mockups, and screenshots of what you are requesting. Everything should be written down ... there should be no question as to what it is that you want.
  • Get everything in writing ... The best option is to have all communications via email or a "customer help desk w/email capabilities". This will provide all parties a copy of past and present communications.
  • Do NOT include the time that YOU think the project can be completed in. For example, I have seen statements in the following manner .. "it will take an experienced programmer 30 minutes top". If you do something like this you will most likely be ignored by the best of programmers.
PROJECT COST

Factors that determines project estimate:
  • Complexity of project
  • Time to complete project
  • Requests for "Exclusive Ownership Rights" (Some programmers, like myself, will not grant "exclusive ownership rights". Others will just increase project cost by a few $1,000's.)
High demand for a programmer usually means ... more experience, less risk, and a higher trust factor. With this in mind, expect to pay more for programmers who are in demand.

TRUST FACTOR

Do not trust anyone.

However, there are things that you can look for to build credibility and trust.
  1. Take a look at current work the programmer has done.
  2. Take a look at the programmer's responses to questions. This will give you a good indication of what "type" of person they are.
    • Does the programmer belittle people if they lack the proper knowledge?
    • Is the programmer "negative" in their tone of voice?
      • Negative responses are a big flag. All responses should be positive regardless of how the programmer feels about the communication at hand.
  3. How long has the individual been a vb.org member? You don't want to hire someone who just became a member last month. Most of the "new members", are the ones that usually end up ripping people off.
  4. Ask for full name and address ... you don't want to refer to someone by their WEB nick. For example, "iMuRfaTHeR is doing the work for me", "iMuRfaTHeR has ripped me off!". My response to you is ... Huh? Who is iMuRfaTHeR? Just think for a moment ... this person could leave and come back with a different nick. Guess what? YOU might hire them again. I don't think you want that. Do you?
  5. Minimize risk by hiring people locally ... (hired in the following order)
    • City
    • County
    • State
    • Country Only hire outside when you can verify their credentials.
  6. Hire only those that you can verify ... if in doubt, do not hire.
  7. Ask for a telephone number (very important - you can verify address / locality of person with a phone number)
  8. Try to find people that have a good understanding of all aspects of vbulletin ... this includes: PHP, MYSQL, XHTML, JS, GRAPHICS ... reading their comments found here in vb.org will help you to determine "what they know".
DISCLAIMER

Information found on this article is provided for information purposes only. It's recommended that you hire a local attorney for legal advice.

[1] Programmer - in this article, we are using the term "programmer" in a general sense ... a programmer could be anyone who modifies or adds to an application in any form (eg. php, mysql, html, graphics, etc)
[2] Mockups - A usually full-sized scale model of a structure, used for demonstration, study, or testing.

Questions? Contact Joe @ https://vbulletin.org.
No reprints of this article is allowed.

vblts.ru supports vBulletin®, 2022-2024