An inside look at remote development, or why programming is not a linear process

I haven’t written here for a long time. But recently, on the toaster, they have repeatedly asked how to control the work of a remote developer.

Well, I'm the same remote developer. Nowhere else to go.

Many times I had to be in the role of task manager, and often this experience was successful. In fact, for a comfortable work with programmers, even a minimal understanding of what is happening “under the hood” is enough.

Palyu topic.

The basics


1. Tasks are set in the task manager. In writing, not dictated by phone or skype.
If you want your remote developer not to waste 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 it for several years, and can share useful skills with you.
Make sure you formulate the task. If the task is great - together with the developer, divide it into parts, write down intermediate goals and criteria together. The work can take place in the conditions of implicit initial data and goals, but at each iteration the criteria for success should be obvious.
The normal iteration duration is one week. The maximum is three weeks. The number of tasks put up for iteration can be discussed with the developer. Examine the progress of the previous iteration when planning the next.

2. Commits are poured into a remote repository, which usually has a web interface. This means that you can view current progress interactively. For this, you do not need to have special knowledge, this work 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 experience.

3. You can ask the developer to periodically make screencasts of new functionality, screen or upload test results and send them to 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


Firstly, it’s easy to control the work. According to the results. Do you have specific tasks? Are there clear priorities?
Any problem can be solved within a week. If the task is very voluminous, it should be divided into smaller fragments, the solution of each of which most likely takes one working day.
Thus, the effectiveness of control directly depends on the quality of the formulation of the problem.

Secondly, we programmers make modules. For 10 average modules, there are approximately 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’ll try to explain why.

Trivial tasks are often voluminous. They are easily programmed and their programming is even automated, but it is precisely because of their monotony that they are debugged longer. In general, debugging takes 60% of the working time. And this is normal. 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).

Challenging tasks are somewhat knocked out of the mainstream. Complex - does not mean voluminous. It was just that there was no solution to this particular problem in the current context. Or it was, but porting for a long time or not advisable for other reasons. Usually, functions in a successful implementation are small in size, literally one or two hundred lines. But you still have to come to this successful decision.

You can go to the decision from one to three days, or longer. Experiments, tests, trials and unconditional errors. Often without instant results. A more effective way is to get distracted from the computer in general, and think about tasks in the fresh air. I am fond of fishing and carpentry in the country. The best of what I came up with came to my mind at a distance of several tens of kilometers from computers. Being close to 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 makes no sense to demand from the developer a real-time presence, and the use of online control tools. He will be present, but will he be productive? This is a question.

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

Third, counseling is harder than developing programs. And the point here is not at all the introvert specificity of labor.

Counseling is hard work. If you want to get a high-quality result, you don’t have to endure the brains for hours, silly questions and discussions. If you are not competent in any issues - is there a fault of the developer? Want to get some new knowledge? Why do we have to pay for your education with our time?

If you want to get a quality consultation, get ready for it. Write down the questions in a list and mail them at the end of the week. No need to call and ask them one at a time. If you find the answers to the questions - remove them from the list. The list is empty? Sumptuously. So there really is 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 spend 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. It’s not worth them to endure the brain in conversations.

What seems effective and convincing to you may seem silly and boring to your interlocutor. Usually these are conversations about prospects, cooperation, new and old technologies. On the contrary, it will be interesting to discuss real user experience and specific plans.

Regardless of whether you remember your calls or not, you influence the work of the remote developer. You can influence positively. It’s simple: regulate communication and don’t do stupid things, justifying yourself with the clause “I don’t understand this.”

Either sort it out, or honestly formulate criteria that you understand.

Also popular now: