[LRUG] Chat Digest, Vol 77, Issue 42

Fri Jun 29 04:30:07 PDT 2012

>  I'm technical so we worked out expectations in advance and set very granular tasks,
> usually less than a day per task and never more than two or three days.
+1 - this is the only sane way to write stories, even for co-located
teams. For distributed teams, it's practically mandatory.

I would also suggest setting up a CI server that auto-deploys every
green build to your staging environment. This way, every commit winds
up on staging in short order with no manual intervention.

This makes a huge difference when (as a customer) you get to use
what's being built as it being built. Necessary prerequisites - rock
solid testing discipline (which comes for free with TDD) and the
ability to manage feedback so you're not throwing the current
iteration into turmoil.

Best,
Sidu.
http://c42.in
http://sidu.in

On 29 June 2012 16:35, Peter Nixey <petenixey at gmail.com> wrote:
> Wow. Great post from Ronny on managing remote developers. I thoroughly agree with everything that he wrote. I've done this on a number of occasions using daily checkins, pivotal and Skype. All of these things work really well and can even lead to better accountability and efficiency than you achieve in person.
>
> However there is just one thing that I wanted to add which was that my experience was that even the good developers enjoyed working this way. I'm technical so we worked out expectations in advance and set very granular tasks, usually less than a day per task and never more than two or three days. By having them break the jobs down over the phone with me into manageable chunks I let them set the expectations and they were happy to work to them.
>
> The key I think to the success of these projects was that I viewed my role as being a supporting one to them rather than that of an overseer. They appreciated the support whereas I'm certain they would have reacted badly to pure oversight. In all the PM work I've done things have gone well when I've taken that approach and badly when I've merely enforced accountability.
>
> Peter
> ----
> peternixey.com
> @petenixey
>
> Sent from an iPad
>
> On 29 Jun 2012, at 10:55, chat-request at lists.lrug.org wrote:
>
>> Send Chat mailing list submissions to
>>    chat at lists.lrug.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>    http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> or, via email, send a message with subject or body 'help' to
>>    chat-request at lists.lrug.org
>>
>> You can reach the person managing the list at
>>    chat-owner at lists.lrug.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Chat digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: First post (about managing remote developers) [OT]
>>      (Ronny Ager-Wick)
>>   2. Re: First post (about managing remote developers) [OT]
>>      (Sidu Ponnappa)
>>   3. [JOBS] ruby dev for an london based internet startup lovethis
>>      (Stuart Dillon)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 29 Jun 2012 12:22:56 +0800
>> From: Ronny Ager-Wick <ronny at ager-wick.com>
>> To: ryan.kalish at gmail.com, London Ruby Users Group
>>    <chat at lists.lrug.org>
>> Subject: Re: [LRUG] First post (about managing remote developers) [OT]
>> Message-ID: <4FED2DA0.1010208 at ager-wick.com>
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>> 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
>>>
>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 29 Jun 2012 11:02:21 +0530
>> From: Sidu Ponnappa <ckponnappa at gmail.com>
>> To: London Ruby Users Group <chat at lists.lrug.org>
>> Cc: ryan.kalish at gmail.com
>> Subject: Re: [LRUG] First post (about managing remote developers) [OT]
>> Message-ID:
>>    <CAH2qJ=7DzMUZZroMgag5kXO2usCQeX_Y=E3C9waHBGY-p1-f5w at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Ryan,
>>
>> One of the pieces of advice we give all prospective clients who are
>> non-technical is "Get a technical partner whom you trust and who can
>> evaluate the code being produced." You need someone you trust to vet
>> the work being done.
>>
>> Working with remote devs is tough enough without also being unable to
>> judge the quality of work produced. Of course, the problem with this
>> model is that if you choose the wrong partner, you're back to square
>> one, but "Quis custodiet ipsos custodes" so what can one do?
>>
>> As a Ruby consultancy, we'd examined this problem in some detail and
>> then written a blog post about how we'd try to look for an offshore
>> vendor if we ourselves had to[1]. But there's no way around having a
>> trusted, qualified person fill the CTO/VP Engineering role in your
>> business.
>>
>> Best,
>> Sidu.
>>
>> [1] http://blog.c42.in/identifying-good-offshore-ruby-and-rails-vend
>>
>> On 29 June 2012 09:52, 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
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 29 Jun 2012 10:50:18 +0100
>> From: Stuart Dillon <stuart at lovethis.com>
>> To: chat at lists.lrug.org
>> Subject: [LRUG] [JOBS] ruby dev for an london based internet startup
>>    lovethis
>> Message-ID: <8808AA64-0F07-49F3-B338-FF2ECEA3D8D7 at lovethis.com>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Hello
>>
>> We are looking for a ruby developer to join our team.  We are a small internet startup (good funding) and we are building out an API with a web and iOS client. Check out our iPhone app and web lovethis.com - its all still beta.
>>
>> Below is the usual job spec but we are flexible so drop me an email and lets arrange a chat  our  offices in soho and lets see if this might be something for you.
>>
>> cheers
>> Stuart
>>
>>
>> Our current stack
>>
>> Ruby/Rails, Rspec, Redis, MySQL,  Objective-C
>>
>>
>> Team
>> 3 developers  - 2 x Senior Ruby Devs & 1 x iOS
>> 1 technical project manager
>> 1 business person (CEO/founder)
>>
>> Desired technical skills in addition to being an awesome Ruby developer
>>
>> Scripting
>> ? Rackspace API integration (server integration & cloud files) ? Build deployment system (Capistano/Ruby)
>> ? Platform Provisioning System (Rackspace API)
>> ? Platform configuration (Puppet/Chef/Vagrant etc)
>>
>> DB
>> ? Mysql & Mysql replication
>> ? Redis (and probably some other nosql solutions)
>>
>> Server Administration (and all that entails) ? RedHat (or other linux distros)
>> ? Nginx & Passenger
>> ? RVM
>>
>> ? Monit / God
>> ? Munin
>> ? Security
>> ? Knowledge of networking, load balancers, firewalls etc
>>
>> Company
>>
>> LoveThis lets you swap recommendations between friends. It connects you with your friends via your existing social groups, including Facebook and email; and makes it easy to give and get recommendations via the web, mobile phone and Twitter. Word-of-mouth is currently inefficient ? finding the right person for a recommendation is accidental; remembering that recommendation is the exception. LoveThis makes word-of-mouth simple, quick, and efficient.
>>
>> LoveThis helps customers to navigate the incredible number of choices they have on how to spend their time and money, by giving them access to the tried and tested recommendations of the people they trust most ? their friends. By doing so, it helps consumers:
>>
>> ? find new things to do, with the confidence that they?ll enjoy them.
>> ? save time searching for the best solutions.
>> ? swap things which they've already enjoyed amongst their friends,quickly and easily.
>>
>>
>>
>> On 26 Jun 2012, at 22:02, chat-request at lists.lrug.org wrote:
>>
>>> Send Chat mailing list submissions to
>>>    chat at lists.lrug.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>    http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>> or, via email, send a message with subject or body 'help' to
>>>    chat-request at lists.lrug.org
>>>
>>> You can reach the person managing the list at
>>>    chat-owner at lists.lrug.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Chat digest..."
>>> Today's Topics:
>>>
>>>  1. Re: Pre/Post/During SRC meetup? (Murray Steele)
>>>  2. [jobs] Freelance developer wanted for small project in London
>>>     (Alex Brown)
>>>
>>> From: Murray Steele <murray.steele at gmail.com>
>>> Subject: Re: [LRUG] Pre/Post/During SRC meetup?
>>> Date: 26 June 2012 14:02:28 GMT+01:00
>>> To: London Ruby Users Group <chat at lists.lrug.org>
>>> Reply-To: London Ruby Users Group <chat at lists.lrug.org>
>>>
>>>
>>> I should be there a bit later on.
>>>
>>> Also, now it's all "official" and that: http://lrug.org/nights/2012/06/26/episode-22-heat-rays/
>>> Even has a Lanyrd: http://lanyrd.com/2012/lrug-nights-june/
>>>
>>> Woo!
>>>
>>> On 26 June 2012 13:20, James Adam <james at lazyatom.com> wrote:
>>> How dare you meet in one of my local pubs while I'm out of town!
>>>
>>> (Have fun)
>>>
>>> - James
>>>
>>>
>>>
>>> On 26 Jun 2012, at 06:52, Tim Cowlishaw <tim at timcowlishaw.co.uk> wrote:
>>>
>>>> Quick heads up for those of you who will be in town this Thursday -
>>>> we're meeting in the Lord Wargrave[1] on Brendon Street W1H for Whisky
>>>> and Ruby-chat from about 6.30. Come and join us if you fancy it!
>>>>
>>>> Cheers,
>>>>
>>>> Tim
>>>>
>>>> REFERENCES
>>>> -----------------------
>>>> [1] http://www.youngs.co.uk/pub-detail.asp?PubID=347
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.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
>>>
>>>
>>>
>>>
>>> From: Alex Brown <alex at souliss.com>
>>> Subject: [LRUG] [jobs] Freelance developer wanted for small project in London
>>> Date: 26 June 2012 14:46:23 GMT+01:00
>>> To: London Ruby Users Group <chat at lists.lrug.org>
>>> Reply-To: London Ruby Users Group <chat at lists.lrug.org>
>>>
>>>
>>> Hello all,
>>>
>>> I'm a freelance UI/Javascript developer working on a personal project.
>>> I'm looking for a rails developer based in London to take on a few days of billed work helping me build out the rails side of my application.
>>> No frontend work is required, just some components to be built into an existing small app.
>>>
>>> I'll be at the LRUG meeting on the 9th of July.
>>>
>>> I've found freelancers a couple of times via LRUG in the last 3-4 years, and always had a positive experience, so looking forwards to hearing from anyone.
>>> Please reply directly to alex at souliss.com if interested.
>>>
>>> Regards,
>>> Alex Brown
>>>
>>> http://www.souliss.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.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/72d90d81/attachment.htm>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>> End of Chat Digest, Vol 77, Issue 42
>> ************************************
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org