Re:How do you recognise good programmers if you’re a busines...
by grandalf on Sunday March 15, 2009 @12:11AM
(#516574)
This will probably not make it above the noise in the thread but I think the following would be useful:
- You would ideally have at least one person who you trust who is a coder who you can show source code samples, previous work, etc., for a quality assessment.
- Previous business references are valuable, as only so much of the overall usefulness of the person comes from raw coding ability -- there may be other habits, personality characteristics, etc., that (good or bad) might influence the decision.
- I highly recommend starting out a new coder with a simple contract project so that you can assess her ability to communicate, work toward a goal, etc. You should probably pay whatever the coder thinks is fair, b/c this is not a bidding war exercise. You mainly want to see about work habits, style, compatibility with the existing team, productivity, etc. By doing this you are giving both parties (yourself and the programmer) a chance to feel each other out and determine if it's a good fit. This can even be done as a part-time project while the programmer is still employed elsewhere, reducing risk for everyone involved.
- Things like blogs, open source contributions, etc., are nice, but I think of them as a hobby and unless you're thinking of hiring one of the few very well known luminaries in a software community, the fact that your prospective hire has a blog is probably not all that indicative of superstar qualities.
- Character traits like tinkering are great too, but just because someone is focused on a main task and doesn't tinker with each new thing that comes along doesn't mean she's somehow a worse programmer than the tinkerer who writes something in every new framework, etc. I have known great coders with both characteristics and I think the bottom line is that good coders know what's out there and can easily help you evaluate it for your business, even if they didn't spend the past 5 weekends hacking out a side project in erlang -- unless of course you truly end up wanting to use erlang, at which point their side project was a great investment that cost you nothing. However, most skilled coders could read up on erlang and catch up in about a week, so we're not talking about all that much overall productivity.
- I'd beware of coders who prefer highly complex solutions to problems -- in a business scenario sometimes a less elegant, easily understood solution is ideal.
- I'd beware of coders who are unwilling to adapt to your demand for quality. Perhaps you don't need 3000 lines of test code for an internal whiteboard app. It's good to find a coder you can trust to make the right call, but some are very unconcerned with your budget and timeline and may not realize where the rubber meets the road from a business perspective.
Any hire is going to be a relationship and hiring a coder is not too different from hiring a business person. You need to establish trust and confidence. Frank and clear communication is key to this. The coder should not think of you as a "suit" and you should not think of her as a geek. Ultimately the reason anyone is getting paid is because it's a business and that requires judicious use of tradeoffs.
- You would ideally have at least one person who you trust who is a coder who you can show source code samples, previous work, etc., for a quality assessment.
- Previous business references are valuable, as only so much of the overall usefulness of the person comes from raw coding ability -- there may be other habits, personality characteristics, etc., that (good or bad) might influence the decision.
- I highly recommend starting out a new coder with a simple contract project so that you can assess her ability to communicate, work toward a goal, etc. You should probably pay whatever the coder thinks is fair, b/c this is not a bidding war exercise. You mainly want to see about work habits, style, compatibility with the existing team, productivity, etc. By doing this you are giving both parties (yourself and the programmer) a chance to feel each other out and determine if it's a good fit. This can even be done as a part-time project while the programmer is still employed elsewhere, reducing risk for everyone involved.
- Things like blogs, open source contributions, etc., are nice, but I think of them as a hobby and unless you're thinking of hiring one of the few very well known luminaries in a software community, the fact that your prospective hire has a blog is probably not all that indicative of superstar qualities.
- Character traits like tinkering are great too, but just because someone is focused on a main task and doesn't tinker with each new thing that comes along doesn't mean she's somehow a worse programmer than the tinkerer who writes something in every new framework, etc. I have known great coders with both characteristics and I think the bottom line is that good coders know what's out there and can easily help you evaluate it for your business, even if they didn't spend the past 5 weekends hacking out a side project in erlang -- unless of course you truly end up wanting to use erlang, at which point their side project was a great investment that cost you nothing. However, most skilled coders could read up on erlang and catch up in about a week, so we're not talking about all that much overall productivity.
- I'd beware of coders who prefer highly complex solutions to problems -- in a business scenario sometimes a less elegant, easily understood solution is ideal.
- I'd beware of coders who are unwilling to adapt to your demand for quality. Perhaps you don't need 3000 lines of test code for an internal whiteboard app. It's good to find a coder you can trust to make the right call, but some are very unconcerned with your budget and timeline and may not realize where the rubber meets the road from a business perspective.
Any hire is going to be a relationship and hiring a coder is not too different from hiring a business person. You need to establish trust and confidence. Frank and clear communication is key to this. The coder should not think of you as a "suit" and you should not think of her as a geek. Ultimately the reason anyone is getting paid is because it's a business and that requires judicious use of tradeoffs.