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

Mon Feb 27 04:22:02 PST 2017

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
>