5 Rules Every Developer Wants You to Follow

Picture this: you’ve got a fantastic idea for a new {insert amazing thing here}. You’ve done the research, planned out the process, and are ready to take it to the web…

But do you know how to communicate with your developer in a way that guarantees success for everyone, especially you?

The way you work with your developer can make the difference between another bloated, useless website and an intuitive website that brings the conversions your new project needs to succeed.

The below 5 rules will guide you through the development process to ensure completed projects match your vision. As a bonus, your developer will look forward to (and maybe even love) working with you.

How to Improve Communication with Your Developer

1. Ask What They Prefer

So how does your developer prefer to work?

If you have to think about it, then you probably don’t know. You could assume and run the risk of getting on their bad side. Or you could ask.

Many developers have a preferred way of working. Some want a detailed spec, fully fleshed out top to bottom. Others want an overall framework and a general idea of what the core functionality needs are. Some just want to know what the “true” goal is and what their part in it is.

If you don’t ask, you won’t know.

2. Focus on What the Site Needs to Do

While your developer may agree that your new amazing idea is going to take the world by storm, you don’t need to sell them on the idea. After all, they (probably) aren’t the target market.

At this stage, they are just building the thing. Instead of wasting time telling them ad nauseum what market segments you plan on approaching and your revenue model, tell them what you need to accomplish it.

What does your site actually have to DO to be successful? In plain English, tell them what should be happening. Examples:

Right way: A user visits the site and sees X, is prompted to do Y, and hopefully we get Z.

Why is this the right way? A developer will not only know what needs to take place, but they can also ask specific questions related to X, Y, and Z and make sure the process works from start to finish.

Wrong way: A user visits the site and is given a distinct call to action that we A/B test.

Why is this wrong? Nothing about what the desired action actually is, or how the user is supposed to interact with it. Or what happens when, if by some magical unicorn goodness, they do it.

In other words, don’t make us guess what you mean. If you don’t know, then you should probably figure it out before getting it to us. Speaking for myself, I cannot stand building something twice because someone didn’t know what they wanted the first time.

3. Let Them Choose the Tools

Please don’t throw buzzwords at your developer about technology or what tools they should use. We don’t care if {insert popular site here} does it. They may use a completely different framework, programming language, or site purpose.

After all, you don’t tell a plumber what wrench to use when installing a toilet, do you? No. You just tell them where it needs to go and that it needs to flush. And just like a plumber, it’s the developer’s job to ultimately decide what tools are best for the job.

Now if there is some sort of integration with other services needed, by all means let that be known in the beginning. Nothing will piss off a developer more than throwing in some 3rd party service at the end of a project when everything has been built to do something a specific way, only to find out that doesn’t mesh with something else.

4. Set Realistic Timeframes

Rome wasn’t built in a day. Neither was Google. Or the text editor I’m writing this post on at this very moment.

Your superawesomeproject can’t just be whipped up in a few hours. No amount of pleading, begging, or money can change that.

While many people still see developers as those Dungeons and Dragons geeks they made fun of in school, we’re actually a (somewhat) social bunch. Most of us have lives outside the code. Many of us have families. So for any project to be successful, you’ve got to give them time to actually do it. A 40-hour project doesn’t mean 1 week. You probably aren’t their only client and almost always aren’t their only priority.

True story: I had a client lead come in for an upcoming book launch. They had waited exactly 9 days before the launch to contact me (and a few other devs, I found out) about getting a site built. Mind you, this wasn’t a landing page. Or even a quick “placeholder” site to get up before the real one was done. Nope, they wanted a full design and development (with ecommerce, no less) done in 9 days. While I’m not sure if it ever got done, it sure as heck didn’t get done by me.

5. Fewer Meetings

Developers, as a rule, abhor meetings. Not only are they usually boring and don’t tie directly to their role in development, but they have an adverse affect on our productivity. A 1-hour meeting can cause 4 hours or more of lost time.

Paul Graham wrote a great essay on this called Maker’s Schedule, Manager’s Schedule. He breaks it down better than I ever could. And since he founded Y Combinator, I’d say he knows a thing or two about both management and developers.

Conclusion

While every developer is a unique snowflake, the above 5 guidelines are appreciated by all. Be upfront about your needs and give us the time to accomplish them. In turn, we’ll build you amazing things.

How do you successfully communicate development projects? Developers, what would you like to see added to this list? Let us know in the comments below.