(Alternatively titled; ‘How To Make Developers Less Grumpy’)

Let’s face it, developers don’t have a reputation for being the most sociably agreeable people at times. Whilst they are seen as a necessity for most modern businesses, at times they can be seen to be downright awkward over certain problems, or overly defensive of their work. Sometimes a simple caffeine boost is enough to fix this issue, and smooth things over in your relationship, but at other times it is clear that there’s a deeper issue. Here’s my quick guide to keeping things sweet between you and a developer working on a project…

Plan the project with the developer

If possible, the developer should be involved with the project from as early on as possible. At least they should be given the challenge rather than the solution, as it’s part of their job to give you the solution, rather than just writing something which matches exactly what’s going on in your head. Developers love this creative step and I think most of them genuinely find it satisfying to offer solutions to your problems using their experience and skill set.

Bring the dev on early, explain exactly what the outcomes of the project need to be, and write the specification with them rather than for them. The better communication you have here, the better you will both understand what’s coming, and the less assumptions you’ll both make, leading to fewer clashes later on.


 Stick to the Specification

You wrote it, so respect it! The more changes you start bringing in, the grumpier your developer will be. I guarantee it because I’ve seen it time and time again. Here’s what can be quite hard to appreciate about a developer’s job: something which you think is a ‘quick fix’ or a ‘slight change to the plan’ can actually cost the developer hours of time, and often (because it’s always the way) they’ve already spent those hours doing it one way, which is just time wasted in their eyes. That means that your ‘small change’ just sent the project over, and its likely that the developer will be blamed for that.

You could ask them how long the change will take, and then consider whether or not the change is worth it, but it’s still frustrating to a developer to spend time specifying a project, and planning his time around that plan, to then have to chop and change that plan as things progress. It is much better to just get it right at the specification stage.


Find a developer you can trust…

And trust them. This one may sound obvious, but it’s the sort of find that pays dividends over time so it really is worthwhile. In the ideal world, every website, or any digital project, would have a lead developer who you would trust implicitly with that project. Their job would be to keep track of the project overall, checking other developer’s work to ensure that it is a good enough standard, as well as updating a specification of the project and planning new changes before letting anyone else start work on it. They’d even be involved in reviewing new developer’s portfolios before they came on board.

The world isn’t ideal, and sometimes budgets and time make hiring someone to this role unfeasible and illogical, but you should definitely be hiring someone that you trust to do things well. It sounds obvious, but if you don’t really trust a new developer to complete the task the way you expect at the start of a project, you’re always going to be sceptical of their work, and that’s not a healthy start to any relationship.


And actually trust them…

By this I mean, actively trust them. Respect the decisions they have made, even if they are different from your own assumptions. At the end of the day, when you hire a developer you’re hiring someone who has experience and skills about something that you don’t. If they do something a little bit unexpected, ask them way they did that, or explain why you thought it might be better if it did something different. They may have a perfectly valid reason as to way they did it the way they did… or they may not convince you at all, in which case…


Try to see the bigger picture

When thing’s aren’t quite how you want them to be, try and prioritise the changes, get second opinions on things that you don’t like, and consider the developer’s feed back. Of course some will be a high priority, and you simply need to get them complete before you go live. If that’s the case, just explain what the problem is, and why it is so important that it is resolved before you go live. They may have misunderstood something you agreed earlier, or maybe they hadn’t thought about something that is probably outside of their experience. That said anything that can wait, probably should wait. Put them on a list of ‘future changes’ and put it away for now.

Try not to think of your website as ‘finished’ once you go live. Yes, the initial build period will be over, but there’ll always be time to go back and make those changes over time, and once you are live you may start to see that the things that you thought would be a problem, are actually not so bad, and yet other things, which you thought were perfect, actually need some improvements pretty quickly.

This will also help your relationship with the developer, as lots of smaller changes, isolated out, and done one after the other, is a lot less frustrating than one huge project which keeps going on and on with continuous changes and alterations, and without the seeming ‘success’ point of a go-live ever being reached.

Get the thing done, and then keep on altering it in future.


Hopefully most of this strikes you as common sense, but its important to bear it in mind when working with coders in the future. Remember, developers are trying to help you, but a lot of what they do is very complicated, and so avoiding outside distractions such as changes to the spec is just so important to them.


Indiespring’s team is comprised of several developers that have built their skills from the ground up while training with us. If you think we have what it takes to help you, check out our team here.