How to Work with Developers
Regardless of the problem, you are trying to solve; you are going to need a developer. While this post is about application development, the same can be true for just about every contractor relationship.
The word development represents more than it should. Sort of like design. But development has a special kind of mystery that I want to dispell.
A developer or programmer is ideally a person that has worked hard at a craft to become very good at leveraging known best practices and sound analytical thinking to build the things that you want. But, for the most part, there are no standards in web development yet. And that’s a shame. More on that later.
A developer is a lot like a carpenter. You have framing carpenters, finish carpenters, furniture builders, boat builders, and carpenters that specialize in decks. In every case, you are talking about a craft and a profession that revolves around wood, tools, and experience. A block of oak in an experienced carpenter’s hand is an invitation to magic. They can make something incredible, before your very eyes that you never imagined could be made.
Developers are similar. There are many different types, but they all revolve around computers, tools, and experience. They can take a bit of code and do things you could never have imagined. It can look like magic.
Here’s where the metaphor breaks down though. You can pick up a block of wood. You can feel the weight of it. You can knock on it and know it’s solid. It has heft and dimension. It feels like something. You can’t do this with apps. Hence the name software. It’s abstract. Development is the craft of building something we all know doesn’t actually exist. Yet, it can still inspire awe, scare the hell out of us, or impact our health.
Furthermore, while I think that there is an obvious difference between a good framing hammer and screwdriver, the difference between tools in development are not obvious at all. You will likely not know if the tools your developer is using are “safe” and won’t create security issues or won’t grind to a halt because they are doing something that they were never intended to do.
Great development can be magical. Poor development is awful. Here’s how you get the best result.
Stick to your guns until it works
I think that there is a direct correlation between the amount of time it takes to achieve magic and the experience of the developer. I have NEVER worked on a project where the initial solution was right the first time. Ever. But, I have worked on projects where getting to launch was quick and easy and where it was impossibly painful. An experienced developer will know all the tips and tricks, and they will know and care about figuring out what you want. That will translate into a shorter development time. In my view, experience equals speed, not a perfect solution.
So, while I think it matters that you understand the basics of the tricks that your developer is using, I do not think you should micromanage. Let them apply the experience that they have.
However, do not ever give up your no. I have done cleanup for shitty developers time and again because the stakeholders were so impressed with the dog and pony show that they ended up with a product that they could not use and no way to recover the cash. Saying no doesn’t mean you are ignorant. Nor does it mean that you are difficult. It means that you trust the developer enough to keep them in the fight even when it’s not clicking. Even when it causes tension. You are saying “I trust you to figure it out”.
Development is listening. More than anything. It’s listening. Once the developer hears you, who cares what they build it out of.
Join the Conversation
This is the from the archive of an ongoing series called Making Things That Matter. Each week I will send you an email with another step in the process of building products and launching ideas. Signup here to join the conversation.
