[LRUG] [JOBS] Freelancer. And some reflections.

Mon Feb 27 05:37:06 PST 2017

Hey everyone!

Leaving my 5 cents here. I've worked in a fully remote team that turned to
on-site later. My takeaway is that working remotely most of the time is not
a problem. When people are motivated they will proactively look for
information, work and deliver. On the contrast when they are not motivated
they will slack. To my experience this is irrelevant to location. I've had
"locals" under-perform and "remotes" do great. Mentoring to me means
showing someone how you would do it, github, PRs, codereview, screenshare
in my opinion is good enough. Face to face (video calls) is also good
enough but it needs to happen. Which is not guaranteed and needs to be
encouraged.

I would agree though that a big timezone difference can be a problem. There
needs to be enough overlap every day when everyone is online and available
to make up for the lack of documentation that always exists. I would also
agree that discussions happen in a relaxed setting while having coffee or
lunch, but I think relying on "lunch brakes" to spark productive
conversation is flawed. When those don't happen it's a
management/culture/motivation problem that is probably still easier to
solve on site.

I missed my remote coworkers the most when there was time to celebrate. You
just can't screenshare a beer.

On Mon, 27 Feb 2017 at 13:22 Sleepyfox <sleepyfox at gmail.com> wrote:

> Whilst I agree with the sentiment of some of the respondents regarding
> documentation (because I've often suffered from incomplete, inaccurate
> or missing docs) I am also acutely aware of the problem of implicit
> vs. explicit knowledge, e.g. you can only document the things that you
> know you know about. The majority of our knowledge is embedded in our
> subconscious and not available to be 'captured' in an online (or
> offline) medium like code comments, READMEs, design docs etc.
>
> Even if _all_ the knowledge _were_ explicit, we still face the
> inevitable trade-off of time and cost vs. benefit in _what_ to
> document, and the decisions that we make are grounded in our own
> myopic viewpoint and our own muddled thinking of what is relevant vs.
> irrelevant. Time and experience helps us to be a better judge of what
> to document, and when, but it is a real 'undiscovered country' skill
> in the repertoire of professional developers.
>
> So whilst I agree that good documentation certainly helps remote work
> be more effective for a team, in my experience there are many other
> contributory factors that affect the success of a team, including but
> not limited to shared goals, an empathic understanding of differing
> cultural values amongst the team, a shared understanding of the
> problem space, regular and effective communication, and a consensus of
> opinion on a sensible approach to implementing the chosen solution.
> I'm sure I've missed many.
>
> It is so tempting to regard good documentation as a silver bullet: "If
> only we could get the docs up to scratch we could totally nail this
> distributed team project"...
>
> TL;DR: Good documentation is often necessary, but not sufficient.
>
> @sleepyfox
>
>
>
> On 27 February 2017 at 11:10, Andrew France <andrew at avito.co.uk> wrote:
> > Wanted to say that I think Jon is exactly right. I'm lucky enough to be a
> > part time remote freelancer in another country at the moment and the
> process
> > with my client is superb because all tasks are documented, all code goes
> > through PR review, and any questions are handled asynchronously through
> > Slack or ticket comments. Of course I miss out a bit on the company
> culture
> > and various informal discussions.
> >
> > I also have a lot of experience working on-site in open plan offices
> where
> > things are poorly documented and team members frequently interrupted one
> > another to discuss things in person. I've found that often the critical
> > knowledge accumulates to a "super" dev who knows everything by virtue of
> > being there the longest. They end up constantly having to answer
> questions
> > or become a bottleneck when they are unavailable.
> >
> > Neither is perfect for every situation. A rapid prototype is probably
> going
> > to benefit from a small team sitting next to each other. But for most
> things
> > I think that it's purely down to process whether remote workers can be
> > beneficial or not.
> >
> > (full disclosure, I'm also looking for p/t remote or on-site Berlin work
> at
> > the moment! :D)
> >
> > Andrew
> > @odaeus
> >
> >
> > On Mon, 27 Feb 2017, at 11:52, Jon Wood wrote:
> >
> > My feeling from what people have said so far is that reactions to remote
> > work, working from a different timezone, and working part time all boil
> down
> > to the same questions of how one works with somebody who isn't currently
> > sitting next to you so you can walk over and ask them questions. The
> answer
> > to that in my experience is to make sure everything is properly
> documented -
> > with a co-located fulltime team you can get away with building something
> and
> > assuming people will come and ask you if anything needs clarifying,
> that's
> > much less true if the person who built the feature is now off work until
> > Thursday.
> >
> > The nice thing is that once you have developed a culture of properly
> > documenting everything and making sure all communication happens using
> > mediums that can be searched you also deal with the other circumstances
> in
> > which you find you can't just walk over to somebody. Holidays, maternity
> > leave, people leaving the company. Situations in which you can't just ask
> > somebody about their code aren't unique to companies with remote
> employees,
> > they're just surfaced earlier and more frequently.
> >
> > On Mon, 27 Feb 2017 at 10:40 Patrick Gleeson <patrick at gojimo.co.uk>
> wrote:
> >
> > Re the bit of the question about part-timers, I have to say that the
> various
> > times I've been looking for a coder I've never even considered part-time
> > developers. The reason being, I'm always hiring someone to be part of a
> team
> > (even when it's a teeny tiny team). When a team of coders works together
> > it's a very involved, collaborative process. You can make it work if
> people
> > are remote, as long as you have good communication hygiene, but having
> > someone who's not available 2 days a week? That really messes with the
> > dynamic, both on a practical level ("WhyTF did they do it like this?" /
> > "Dunno, and we can only ask them when they're back in on Thursday, so
> you'd
> > better not touch that class until then."), and more importantly on a
> > psychological one: people are tribal, and if you're not fully in the
> tribe
> > you're an outsider.
> > Of course, if the whole team worked part-time, with the same days off,
> you'd
> > sidestep that. But even if the feel-good factor offset some of the lost
> > hours, your output will still drop, and I've never worked for a company
> that
> > wasn't in a desperate hurry to get stuff done....
> >
> >
> > On 27 February 2017 at 10:23, Thomas Buckley-Houston <tom at tombh.co.uk>
> > wrote:
> >
> > Wow Evgeny, I really appreciate the feedback. It gives me a much more
> > digestible perspective than, "no, sorry, not at the moment" (which is
> > of course a legitimate response itself).
> >
> > I should have mentioned though that all the places I'm applying
> > clearly express remote focuses or remote friendliness. So I totally
> > understand your preference for face to face, it's a basic human medium
> > we've evolved over millions of years. And I love your;
> >
> >> I need a person who will look at the company and figure out how to
> prevent
> >> half the tickets from appearing.
> >
> > Also perhaps I could make clearer that I'm not just looking for short
> > term contracts. I'd love a permanent part time role, I just have no
> > need for the kind of money full time involves.
> >
> > Anyway, like I said, this is such a first-world problem. But still I
> > very much appreciate the feedback.
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> >
> >
> >
> > --
> >
> > Patrick Gleeson
> >
> > Senior Ruby Developer
> >
> > Gojimo is available on iOS, Android (beta) and web (beta)
> >
> > EducationApps Ltd is a registered company in England, No. 07556427
> >
> > Gojimo, c/o Edspace, Block D Room 203, Hackney Community College, London
> N1
> > 6HQ
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> >
> > --
> > Avito Ltd
> > Company 05946211 registered in England.
> > Reg. office: 23 Hoadly Road, Cambridge, CB3 0HX
> >
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: 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/20170227/ef48f139/attachment-0002.html>