Some of my observations and experiences I’ve gathered while working with multiple different developers on multiple startups:
Hiring a developer you haven’t worked with yet
Don’t hire a developer you haven’t worked with yet. If possible, try to assign him some small side project where you can see him in action.
Most red flags usually appear very soon, so working with him even for a short time will help you to better evaluate his suitability to work with you permanently.
If it’s not possible, make it at least clear that you’re hiring him for a test period.
It may be surprising to learn how many bad traits or habits a developer can have which will make working with him very complicated, no matter how good he is from the tech perspective.
Experienced vs Inexperienced
An experienced developer has already done projects (or at least features) similar to what you want him to do. This means that he will spend most of the time coding, not figuring out how to go about it. The code will be easy to navigate and build on.
An inexperienced developer will encounter a lot of new stuff when working on your project. He will have to learn it first, and learning takes time. Part of learning is making mistakes, which will significantly delay development. He doesn’t know what the best practices are & how to properly structure the code – the software may work, but it could be a nightmare (or even impossible) to edit and develop further.
If a developer makes just one fundamental mistake and realizes it only after a few weeks, it’s likely the code will have to be rewritten from the ground up.
Motivation and Honesty
When a developer is motivated, he can do incredible things. If he isn’t, he can do incredibly little.
The tricky thing about working with a developer is that it’s difficult for you to tell whether the next 7 days that he requested to get something done are really needed – you have no way to know whether he wasn’t done by the day 2 and then just waiting until the 7-day deadline runs out.
I’ve seen this firsthand and also heard stories from programmers themselves. They were able to waste an unbelievable amount of time by lying about what they are (or are not) doing.
Try to find a developer with an intrinsic motivation to build things. For some developers it’s only a job, nothing more. For others, it’s their life mission to solve complex challenges and build great things, even if they’re often not going to be first in the line when the payday comes.
Having skin in the game helps, too. When a developer is a part of your early-stage startup and knows that he’s not going to get paid until you get the thing going, his motivation cannot be even compared with a motivation of a developer who’s paid by the hour and your success or failure would affect him only a little.
On the other hand, I’ve met a developer who didn’t have any stake in the startup, was paid by the hour and had great results.
Try to find a developer with the right mix of honesty, motivation, and skin in the game. Some just need a reason to work hard, others won’t work hard anyway.
Try to find a developer who can make things that actually work. It’s natural if you stumble upon some hidden bugs, but when a developer tells you that the new feature is done and it doesn’t work AT ALL, it’s a problem.
There are multiple types of developers here:
- A developer that only sends you software for review that always works perfectly
- A developer that sends you software where all main features work and you will only find a few hidden bugs that need fixing
- A developer that sends you software that sometimes works and sometimes doesn’t
- A developer that sends you software that fails right at the first opportunity, even if he said that everything works
#1 is very rare, #2 is what you should be aiming for, #3 and #4 are bad – it means that the developer is lazy to spend a little time testing the software.
Ask your developer to always test the software before sending it to you for a review. This used to drive me crazy: I was told new version works, but it crashed right after hitting the first button.
It’s not just about driving you crazy though. A developer constantly delivering software that doesn’t work has negative time implications too:
You assign a developer a task and he says it’s going to take 2 weeks. After 2 weeks he delivers it and almost nothing works. So he says he needs another 10 days to fix it. After 10 days he fixes it and it works, but you find some little bugs that again need fixing – another 5 days.
When you sum it up, you went from 14 to 29 days.
If you allow a developer to do this, he’ll see that the deadline for everything is always double of what you originally said. “I need another week” situations are a very, very slippery slope.
Sometimes a developer changes a detail without consulting it with you because he considered the change insignificant and it was easier to code it that way.
This can’t happen. If a developer thinks there’s a better or faster way to do something, he has to consult it with you first – make sure he’s aware of it.
If you know what you want, every single detail in the assignment is there for a reason. Changing a few of them, even a little, can result in a real mess in the final product.
When something isn’t clear
Sometimes you forget to specify some small details about the feature.
There are 4 types of developers in this situation:
- A developer that will instantly get in touch with you to ask how to proceed
- A developer that will not get in touch and wait until you do (inquiring how it’s going or whether it’s done) just to tell you that he doesn’t know how to proceed
- A developer that will solve it himself, but badly
- A developer that will solve it himself, mostly well
You want to work with either #1 or #4. #2 may indicate that he has no motivation to get it done ASAP and #3 will probably just need to be told to do #1.
When you finally hire a developer and you see that it doesn’t work how you expected, find another one. I can’t stress this enough. There are SO MANY things to deal with in a startup, and constantly checking on your developer shouldn’t be one of them.
You can try to “talk to him” but from my experience, it rarely works – things may improve for some time, but it eventually gets back to the old ways.
I’ve seen months wasted by delaying the decisions to replace a developer. When we finally did that, in one case a new developer had done more work in the first 2 weeks than the old one did in the last 3 months.
Sometimes it’s difficult to realize how big the difference in productivity between a bad and good developer can be.
If you find yourself in the “it’s going to be done soon” mode for too long, you shouldn’t hesitate to make the change.
You’re not going to get anywhere without good developers. Try to find the best you can. Having a great developer makes everything so much easier. It gives you confidence that you don’t have to worry about your software because it’s in good hands. You know that if there’s a problem in a published version of the software, he will be able to quickly fix it.
If you’re not able to get a good one, there’s a way to go, too: Get someone who will make the minimal version of the software (MVP) that you need to launch. Forget about the cool features, focus on the basics only. Treat it like a temporary solution – the goal will be to prove that your concept works. If you do, landing a better developer (who will probably have to start all over again) should be easier.