I have not written here for a long time. But lately, the toaster has been asked for the umpteenth time how to control the work of a remote developer.

Well, I'm the same remote developer. Far away there is no place.

I have often been in the role of task master, and often this experience was successful. In fact, for comfortable work with programmers, even a minimal understanding of what is happening “under the hood” is enough.
')
Palu topic.

Ases

1. Tasks are set in task manager. In writing, and not dictated by telephone or Skype.
If you want your remote developer not to spend his time and energy (which he could send to work), then ask him which task manager is convenient for him to use. Surely he reasonably uses them for several years, and can share with you useful skills.
Make sure you formulate the task. If the task is great, together with the developer, divide it into parts, jointly write down intermediate goals and criteria. Work may take place under conditions of implicit source data and goals, but at each iteration the success criteria should be obvious.
The normal duration of the iteration is one week. Maximum - three weeks. The number of tasks to be iterated can be discussed with the developer. Study the progress of the previous iteration when planning the next one.

2. Comites are uploaded to a remote repository, which, as a rule, has a web interface. This means that you can view current progress online. To do this, you do not need to have special knowledge, this job is available to the average manager with basic skills "Computer Operator". Of course, this mode of operation requires a trusting relationship with the developer. Trust can be achieved not by exhortations, but by positive work experience.

3. You can ask the developer to periodically make screencasts of new functionality, screen or upload test results and send you.

4. It is much easier and cheaper to go and google the question you are interested in before asking the developer to explain something to you in a voice.

Details

First, control the work is simple. According to the results. Are there specific tasks? Have clear priorities?
Any problem can be solved within a week. If the task is highly voluminous, it should be broken up into smaller fragments, the solution of each of which most likely takes one working day.
Thus, the effectiveness of control is directly dependent on the quality of the task.

Secondly, we, programmers, make modules. 10 average modules account for about 5 to 10 complex tasks, and 90 are very trivial. Within a week, it is possible to make from 3 to 10 modules. During the day - from zero to 5. Now I will try to explain why.

Trivial tasks are often voluminous. They are easily programmed and their programming is even automated, but it is because of the monotony that they take longer to debug. In general, debugging takes 60% of the working time. And that's fine. 60% of the time to get the freshly written code to work, and to get the necessary properties from it, including performance and security (if there are additional requirements in this regard).

Difficult tasks are somewhat knocked out of the mainstream. Complicated does not mean voluminous. Just solving this particular problem in the current context has not yet been. Or it was, but to port for a long time or not advisable for other reasons. Usually functions in a successful implementation are small, literally one or two hundred lines. But before this successful solution you need to come.

You can go to the decision from one to three days, or longer. Experiments, tests, tests and unconditional errors. Often without instant results. A more effective way is to be distracted from the computer in general, and think about tasks in the fresh air. I enjoy fishing and carpentry in the country. The best of what I thought out occurred to me at a distance of several tens of kilometers from computers. Being closely acquainted with dozens of colleagues, I discussed this issue with them many times. Everyone has come across this, and everyone understands that this is normal.

That is why it is meaningless to demand from the developer a real-time presence, and the use of online controls. It will be present, but will it be productive? This is a question.

I have a lot of familiar executives who told similar stories about programmers who go to work in a suit and by the hour, but in fact work slowly and too often they do the “wrong thing”.

Third, consulting is more difficult than developing programs. And the point here is not at all in introverted specifics of labor.

Counseling is hard work. If you want to get a quality result - do not have to stand for hours with brains, stupid questions and discussions. If you are not competent in some issues - is there a developer’s fault here? Want to get some new knowledge? And why should we pay for your training with our time?

If you want to get high-quality advice - prepare for it. Write down the questions in a list and send them by mail at the end of the week. No need to call and ask them one by one. If you find the answers to the questions - remove them from the list. The list is empty? Sumptuously. So really nothing to talk about. And this is also normal.

Typically, programmers work in small sessions, for 2-4 hours. Thus, during the day it turns out to hold only 2 or 3 sessions. If you distract with a spontaneous call, half a day is lost. Programmers work directly with their brains, so they require some delicate communication. Do not they talk the brain to make.

What you think is spectacular and convincing, your interlocutor may seem silly and boring. Usually this is a conversation about prospects, cooperation, new and old technologies. On the contrary, it will be interesting to discuss the real user experience and specific plans.

Regardless of whether you remember your calls or not - you influence the work of a remote developer. You can influence and positively. It's simple: regulate communication and do not make deliberate nonsense, justifying the reservation "I do not understand this."

Either understand, or honestly formulate the criteria that you understand.