[LRUG] First post (about managing remote developers) [OT]

Artan Sinani artisinani at gmail.com
Fri Jun 29 14:59:03 PDT 2012


Hey Ronny,

I understand all the points you make, but I don't understand what's the
difference between managing a developer working remotely to a dev working
in the office. The developers working in the office can also deliver little
and waste time on other activities. In other words, the checking ways you
describe, can apply to a dev in the office as well as to the remote one.

I have been working remotely for almost one year now with the same
responsibility to get things done as when I was working in the office. I
find it hard to believe that a developer would reduce his/her productivity
when working remotely. In my case I've found the opposite to be the case,
as the interruptions are much less working remotely.

Regards,
Artan

On 29 June 2012 05:22, Ronny Ager-Wick <ronny at ager-wick.com> wrote:

> Ryan, hiring remote developers is a mine field, as many will tell you.
> Some developers, regardless of location, are extremely good, but not
> everyone. If you're unlucky, you may spend more money getting less done
> than you would hiring a local developer. Unfortunately though, although the
> proximity makes it more likely to work out, even that is not a guarantee
> for success.
> From my experience (which includes managing a number of developers, most
> of them great, but far from all), working with people you don't know yet, a
> short feedback cycle is essential. For example, you could ask for a list of
> things they plan to do the next day to be sent to you at the end of their
> working day, as well as a list of things they accomplished that day.
> Comparing the to-do list from yesterday with the accomplished list today
> should give you an idea of whether something is happening. The principle is
> similar to scrum, but of course modified to fit the situation.
> You should also have access to their git repository (assuming that's what
> they use - normally it is), so that you can pull (download) the changes in
> the code whenever you want. Insist on pushing code at least daily
> (temporary development can be pushed to a separate branch). If you don't
> know how to use git, learn at least enough to download the latest changes
> (git pull), review the log (git log), and see what changes has been done on
> each commit (every time they add new code). The last bit can be done with
> git diff, but you may benefit from using a graphical program for that, such
> as Qgit (I'm sure there are many others, and it may not work on other
> platforms - I use Linux). If you have doubts that they're actually
> delivering much, at least you can see for yourself what code has changed.
> Please note that programming high level languages is more about thinking
> than typing, so a low character count is not necessarily a proof that they
> do almost nothing. But a 0 character count many days in a row almost
> certainly is :)
> You should also use a task management system, which allows both of you to
> comment on tasks and allows the developer(s) to indicate what they're
> working on and what's finished. You do have defined tasks (stories,
> features, ...), don't you?
>
> Some developers will likely react to this level of micro-management
> (although it's not really management, as they tell you what they will do,
> not vice versa - micro-monitoring maybe). I will have to warn you that
> while applying rules and regulations for how work should be done probably
> will scare away a large number of the less desirable people, it is also
> likely to scare away the best ones (at least if you throw the rules in
> their faces as soon as you meet). I'd try first, like you already did, to
> see if they can manage without your regime.
> No situations and no developers are exactly the same so there may be a
> number of reasons for them refusing to follow this scheme, or for agreeing
> but later on simply ignoring it. It could be that they know they would be
> caught not doing much, but it could also be that they are so experienced
> with self management that they find this degree of monitoring unnecessary
> and annoying. Just like Ruby, both control and freedom are double edged
> swords (although Ruby is more like a chain saw apparently).
> From my experience though, a lot of good developers impose a similar
> routine on themselves anyway and may even suggest it to you, as well as
> imposing rules on *you* to make sure you're constantly in the feedback loop
> and they don't have to stop work because of lack of information from you.
>
> It's a difficult balance - software development management is not as easy
> as it seems... Besides, if there was a solution that worked in all cases,
> I'm sure you could just google it and find the fool proof answer right away
> :)
>
> I wish you good luck!
> Ronny.
>
>
> Ryan Kalish wrote:
>
>> Hi All
>>
>> This is my first message. I've heard great things about this community.
>>
>> I'm trying to launch a ruby based web startup, currently bootstrapping
>> an ecommerce idea which I believe can be highly profitable soon after
>> launch. I have employed a freelance rails developer based in Pakistan
>> through Odesk. He has been working for six weeks but progress has been
>> slow. I am not a developer so its difficult for me to know if I'm just
>> being impatient.
>>
>> I would be very interested to meet with London based rails developers
>> to discuss the project, look at what this guy is doing and maybe find
>> someone to work with on this.
>>
>> Please get in touch!
>>
>> Ryan
>> ______________________________**_________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/**listinfo.cgi/chat-lrug.org<http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>>
>>
>>
>
> ______________________________**_________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/**listinfo.cgi/chat-lrug.org<http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120629/f68fd0b3/attachment-0003.html>


More information about the Chat mailing list