How to control the work of a remote programmer?

Question

Freelance

I order the development of my service from a remote programmer. The person upon hiring seemed adequate and interested. However, over time, the quality and speed of work began to fall: simple tasks are done for weeks, complex ones generally take several months, after passing the sprint, a bunch of bugs and errors are revealed. With all this, the number of hours spent on development per month (for which I pay) does not change, sometimes even increases.
I have a question, how can I track the progress of developing an application on Ruby on Rails if some tasks are not related to the frontend in any way and the programmer says that the process is underway, it's just in the code and it's not visible? Maybe somehow by commits or something else, are there any articles on this topic, etc.?
I myself am not a programmer and I can’t estimate from the code whether 10 minutes or 10 hours were spent.

Answer 1

To begin with, it was not necessary to try to save so much. Judging by the fact that months are spent on solving the problem, you were looking for the cheapest programmer, and a newcomer agreed to cooperate with you. He now most likely regrets that he contacted you. I'm sorry, but it's your own fault. You can't cut seven hats out of one sheep.
Any task is solved in no more than one week. The vast majority of programs are released into beta in 2-3 months. If longer - you need to sound the alarm. Or wrong planning, or problems in the team.
It's easy to monitor - by the list of tasks in the tracker and/or by commits. Don't expect a developer to produce some kind of progress on a daily basis. Programming is not a linear process. You can blunt for a day or two, and then do it in ten minutes - this happens all the time. Weekly iterations will be convenient for everyone. For example, every Monday check the progress for the week, and if necessary, adjust it.
Don't blow the developer's mind with long conversations. For programmers, the brain is arranged somewhat differently, and with long conversations you take out his brain. After that, it is difficult for him to work - in this way you yourself create problems. Write questions in text, and do this no more than once a week. Accumulate questions before posting them. If you found the answer to the question yourself - remove it from the list. Check if there are answers to questions on the Internet.
This is surprising, but many, like complete oligophrenics, do not understand that consultations take both strength and time. And that is why it should be regulated.
With consultations, as with sex. Do you want quality? Then you need to be well prepared. And behave yourself. Always. Want good answers? Think over your questions.
In the state of flow, any crap can be distracting and disrupt the working state. Especially questions. Especially stupid questions. Stupid not from your point of view, but from the developer's point of view. The programmer works in cycles of 2-4 hours. If you break the cycle (for example, by asking a stupid question or calling on the phone) - HALF A DAY is lost.
Therefore, my second remark - check if you are preventing it from working?

Answer 2

It is obvious that it is necessary to change the programmer.
It is very easy to control, each task has a deadline and it is easy to control it, well, look at the history in the git.

Answer 3

pay by the hour, track time in specialized software. For example: www.tahometer.com
I don't see a problem, I see a lack of knowledge of methods.

Answer 4

Take a third-party developer at a higher level, for an hourly job, so that he just does a code review once a day or two for an hour and a half. I think in a week you will have a verdict.

Answer 5

You can define an update schedule in Git/SVN and track what's changing.
You can set tasks in something like Redmine and track their progress.
You can offer him to put a tracker like Timedoctor on his computer and track what he is doing.
But all this is useless if a person decides to give up on work. Any suggestion of activity tracking will be taken with hostility and used as an excuse to end the relationship.

Answer 6

All tasks must be recorded (you can use any task tracker like JIRA, or just an Excel file in Dropbox, for example, the main thing is that both have access to the list of tasks). For each, there should be a description of what exactly needs to be done as part of the task. Ask the developer to estimate by time the priority tasks from the general list (also - if the tasks are dependent on each other - arrange them in the order of completion) and, based on this estimate, type tasks for the week of work. For each, the time estimate will be known in advance. It can change in the course of work, of course, but there will always be an understandable reason for this change. You can go over the list of tasks together after the assessment for a week and talk about each one (make sure everything is clear to the developer, make the necessary explanations, etc.).
Ask the developer to write you a report every day in the form of:
1) what tasks have been done
2) what tasks are planned to be done next
3) what are the problems, questions, difficulties in the current work
assess (if the deadlines are delayed) what the problem is. Also, a side effect is that you can help the developer every day by promptly answering questions from point 3.
I support the opinion that tasks should not be too large - less than 8 hours (working day), and preferably no more than 4 hours. Big tasks should be divided into parts.
In any application, as a rule, there are similar tasks. And over time, you will have an understanding of how much this or that new task, similar to those that were done before, can take. And if you see that the estimates diverge significantly, there should always be a clear explanation why a similar task takes more or less time. Ask the developer to clarify this. Also, the subsequent similar task usually takes less time, as it is done faster by analogy.
Well, if you have questions (for example, why the speed is reduced) - you can always just ask the developer - why is this happening? Are there any problems with work? What can help return the speed to its previous performance?
Telepathy, unfortunately, is still only a fantasy, and no one can read thoughts. Therefore, the only way to find out something is to communicate.

Answer 7

No, wait, believe, hope. In addition to writing code, a person has other tasks. You better describe what kind of service and you will be given an approximate estimate in time.

Answer 8

The desire to control comes from the judgment that all people are idiots. The problem is that non-Idiots are expensive. Also, regarding the programmer, you can be an idiot. Short iterations help, pay a lot and let the programmer "fuck" your brain for your money, because only you know what you need. In general, I am for a time-based payment, but with brain-fuck, and not just that you have technical specifications and shit - and then it turns out that what for it doesn’t work, because the developer of the technical specifications did not even model in their brains how it would be.

Answer 9

Everything that is described below will require you to spend more time on control, communication, etc.
1. Break up tasks so that the duration is no more than 4 hours
2. Ask for a preliminary estimate of each task in hours, and if it gets out of it a lot in the process, ask to explain why. Do not pay if you get out for an assessment without warning
3. Connect another developer or several, create competition so that they can see each other, let them both evaluate the same task, and you decide who will do it
4. Give negative feedback. Did not meet the deadline - receives a warning for the first time, then a fine
ps Also, consider the advice of Evgeny and Maxim Timofeev

Answer 10

This is a common practice - he just lies, and he does another project.
Even if you do not understand the code, you can at least look at the volume of what is written.
Or invite an outside specialist for an audit - it's not expensive.

Answer 11

There are excellent time trackers, and some log everything, launch the program, take screenshots and all this is sent to the service in which you are the main one, you are the main one and therefore you will be like a manager, producer and team leader who should be able to control all these issues . Plus, when you are thinking of working with a remote programmer, then you need to understand what development methods you will follow, you don’t have to go far and take, for example, Agile. Familiarize yourself with it to understand what you need from a programmer and him from you, here I am pointing more to the so-called "stories". Also, get acquainted with the programmer's portfolio, conduct an interview with him, make a list of questions before that. And most importantly, you must have good capital. Well, I advise you to read the book - The Ideal Programmer. Any questions please write. I will answer.

Answer 12

If you look at this problem from the side of the developer, then such customers often misunderstand the concept of complexity. Sometimes the task that the customer considers "difficult" takes a couple of hours, and the one that is "easy" requires large edits in the project and a long time for reflection and implementation. In addition, such customers want to pay only for innovations, they consider such concepts as refactoring a waste of money, and their Wishlist is often not even provided for in the project, and because of this they violate the overall concept and quality of the code.

Answer 13

The frontend is also not visible, if that. This layout is sometimes visible))
How to control - no way. Morons need control.
But it's better not to work with morons.
Better choose a specialist. Learn programming management.
And so you can track by commits.
Well, the problem is on both sides. So-so programmer. So-so customer.
If I had such a problem, I would start with myself.