Fact: Hiring a programmer sucks; everyone has horror stories. Good, affordable programmers are rare and very often constantly booked solid.
Fact: I am a programmer and some of the tips I will give will probably cramp programmers style (ironically, including my own).
If you have ever talked to me in person about business, chances are I have at some point told you that if I was ever to create an info product it would be on just this subject. As of now I don’t have any serious plans to do so and I would rather help you folks out instead of hording the information.
Fair warning this post will not go into wear to find programmers, but instead focus on how to screen a list of canidates once you have them.
Hint: Standards.
Getting Started
Before you can seriously consider hiring a programmer you should produce some boiler plate on common things you expect from anyone you outsource from.
You should hit each of these points and write out what you expect
Some things to include are:
– Mode of commuincation (Skype, Phone, Email, etc…)
– Frequency of one way communication (how often you expect progress reports sent to you)
– Frequency of two way communication (how often you expect to have a real time conversation with your programmer)
– What form of version controll (subversion,cvs,hg,git) will they be using (if they say “my own” or “none” forget them).
– What form of replication will they use (scp or rsync over ssh are good tools)
– What tools do they use to check for correctness, tell them you prefer some automated testing if applicable (note that adding unit/system tests can raise the price of the project significantly, but if you need to be sure it works correctly, its a good idea).
– How long will they support the project (i.e. if you find a bug in week after last payment, is it covered, how about a month, what are the rates afterwords?)
Some Basics of Coding Standards
– Ask them what languages/tools they will use: PHP, MySQL, SQLite, maybe some MVC Framework, jQuery, Python, Pylons, Rails, whatever just be clear on the technologies they are going to use and be aware of the licensing issues that come with these technologies. They may change this during the course of the project, this is normal.
– Tell them that you expect documented object orientated code, with unobtrusive javascript (if applicable) and a responsible separation of logic and presentation (i.e. there should not be a lot of code inside of the HTML if possible).
– If you are doing anything with a database specify that they must use “transactions” with PREPARED STATEMENTS. If its a PHP project tell them you expect them to use the PDO class with prepaired statements. And if its Python, be happy if they say they will be using sqlalchemy.
– If they are doing any HTML from scratch (i.e. not extending an existing script/site) you expect them to do it in “HTML 4.01 Transitional” if they argue with you that XHTML Strict is somehow better, tell them not unless they have a time machine to the year 2007 and the power to change history.
– Tell them you expect a cron job to dump the database to a secure location on the server which is password protected so that you can download/backup the database from your browser (unless, of course, you use phpmyadmin or something similar).
– Login Passwords must be one-way encrypted/hashed in the database.
Going over the Specs
SUPER IMPORTANT: Make sure your prospective programmer is willing to go over the specs that you have thoughtfully and thoroughly written out BEFORE you put down a deposit. Avoid people who say “i completely understand your specs (no one does) and i can get this to you by your deadline.” This is bad.
Often They will then put either a highball or a low ball price for a
quote.
Instead tell them you expect them to go over the specs with you and ask you any questions before you get started (they may charge a little for this, but its worth it).
SPECS CHANGE, understand that sometimes this will be your fault, sometimes it will be the coders. If you add new features expect to pay more, possibly a lot more even if you think it should just be a few lines of code. You don’t know the architecture of the site so you don’t know what will needed to be done.
Fast or Clean?
The speed of the site both in terms of load time and how fast you get the site/app up has to be balanced with how fault tolerant (dealing with corner cases and bad input) and maintainable the site is.
Choose speed if you are running something that needs to be real-time.
Fault Tolerance/Clean Code if the data is important and/or you think the application will have a long life cycle or be getting new features in the future.
Are They Getting the Job Done?
After you have given your deposit (I do %25 to start, %50 at beta, %25 at completion) you need to know that they are actually working on the site.
One approach to doing this is to ask them to show you snapshots often, i actually think this is kind of tricky because often its better to code a nice strong foundation first and then get the front on the site on the end. By asking them to show you partial functionality you may very well be hurting the coding process.
If you do ask for snapshots or even if you don’t still REQUIRE FREQUENT COMMIT COMMENT LOGS aka revision logs. All of the version control tools work by “commiting” a snapshot of code to a project code “database.” When you commit you can comment on what has been done.
The version control (svn/git/hg/etc…) tool can spit out a history of changes and they can email this to you along with any other little notes they might have. This should only take them 5 minutes and will show you that they are actually working and how much they are getting done. If it takes them longer they are doing something wrong.
As an example, in svn to get the commit log you would do:
svn log
This would give something like:
svn log
---------------------------------------------- r3 | Coder Name | (Fri, 12 Mar 2010) | 2 lines middlewear fix added the foo template ---------------------------------------------- r2 | Coder Name | (Thu, 11 Mar 2010) | 2 lines First commit with tables Now the bar function works, but need to santatize the baz script --------------------------------------------- r1 | Coder Name | (Wed, 10 Mar 2010) | 1 line initial import dfhu.org script ---------------------------------------------
Similarly you might ask for a code word count dump.
The shell script one liner is
find . -name "*.py" | while read ln; do wc $ln ; done
And will give something like:
Line Counts
17 40 448 ./projectname/controllers/login.py 46 144 1630 ./projectname/controllers/error.py 14 32 409 ./projectname/lib/validate.py 264 568 7492 ./projectname/lib/form.py
Where the numbers are represent Lines, Words and Characters per file respectively.
Also as for the results of apache’s `ab` benchmarking as well, to get an idea of how fast the site is. The number of requests -n and the number of concurrent requests -c depends on how much traffic you expect.
ab -n 250 -c20 http://thesite.faux
This will give something like:
Ab Testing
Total transferred: 160660 bytes HTML transferred: 155180 bytes Requests per second: 17.12 [#/sec] (mean) Time per request: 584.071 [ms] (mean) Time per request: 58.407 [ms] (mean, ... requests) Transfer rate: 134.31 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 7 9.0 1 21 Processing: 89 561 435.0 919 1078 Waiting: 71 545 432.6 901 1071 Total: 89 568 442.5 937 1099 Percentage of the requests served within a certain time (ms) 50% 937 66% 966 75% 973 80% 987 90% 1074 95% 1099 98% 1099 99% 1099 100% 1099 (longest request)
TL;DR
– Agree on frequency and type of communication
– Have basic coding standards (OOP, Prepared SQL statements, sepration of logic and presentation)
– Require version control logs emailed to you a couple times a week or however often.
Please rate this post and coders feel free to bash me in the comments.
Loading ...
7 Comments
Hey Victory,
Would you consider a writeup on version control, svn, and why its important today? When I develop I rarely touch it, mostly due to lack of indoctrination.
Enjoyed Reading,
Leaving intimidated,
adbox
Nice article, thank god I don’t work as a programmer and only code for myself though.
Excellent article! This is the big distinction between hiring coders/programmers and software developers/architects.
Great post. I never thought about it, but the idea for requiring them to use version control and using the commit logs as a way to view progress is great! I noticed, however, that you didn’t mention using any type of milestones. Any reason? Btw, I great blog. I’ve been reading old posts all morning
Very useful information of how to screen and select a programmer. I like how you put the payment method strategy down there too because it gives more confident and satisfaction to customers. Thanks for the awesome tips!
An excellent article and one that should be essential reading for any non-techie who has to hire a coder.
One question: you say they should craft any HTM in “HTML 4.01 Transitional” – why not XHTML?
Thanks again
XHTML was put into a limbo state where browsers and users didn’t really have to use it correctly. They were asked nicely to do xhtml right, but for the most part did not. IE6 didn’t even bother rendering xhtml at all, FF required the proper XML header and %99.99999 sites didn’t send the correct XML header. XHTML was not rendered as XML but instead broken HTML.
Look at most page source in FF and you will see the red “/>” marks showing that they should not be there.
Real XHTML is tricky and if you have one error on the page the whole page does not load. I use Genshi as a template engine, which requires real XHTML to run (but renders whatever (X)HTML you wish), desingers are “shocked” when they find out that they really actually have to write XML.
ALL that being said there is still a time when you have to pretend to use XHTML and that is when you are using a different namespace for some elements in your page.
For instance facebooks “<fb:like>” tags.