<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi, Artan,<br>
<br>
I completely agree with you. As an independent consultant (or whatever
we should call ourselves now) I am also working remotely, and wouldn't
consider anything else. I also feel I'm more efficient and it's much
more practical, and family friendly, compared to being location bound.
Doing the kind of work we do should allow us to do it from anywhere we
please, and personally I feel there is little need for being place
bound like an old fashioned industry worker. Yes, I know there are some
exceptions (like pair programming and occasional interaction with
users), but that still doesn't justify 9-5 work, as far as I'm
concerned.<br>
<br>
As I mentioned in the original post, having a developer in house is far
from fool proof, but it tends to have a higher percentage of success. I
must admit, this is purely speculation based on hearsay though - maybe
I'm even wrong and it's just "traditional knowledge" that dictates that
as a fact. The reason I allowed this statement without collecting any
evidence, is again personal experience. Being in the same office makes
it a degree harder to slack off and do nothing, or sit for hours trying
to do a simple thing which could be done with a bit of help, maybe
because someone may open your door at any given time and ask what the
heck you're doing. It's harder to ignore that question compared to the
same by email. Also, if you deal with a remote developer and there is
little contact throughout the working day, and no or very long feedback
cycle, you may sit there thinking the developer went on holiday or
something - something a physical presence effectively eliminates :)<br>
I can say this because I've been on both sides. In my early career I
briefly worked in house for two different - *very* different software
companies. And I've seen both great developers working in house, as
well as those who were a complete waste of time and money - or worse
(the ones who screw things up so badly someone else has to spend their
time fixing it all). I still do software development now, as well as
all the other things, because I enjoy it and (feel that I) have a
talent for it so I know how easy it is to be distracted, and have a
fair idea of how to avoid it. Being able to make yourself unavailable
at times is pretty much essential (but hard if you're in an office
environment), but imposing a good regime of short feedback cycles and
transparency on yourself is key. It's just better for everyone involved.<br>
So yes, to finally answer your question, you're absolutely right - the
"regime" I describe could be used for in house developers just as well
as remote ones.<br>
<br>
I need to point out that I would feel much better if the developers
themselves suggested a routine that aims to encourage transparency,
accountability and cooperation, as has been the case with a lot of the
developers I've worked with. Going along with the developers' way of
doing it, providing it gives you a similar level of progress
monitoring, is much preferred, as it is unlikely to meet any
resistance, and they're likely to have more experience using the system
than any manager they'll ever meet.<br>
I would only impose ("suggest" is maybe better) a system on developers
who don't already have a system or have proved incapable of delivering
already.<br>
<br>
Ronny.<br>
<br>
<br>
Artan Sinani wrote:
<blockquote
cite="mid:CAF7RF089+OdX6UhQ1K+Wx84GHHu+ddQcHawKDJoOn_5UKni6Gw@mail.gmail.com"
type="cite">Hey Ronny,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Artan<br>
<div><br>
<div class="gmail_quote">On 29 June 2012 05:22, Ronny Ager-Wick <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ronny@ager-wick.com" target="_blank">ronny@ager-wick.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
>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.<br>
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 :)<br>
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?<br>
<br>
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.<br>
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).<br>
>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.<br>
<br>
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 :)<br>
<br>
I wish you good luck!<br>
Ronny.<br>
<br>
<br>
Ryan Kalish wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi All<br>
<br>
This is my first message. I've heard great things about this community.<br>
<br>
I'm trying to launch a ruby based web startup, currently bootstrapping<br>
an ecommerce idea which I believe can be highly profitable soon after<br>
launch. I have employed a freelance rails developer based in Pakistan<br>
through Odesk. He has been working for six weeks but progress has been<br>
slow. I am not a developer so its difficult for me to know if I'm just<br>
being impatient.<br>
<br>
I would be very interested to meet with London based rails developers<br>
to discuss the project, look at what this guy is doing and maybe find<br>
someone to work with on this.<br>
<br>
Please get in touch!<br>
<br>
Ryan<br>
_______________________________________________<br>
Chat mailing list<br>
<a moz-do-not-send="true" href="mailto:Chat@lists.lrug.org"
target="_blank">Chat@lists.lrug.org</a><br>
<a moz-do-not-send="true"
href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a moz-do-not-send="true" href="mailto:Chat@lists.lrug.org"
target="_blank">Chat@lists.lrug.org</a><br>
<a moz-do-not-send="true"
href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Chat mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a>
<a class="moz-txt-link-freetext" href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a>
</pre>
</blockquote>
<br>
</body>
</html>