How to Talk to Your Developer in 5 Easy Steps

By: Jordan Hanchin  | 02/27/2019


Have you ever found yourself talking to your web developer and zoning out because you have NO idea what they're saying? "This API integration uses SOAP instead of REST"? "The Object Model is filled out using a series of RESTful API calls and then used to create new data records needed for later in the process"??

Yeah, we get it. We're pretty smart people. But, it's important to note that we're people, too. We don't spend our days writing code and then go home, write more code, speak in code, sleep in code. (Well, maybe some of us do.) Nevertheless, working with us is a necessity. Here are some handy tips for you to use next time you find yourself in a room with a developer and have to, you know, talk to them.

 

1. Details and documentation.

This is the most important step when beginning a project with a developer. Wireframes, Business Requirements Documentation (BRD), Quality Assurance (testing) documentation all tell us what to do. There is no such thing as TMI in technology, so give us everything you've got. Setting expectations, dates, etc. all keep us on the same page, so there is no (well, less anyway) confusion. To add to that, when something isn't working as it should, it's best to show us what you're seeing. We like URLs, images and descriptions when you come up with errors or bugs. 
 

2. Don't Write, Talk.

As mentioned above, we are people. While we do spend a lot of our days head's down, face-to-face communications help build relationships. It also helps us feel more engaged in the project, so we can better solve the problem at hand.


3. We don't know what we don't know.

When kicking off a project, you have to be able to answer five questions:
  • Who?
  • What?
  • Where?
  • Why?
  • When?
If you are unable to answer 3 of the 5 questions, it's not time to engage the developer. Having all your ducks in a row can save time as there'll be less back and forth between you and your developer. To add to that, the sooner you can bring us into the project, the better. You might have a problem that you don't know we can solve, or, you might not know you have a problem in the first place, so let us help you. The caveat, of course, is that you also might not know what you don't know, so if you can't answer the 5 questions, it's okay. We will work with you to figure it out.
 

4. Let us process.

To add to #2, as we work with you to figure things out, some of us need time to process. We are tasked with having to absorb a lot of information in a short amount of time and then expected to answer on the fly. Developers are very analytical by nature, so sometimes, we need time to come up with a solution. Giving us time to think it through will lead to better decisions, better solutions and more accurate timeframes. And, of course, this can sometimes lead to more questions, but it will help the resources, the project and the client in the long run.
 

5. Keep your word.

This is the biggest one for me. In an ideal world, you won't have edits halfway through the project, but we understand it happens. However, when you can, try not to change your mind after we've started development. Give thought to what you're asking us to do, agree to the solution and then let us work. Thought and discussion are important steps in the process. Don't overlook them.
 

BONUS: WE Will work for coffee.

This pretty much speaks for itself. We spend a lot of our day in front of multiple screens. Caffeine is what keeps us going most days. So if you see us going cross-eyed, but need something done, a steaming cup of coffee on our desk will typically indebt us to you forever.

CoffeeDrivenDev.png

Hopefully, this list isn't too terrible. We could write an entire blog post on misconceptions, too. For example, a common misconception is that developers don't like to drink or have human interaction. ThisStatement = false. Get to know us, invite us to lunch. We may have an unusually large number of action figures on our desk, but that makes us whimsical, not weird.

We swear.

public void EndofPost()
{
    foreach(var Reader in ListofReaders)
    {
        if (!Reader.Likes)
            ReadAgain();
        else
            Share();
    }
}






 

Share this




Comments
Blog post currently doesn't have any comments.
 Security code