how to communicate with a developer

Hey everyone. Today we’ll be learning how to communicate effectively with developers and tech people in general. If you want to avoid headaches when talking to teach people then I suggest learning the lessons outlined here.

The Golden rule of delegation

Each delegated task must be both time-consuming and well-defined. If you’re running around like a chicken with its head cut off and assigning your VA to do that for you, it doesn’t improve the order of the universe. — The Four Hour Work Week. Tim Ferriss

Example: “I don’t like the layout of the webpage could you change it?”

This causes an email back and forth. Be specific. If you want the social share buttons to be on the right. You’ll need to say that. If you aren’t sure what you want exactly then suggest multiple options for what to do.

Improved example: “I don’t like the social share buttons because they get in the way of the text. Could you move the social buttons to the side and make them smaller? Or do something else if you think it’s better.”

The last part of the statement is important. If someone has a great idea then you better take advantage of it.

I not only use all the brains i have but all the brains i can borrow. — Woodrow Willson.

Sentences should only have one possible interpretation and be comprehensible by a 2nd grader. This is twice as important if the person you’re dealing with isn’t a native speaker.

Example: Can you add social login buttons to my application?

Which social login do you want? If the developer says yes and adds linkedin and apple login buttons when you really wanted google and facebook logins then you won’t be able to blame him.

Improved example: “Could you add login with google and login with facebook buttons to my app?”

Make sure you ask your developer to paraphrase what you told him to make sure he understands what you want. This will make sure misunderstandings don’t happen and cost you extra time for your project.

Don’t give people a license to waste time.

Request a status update after a few hours to see if your instructions are understood and achievable. Some tasks turn out to be unachievable within the deadline you set. To avoid having your developer rush his work and come out with a bad product work on a fee instead of an hourly basis. This will prevent you from having to scrap the project later.

Use Parkinson’s law to your advantage.

Set short deadlines for task completion. Remember back in school when that assignment was due next week but you only started working on it before the due date by a day?

That is what you risk happening when you give long deadlines. A task’s deadline must not be longer than a week. This does not mean long tasks are never done. It simply means you break them down into smaller pieces.

Example: “Can you finish the login system by the end of the week?”

Improved example: “Can you add social logins in 4 days?”

Use task batching for short tasks

Batch your requests when you want changes to be done to your app. If you have 5 changes you want to make which are small (small means small) such as changing something’s color, making the font bigger etc.

It doesn’t make sense to send an email that says “make the button blue” and only get a response 24 hours from now when you have 8 other small changes you want. If you have many small changes send them out in one email to avoid communication slowdowns.

Example of a proper email

Hi developer. I have seen your work so far. Here are a few small changes I would like to add.

NOTE: these are listed by importance so if you can’t finish all of them finish them by order.

• blah blah blah
• blah blah blah
• blah blah blah

Please reply to this email and paraphrase the changes so that we both understand what needs to be done. After 4 hours stop and send me a status update so i can see your progress.

The status update prevents people from wasting time and the ordered list prevents them from getting overwhelmed. The summary response email is to make sure that:

• The changes are achievable in the expected timeframe.
• The changes are indeed small and none of them is complicated. Some features may seem simple to implement but turn out to be complicated. That’s why developers set extremely conservative deadlines. You never know when a bug in the code will come along and ruin your schedule.

Focus on one thing at a time for large tasks.

For bigger tasks (use your judgement) only give one at a time. If you want your computer to crash open 50 windows at the same time. If you want your developer to pull his hair out give him a million large tasks at the same time.

Use the criticism sandwich

The criticism sandwich is a tool that you can use to give people constructive criticism. It is a great tool to tell someone something that he doesn’t want to hear without causing a tense/awkward situation.

Example: “Hi developer. I wanted to tell you that I dislike the navigation system you made. I think it’s horrible and we can improve it”

Improved example: “Hi developer. I really like how you organized the social buttons on the login screen. The thing is the navigation is a bit hard to use so maybe we can work on that. I also really like how fast your iteration time is blah blah blah”

You don’t need to use the criticism sandwich on every change you request. Just use it around sensitive topics as developers are used to changing requirements.

Use labels to make sure you understand what your developer is saying.

A label is when you paraphrase the last statement the other person said to make sure you understand.

If you are unsure about what a person on the other team is saying then you can attempt to paraphrase it. People hate repeating themselves but they don’t mind correcting you if you are wrong so this is a great tactic to use.

If a developer mentions something to you then that means that the thing he is trying to say is important for you to understand so you must understand it. It’s your app after all and if the fact wasn’t important the developer wouldn’t have mentioned it.

Communication is a two way street. If either you or the developer fail to communicate properly things won’t go very well. Make sure you and the person you hired get in touch at least once a week. More is preferable. This way communication problems won’t arise during your project.

“But what if my developer doesn’t communicate that much” This is your project. You need to take responsibility for it. Keep in touch with your developer to make sure things are going as planned.

Thanks for reading if you enjoyed this blog post then share it to those who might benefit from it

sharing is caring :)

Originally published at https://valuegrammer.tech.