Avdi Grimm

Part two in my “live”-style screencast series is now available! Watch me code up a small web app from scratch using test-driven development.

In this hour-long episode, I switch from integration testing to unit testing in order to drive out some more features for the Sinatra-based web service I’ve been building. You’ll see me:

• Use the “hub” gem to interact with GitHub.
• Talk about the decision point to drop from integration to unit testing.
• Use IO.popen to pipe text through an external process.
• Isolate tests for filesystem interaction using simple dependency injection.
• Use Enumerable#each_cons and enumerators to identify a sub-sequence in an Array.
• Use the Pathname standard library.
• …and more!

Did you miss part 1? Get it now:

I hate underscores. They are ugly. They are like the neon orange belt pack of syntax. Dated and unfashionable no matter what era they are found in. As the former owner of a neon orange belt pack, I feel I can speak with authority on this. Aesthetically speaking, underscores are one step shy of “C:\Progra~1“.

Only nerds even know what an underscore is. What’s the first thing I have to teach people who are brand new to programming? What the hell an underscore is, and where to find it on the keyboard. No, not that line. The other line. Hold down shift. There you go.

Underscores require me to hit the Shift key. When writing prose, I only hit the shift once or twice per sentence.  In Ruby, I have to hit the shift key every few letters. Awkward. Inefficient.

I’ve been thinking about rebinding the dash key to underscore in Emacs ruby-mode. It’s stupid that I’m even considering such a thing.

Underscores are visually ambiguous. When the font is underlined for some reason, the underscores get muddled up with the underlining. In badly-rendered text boxes it’s not always clear where the underscore leaves off and the bottom border begins.

CamelCase is no better. I still have to hit Shift all the time. Plus it relies on a peculiarity of the Latin family of languages.

Lisp gets it right. Lisp S-expressions have one basic rule that vastly simplifies the syntax: whitespace separates tokens. Always.

This means that “foo - bar” parses out to the three tokens “foo”, “-”, “bar”. Whereas “foo-bar” is a single token that happens to have a dash in the middle. That’s right, your tokens can have dashes in the middle. Ordinary, easy-to-type, recognizable, visually unambiguous dashes. Lisp functions have names like:

find-file

All you have give up for this is tightly-packed arithmetic statements, like this:

5*5-3

Instead, you have to give your tokens some breathing room:

5 * 5 - 3

That’s a trade-off I’ll gladly make if it means using dashed identifiers instead of underscores.

I mostly code in Ruby these days, and I love almost every aspect of its very rich syntax. But I hate all the snake_casing. I want a Ruby that lets me use dashes in identifiers. If I never type another underscore, it will be too soon.

UPDATE: The Recursive blog points out that Japanese keyboards may be more comfortable for typing Ruby.

One of the points I try to make in Objects on Rails is that you don’t need to let other libraries or frameworks dictate the public face of your objects. Just because you use ActiveRecord, for instance, to persist the state of an object doesn’t mean you have to commit that object to honoring the effectively infinite ActiveRecord model API. You can use the facilities of ActiveRecord internally to that object, but still project a tidy, well-understood, easily-substituted interface to the rest of the system.

And of course you can do this entirely by convention, by simply being careful to interact only with the methods you’ve explicitly exposed. But it’s easy to forget these conventions in the heat of implementation, gradually coupling the rest of the program to more and more framework-provided methods until one day you discover that your object’s interface surface area has become quite large indeed.

As an exercise in mindfully limiting the interface exposed by objects and classes, in Objects on Rails I demonstrated a tool called “FigLeaf“. FigLeaf gives you something akin to the “private inheritance” found in some other OO languages. While it doesn’t actually hide the fact that a class is derived from a framework class, it enables you to selectively privatize some, most, or all methods derived from ancestor classes and modules.

Here’s an example from the readme

class Post < ActiveRecord::Base
  include FigLeaf
  hide ActiveRecord::Base, ancestors: true,
       except: [Object, :init_with, :new_record?, 
                :errors, :valid?, :save]
  hide_singletons ActiveRecord::Calculations, 
                  ActiveRecord::FinderMethods,
                  ActiveRecord::Relation
  # ...

And here’s what happens when we try to send class or instance-level messages which have been hidden by FigLeaf

ruby-1.9.2-p0 > Post.find(1)
NoMethodError: private method `find' called for #<Class:0xa1a4a50>

ruby-1.9.2-p0 > Post.new.destroy
NoMethodError: Attempt to call private method

Today I’m happy to announce that thanks to the dilligent efforts of Sammy Larbi, FigLeaf is now available as a RubyGem. You can install it with:

gem install fig_leaf

The project is also available on GitHub.

It’s important to note that FigLeaf is not intended as a hammer to keep your coworkers or your library clients in line. It’s not as if that would work, anyway; the strictures that it adds are easy enough to circumvent. Instead, it’s intended role is more along the lines of the “rumble strips” along highways which give you a jolt when you veer off into the shoulder. It provides a sharp reminder when you’ve unthinkingly introduced a new bit of coupling to an interface you are trying to keep isolated from the rest of the codebase. Then, you can consciously make the decision whether to make that method public, or find a different way of going about what you were doing.

Got questions or suggestions about FigLeaf or about OO practices in general? Please join us on the Objects on Rails discussion list!

@CapnKernul writes:

[do you know of] a Ruby idiom for converting an object to a type if it isn’t already that type. For example, if you want to only store an attribute of type Foo, you could write an accessor method that would pass any non-Foo object to Foo’s constructor.

There is a de facto idiom among Ruby built-ins to define a method with the same name as a class for doing conversions to that class. My favorite is Kernel#Array:

Array("foo")                    # => ["foo"]
Array([1,2,3])                  # => [1, 2, 3]
Array(nil)                      # => []
Array({:a => 1, :b => 2})       # => [[:a, 1], [:b, 2]]

But there are others. Kernel#Integer provides a stricter form of integer conversion than does #to_i:

"42".to_i                       # => 42
Integer("42")                   # => 42
"30 seconds".to_i               # => 30
Integer("30 seconds")           # =>
# ~> -:4:in `Integer': invalid value for Integer(): "30 seconds" (ArgumentError)
# ~> from -:4:in `<main>'

And there are also Kernel#String, Kernel#Float, Kernel#Complex, and Kernel#Rational:

String(123)                     # => "123"
Float("123")                    # => 123.0
Rational(4,5)                   # => (4/5)
Complex(1,3)                    # => (1+3i)

You can also find this in standard libraries. The URI library defines an idempotent conversion method for URIs:

require 'uri'

u = URI("http://example.com")   # => #<URI::HTTP:0x000000030cac80 URL:http://example.com>
URI(u)                          # => #<URI::HTTP:0x000000030cac80 URL:http://example.com>

There’s also Pathname:

require 'pathname'

p = Pathname("~/.emacs.d")      # => #<Pathname:~/.emacs.d>
Pathname(p)                     # => #<Pathname:~/.emacs.d>

I like to extend this idiom into my own code for idempotent conversions into commonly-used value objects. I did this in Objects on Rails for TagList objects.

module Conversions
  private
  def TagList(value)
    return value if value.is_a?(TagList)
    TagList.new(value)
  end
end

The TagList method is shorter than calling TagList.new(...). And in addition, it’s safe to call on inputs which might or might not already be TagList objects.

Although they may look a little odd at first, capitalized conversion methods are a well-established Ruby idiom for methods which “do the right thing” to convery any reasonable input value into a desired class. And because unlike #to_x methods they are outside of the objects being converted, they incur none of the maintenance danger of a monkey-patch. I don’t define them for every class in my program; but for oft-used value object types they can be quite convenient.

I’m working on Facebook Open Graph features for a client, and developing these features requires enabling Facebook to somehow crawl my locally-served pages. I asked around for solutions to this problem, and got a pretty long list of replies. I’m listing them here for future reference.

All of these offer a pretty similar service: you download a command-line tool (often in the form of a Ruby gem), start up your server, run the command, and hey presto, your local pages served on localhost:3000 are now being served at http://yoursubdomain.example.com. Most, if not all, use SSH tunneling as the underlying technology.

• Showoff.io: 5m free, $1 for a day pass, otherwise $5/mo unlimited.
• Pagekite: Features transparent SSL support and unlimited subdomains. $5/mo for a basic plan. EDIT: Looks like they also provide a Debian/Ubuntu package source, nice touch! EDIT2: PageKite informs me that their service is as low as $3/mo for an individual, and that they do not use SSH as their underlying tunnel in order to be friendlier to Windows users.
• Localtunnel: Free, sponsored by Twilio. Looks similar to Showoff.io.
• Tunnlr: Explicitly marketed to FB developers. $5/mo for a single subdomain (notice a trend?)
• ProxyLocal: Free, appears very similar to Showoff.io, LocalTunnel, etc.

A couple weeks ago I created cowsays.com, in an effort to introduce the joy of Cowsay to more people. In the announcement I talked about how I created the site over a 24-hour period (not counting some UI tweaks). What I didn’t mention was that I also recorded the entire process.

Since then I’ve been working on editing the video in my spare time, and I’m happy to announce that today part 1, (“Zero to Heroku”), is ready and available.

This video series is a raw, over-the-shoulder look at my solo development process. I narrate what I’m doing and thinking as I work, and occasionally I digress to explain why I’m making a particular decision. I’ve tried to edit out the really long pauses. But you’ll still hear a lot of “hm, what next?”.

In this first hour-long video I take the app from an empty directory up through a successful “tracer bullet” deployed to Heroku. Along the way, you’ll watch me:

• Start with nothing but a failing integration test.
• Use IO.popen to call out to Perl from Ruby.
• Set up Guard to automate my tests and Bundler updates.
• Use Hub and Magit to simplify working with Git and GitHub.
• TDD a simple Sinatra service using RSpec and rack-test.
• Create a Heroku app.
• Create a Rackup file and deploy to Heroku.

Sound interesting? It’s yours for $5.

Over the coming weeks I’ll be releasing the rest of the series. I have all the video, I just need to edit it. In upcoming episodes you can expect to see:

• Refactoring the Sinatra app from a “classic” app to a “modular” style app.
• Switching to Unit Tests as method logic increases in complexity.
• Adding more cowsay features.
• Smoothly migrating from a Sinatra app to a Rails app that mounts the Sinatra app as a service.
• Using Datamapper for persistence.
• Using Erector for object-oriented views.
• Using Coffeescript and jQuery to liven up the UI.

NullDB, for those who don’t know, is a null backend for ActiveRecord. Unlike RSpec’s stub_object, rather than raise an exception on DB access, will NullDB DB interactions simply become no-ops. This is handy for things like testing after_save hooks in isolation.

Myron Marston has done a stellar job shepherding it through the Rails 3 transition, but he’s busy with other awesome projects now and has asked me to look for a new maintainer. So: If you’re interested in helping keep NullDB up to date with the latest changes to ActiveRecord, please get in touch!

This is not strictly software-development-related, but a number of developers have asked me about my experience finding and working with a remote assistant. I’ve had my assistant for a few months now and I thought I’d jot down some notes on the experience.

I find the subject of starting and interacting with other OS processes fascinating. A few years ago I wrote a never-completed series on the many ways to spawn off processes in Ruby:

• Part 1: Backticks and system()
• Part 2: Opening pipes to processes
• Part 3: Open3, PTY, and Shell standard libraries

However, those were all written for Ruby 1.8, and are a little out of date.

Ruby 1.9 substantially expanded and revamped the Ruby process API. Many of the tasks which once required third-party gems like Open4 can now be easily accomplished using the built-in calls. Particularly notable is that Process.spawn was added with a comprehensive set of options for customizing how the process is started, and the other standard process-starting calls were updated to accept the same set of arguments as Process.spawn.

Here’s how www.cowsays.com starts a Perl process in order to generate ASCII-art cows:

cowsay_path = Pathname(__FILE__).dirname + "../bin/cowsay"
perl_path   = "/usr/bin/perl"
cows_path   = Pathname(__FILE__).dirname + "cowsay/cows"
env         = {
  'COWPATH' => cows_path.to_s
}
args        = %W[-f #{@cowfile}]
@io.popen([env, perl_path, cowsay_path.to_s, *args], 'r+') do
  |process|
  process.write(message)
  process.close_write
  process.read
end

Notes:

• Since I know where Perl is found on Heroku boxes, I hardcode the path to it. Unless you have a specific reason for allowing program paths to be overridden, it’s always safer to hardcode the path to executables. That’s one less vector for attacks.
• @io simply points to the IO class in production. It’s an instance variable so I can write isolated unit tests verifying how my code interacts with the system.
• IO.popen starts a process and creates a pipe to that process, which your program can use to send data into that process’ STDIN, and read data from its STDOUT.
• I pass an array instead of a string to IO.popen. If you pass a string, Ruby will start up a shell process and pass the string to the shell for interpretation. This is handy for commands like ls -l *.rb where you want standard shell-expansion to be performed. It’s also very dangerous when dealing with user-supplied data; it opens up a door for shell-injection attacks similar to SQL injection exploits. Only shell-injection is even more dangerous, since a shell injection can potentially execute any command that your server process has the rights to execute.
• The array version, by contrast, skips the shell. The arguments are passed directly to the process as strings in it the ARGV variable. This version is always my preference unless I have a specific reason to want to do shell expansion. This is also why I avoid backticks (`some-command ...`) or %x() except in little personal-use scripts.
• I make use of another feature of IO.popen, Process.spawn and friends: I customize the environment variables the process will see by passing a hash as the first argument. I want more Ruby programmers to know about this feature; I sometimes see code which accomplishes this effect by setting ENV['somevar'] before spawning a process and then re-setting it afterwards. Passing a hash is much cleaner.
• Note that by default, only the hash keys specified in the environment hash will be changed for the subprocess; the rest will be copied from the current environment. There’s an option, however, to use the hash as a complete replacement for the current environment. See the IO.spawn documentation for details.
• I pass r+ as the “file mode” argument. This tells Ruby I want to read from and write to the child process. The default is read-only.
• Note the line where I call process.close_write. This is very important, and something which bites a lot of first-time users of popen (it sure used to bite me!). With many programs, if you don’t explicitly close the pipe for writing after finishing your write, you’ll wait forever trying to read the program’s output. This is because the program being executed as a subprocess was written to read its input up to EOF before outputting and exiting. And it won’t get that EOF until you close the pipe for writing. In addition, the operating system may buffer the data flowing from your program to the subprocess, and calling .close_write forces that buffer to be flushed.

I hope you’ve learned something new about starting processes in Ruby from this post. If you have any process tips of your own, or any burning questions about spawning processes, feel free to bring them up in the comments!

By the way, if you’re interested in finding out more about working with UNIX processes in Ruby, the Ruby Rogues book club is currently reading Jesse Storimer’s book on the subject.

If you’ve seen my Confident Code talk you know I’m a fan of the cowsay utility.

cowsay "Quack"

 _______
< Quack >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

In fact, I like it so much I wanted to share it with people who might not have had a chance to try it yet. So I put it on the web.

Enjoy it for all of your ASCII-animal speech-bubble needs. The source code is on GitHub if you’re curious. Interesting implementation notes:

• It was written from scratch starting last Saturday night and then over part of last Sunday.
• The original Cowsay program, written in Perl, is included in the app. I use IO.popen to open a Perl process and generate the ASCII art.
• I started with a simple Sinatra service. Then I added Rails in, and mounted the Sinatra service in the routes file.
• I use Erector for views, and DataMapper for persistence (what little there is).

In this episode I talk to Louis Font of Zyncro. We talk about his internationally distributed team and how they, as a company, seek to be available to customers 24/7 no matter what time zone they are located in, solving communication gaps between businesses and social networks, and how important physical communication is in the world of remote work.

Show Notes:

ZyncroBlog
Twitter: @zyncro
Facebook

00:40 – Introduction

02:22 - Louis’ background

04:20 – Distributed team structure and background

09:08 – Challenges working distributed

10:30 – Cultural differences between team members

12:00 – Zyncro as a company

16:22 – Advice for distributed teams

17:20 – Future of distributed teams

In this episode I talk to Joseph Moore of Pivotal Labs. We talk about the challenges of moving from a collocated team to being a “satellite team member” thousands of miles away. What’s especially interesting about Joseph’s story is that he still pair-programs all day, every day with other members of his team despite being remote.

 Show Notes:

00:55 - Introduce Joe

01:41 – Interview begins

 01:58 – Joe’s background

04:50 – Pair Programming

06:55 – Pair Programming 100% of the time while remote

09:10 – Patience and Social Skills while Pairing

13:55 – Keyboard back & forth sharing

23:08 – Daily Pair Swapping

25:09 – Going from co located to remote (Joe’s experience)

27:18 – Daily Standups

32:01 – Daily check-ins with clients

33:56 - Social impact of going from co located to remote

36:40 - Advice for remote workers

38:17 – Type of person who can be successful at remote work

39:40 – How much of a “normal” work environment can be replicated with distributed teams?

40:35 – Aspects that are superior to remote versus co located work

42:00 – Remote pair programming and coworking

43:38 – Wrap Up

Hans de Zwart recently finished an experiment in which he encouraged his distributed team to “narrate their work”—to issue frequent updates to the team about what they were doing. In this article, he discusses the results of the experiment. This article was originally posted on Hans’ blog, and he has kindly granted permission to reprint it here.

A few months back I posted a design for an experiment on my blog. The goal of the experiment was to find out whether it would be possible to use a microblogging tool to narrate our work with the intention of making better performing virtual teams.

Over the last two months, the direct team that I work in (consisting of 18 people) basically participated in the experiment in the way that it was designed: They posted constant, daily or weekly updates on our Yammer network. Each update would describe things like what they had done, who they had spoken to or what issues they had encountered. Occasionally the updates were peppered with personal notes about things had happened or were going to happen after work.

Methodology of the experiment

There was no formal (or academic) research methodology for this working experiment. I decided to use a well-considered survey to get people’s thoughts at the end of it. Out of the 18 team members 17 decided to fill it in (in the rest of the post you can assume that n=17). The one person that didn’t, has taken up another role. This means there is zero bias in who answered and didn’t answer the survey.

I find it more interesting to zoom out and look at the methodology of this experiment as a whole. To me doing things like this is a very good approach to change in the workplace: a grassroots shared experiment with commitment from everybody working towards solutions for complex situations. This is something that I will definitely replicate in the future.

Didn’t this take a lot of time?

One concern that people had about the experiment was whether it would take a lot of time to write these updates and read what others have written. I’ve asked everybody how much time on average they spent writing status updates and reading the updates of others. This turned out to be a little bit less than 5 minutes a day for writing the posts and slightly over 5 minutes a day for reading them. The standard deviations where around 4.5 for both of these things, so there was quite a big spread. All in all it seems that narrating their work is something that most people can comfortably do in the margins of their day.

Barriers to narrating your work

Designing the experiment I imagined three barriers to narrating your work that people might stumble over and I tried to mitigate these barriers:

• Lack of time and/or priority. I made sure people could choose their own frequency of updates. Even though it didn’t take people long to write the updates, just over 50% of the participants said that lack of time/priority was a limiting factor for how often they posted.
• Not feeling comfortable about sharing in a (semi-)public space. I made sure that people could either post to the whole company, or just to a private group which only included the 18 participants. Out of the 18, there were two people who said that this was a limiting factor in narrating your work (and three people were neutral). This is less than I had expected, but it is still something to take into account going forward as 12 of the participants decided to mostly post in the private group.
• Lack of understanding of the tool (in this case Yammer). I made sure to have an open session with the team in which they could ask any question they had about how to use the tool. In the end only three people said that this was a limiting factor for how often they posted.

The qualitative answers did not identify any other limiting factors.

Connectedness and ambient team awareness as the key values

Looking at all the answers in the questionnaire you can clearly see that the experiment has helped in giving people an understanding of what other people in their team are doing and has widened people’s perspectives:

A quote:

I enjoyed it! I learned so much more about what my colleagues are doing than I would have during a webcast or team meeting. It helped me understand the day-to-day challenges and accomplishments within our team.

and:

The experiment was very valuable as it has proven that [narrating your work] contributes to a better understanding of how we work and what we are doing as a team.

People definitely feel more connected to the rest of their team:

There was practical and social value in the posts:

A lot of people would recommend “Narrating your work” as a methodology to other virtual teams:

What kind of status updates work best?

I asked what “Narrating your work” type of update was their favourite to read (thinking about content, length and timeliness). There was a clear preference for short messages (i.e. one paragraph). People also prefered messages to be as close as possible to when it happened (i.e. no message on Friday afternoon about what you did on the Monday). One final thing that was much appreciated was wittiness and a bit fun. We shouldn’t be afraid to put things in our messages that reveal a bit of our personality. Sharing excitement or disappointment humanizes us and that can be important in virtual teams (especially in large corporations).

Personally I liked this well-thought out response to the question:

The best posts were more than simply summing up what one did or accomplished; good narrations also showed some of the lines of thinking of the narrator, or issues that he/she encountered. This often drew helpful responses from others on Yammer, and this is where some some additional value (besides connectedness) lies.

It made me realize that another value of the narrations is that they can lead to good discussions or to unexpected connections to other people in the company. This brings us to the next question:

Public or private posts?

The posts in the private group were only visible to the 18 participants in the experiment. Sometimes these posts could be very valuable to people outside of the team. One of the key things that makes microblogging interesting is the asymmetry (I can follow you, but you don’t have to follow me). This means that posts can be read by people you don’t know, who get value out of it beyond what you could have imagined when posting. What to you might sound like a boring depiction of your morning, might give some stakeholders good insight in what you are doing.

So on the one hand it would be very beneficial to widen the audience of the posts, however it might inhibit people from writing slightly more sociable posts. We need to find a way to resolve this seeming paradox.

A way forward

Based on the experiments results I would like to recommend the following way forward (for my team, but likely for any team):

• Don’t formalize narrating your work and don’t make it mandatory. Many people commented that this is one aspect that they didn’t like about the experiment.
• Focus on helping each other to turn narrating your work into a habit. I think it is important to set behavioural expectations about the amount of narrating that somebody does. I imagine a future in which it is considered out of the norm if you don’t share what you are up to. The formal documentation and stream of private emails that is the current output of most knowledge workers in virtual teams is not going to cut it going forward. We need to think about how we can move towards that culture.
• We should have both a private group for the intimate team (in which we can be ourselves as much as possible) as well as have a set of open topic based groups that we can share our work in. So if I want to post about an interesting meeting I had with some learning technology provider with a new product I should post that in a group about “Learning Innovation”. If have worked on a further rationalization of our learning portfolio I should post this in a group about the “Learning Application Portfolio” and so on.

I liked what one of the participants wrote:

I would like our team to continue as we have, but the important steps to take now are 1) ensuring that we stay in the habit of narrating regularly, 2) showing the value of what we achieved to other teams and team leads, and 3) ensure that there is enough support (best practises etc) for teams that decide to implement [narrating your work].

I have now taken this as far as I have the energy and the interest to take it to. I would really love for somebody to come along and make this into a replicable method for improving virtual teams. Any interns or students interested?

(This article is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Netherlands License. It originally appeared here: http://blog.hansdezwart.info/2011/07/19/reflecting-on-the-narrating-your-work-experiment/)

A discussion with Dan Menard of Macadamian, covering the importance of taking the time to build personal relationships; the advantages of having a team that’s split across time zones, the practice of distributed code review, and much more!

Announcements:

Show notes:

03:15 – Dan’s background

04:02 – History with oversea startup

06:00 – Schedule Flexibility

07:28 – Importance of relationships

09:50 – Advantages of working with teams across time zones

12:00 – Tools

14:40 – Smartboard

17:06 – Code Review

19:00 – Adjustment to working with distributed teams

20:52 – Future of working with distributed teams

21:24 – Advice to distributed groups

In this episode, an interview with John Hawkins, one of the founders of 9Seeds, a company that specializes in custom WordPress development. The 9Seeds team is fully dispersed, with every team member working from home. We talked about how 9Seeds came to be a distributed company, and why John intends never to set foot in a brick-and-mortar office again.

Show notes:

• John Hawkins is @vegasgeek on Twitter
• 9Seeds LLC
• The Event Ticketing and Affiliate Manager WordPress plugins
• 9Seeds sponsors WordCamp conferences

For some remote workers, leaving the office behind is a choice to spend more time with family. For others, it’s a move to an environment more conducive to focus, or a way to travel the world while still making a living. Whatever your reason for working remotely, it’s good sometimes to reflect on the joys of living and working untethered to a desk.

I asked eight remote workers to tell me about their moments of remote work zen—those perfect moments that make it all worthwhile. Here are their answers.

–David Browning, co-founder of Two Guys

–Sahil Parikh, Founder of DeskAway

–Marieke Guy, blogger at Ramblings of a Remote Worker

–Ligaya Turmelle

–Jessica Dally, Project Manager at TechSoup

–D. Keith Casey, Jr., Chief Stuff Breaker at Blue Parabola

–Shane Pearlman, CEO of Shane & Peter, Inc.

What about you? What’s your moment of remote work zen?

In this episode I talk to Shane Pearlman of Shane & Peter, a fully dispersed software consultancy. We talked about recruiting  the right kinds of people for a distributed team, and how to stay connected as friends as well as coworkers.

Show notes:

• Shane Pearlman is @justlikeair on Twitter
• Shane & Peter
• Check out the Shane & Peter Lifeblog
• Redmine
• Adium
• Coworking
• Freelance Camp

Remote workers such as telecommuters and freelancers often face the challenge of little- to no-face time with team members.  Lack of in-person communication means one loses access and the non-verbal cues of team members, such as facial expression, body language and sometimes tone of voice.  As a result, remote workers face challenges such as misinterpretation of information, lack of information due to delay in response, and low team spirit due to limited personal interaction with team members.

There are ways remote workers can overcome these challenges with different communication techniques.  Knowing when to use e-mail, the phone, and instant messaging can also help everyone communicate more effectively.

1. Use the phone for urgent matters. If you have a question or a matter to discuss of urgent nature, you want to reach your team member over the phone so that you may receive an immediate response.  The telephone also allows you to obtain clarity on a response immediately if you have further questions.  Of course, there are times when you reach voicemail instead.  In that case, you want to leave a message that clearly indicates you have an urgent matter that needs to be discussed (if you have a specific deadline, indicate what it is), when you called, and request an immediate call back.
2. Gather your thoughts before communicating. Compile your thoughts, points and questions in one e-mail or on a piece of paper before going on a call.  If you are using e-mail and have two or more points or questions, use bullet points.  This makes it easier for you to receive responses to all items and for the team member to review and respond to you.
3. Respond promptly. It is important to respond promptly to all communications.  It’s already a challenge for team members to not be able to walk over to you with a quick question.  You want to make communication easy for everyone.  Your team members will appreciate your prompt responses and will catch on to this protocol.  In return, you should also receive prompt responses for any questions you have from team members.
4. Get to know your team members and let them get to know you. Face time helps a great deal when getting to know one another.  For remote workers, utilizing video conferencing such as Skype when appropriate helps with interpersonal communications.  Also in any day-to-day communication, whether via the phone or e-mail, make a point to be more personable by asking how your team member’s day is going, how their weekend was spent, and share with them what’s going on at your end.
5. Use “please” and “thank you.” E-mail and texting can leave a cold message.  There are times when the tone of a message can be misinterpreted.  By utilizing words such as “please” and “thank you,” it ensures your message’s tone remains positive and it also doesn’t sound demanding.
6. Provide and/or ask for confirmation. Before ending calls where direction is provided, always summarize what you understand to be the next steps and include deadlines.  This ensures both of you are on the same page.  A brief e-mail summary on to-dos is also helpful in keeping everyone on the same page.

Title photo “Hotline” by Grant Hutchinson

The latest and greatest news and resources for remote workers, from all around the web.

• Set Up Remote Colleagues With the Apps They Need Using Ninite: Online Collaboration «

  • Ninite has a selection of many of the most commonly used apps, including browsers, IM clients, media players, office apps, Flash, PDF readers, security tools, utilities and even some of WWD’s favorite tools, like Dropbox, Evernote and KeePass. The installer installs the most up-to-date version of the apps; running the installer again will update the apps to the latest version.

     

• iPad 2: The Best Tablet for Distributed Teams Just Got Better: Online Collaboration «

  I’ve talked about the importance of  a “comms appliance” for remote workers; the iPad 2may just be the best device yet for that role.

  tags: communication videoconferencing ipad

  • People who think that adding a camera to the iPad 2 is just a minor improvement aren’t people who work with remote team members and clients. Videoconferencing is increasingly popular; you need only look as far as the success of Skype and the rise of competitors to that service to find proof of that. The value of face-to-face communication actually increases as in-person dealings become more of a rarity, and it won’t be long before third parties join Apple’s FaceTime in the video chat game, and multi-person group video chat is right around the corner

     

• Teleworkers on the rise

  Great article about some of the advantages of working remotely.

  tags: telework

  • Carr said the benefits of teleworking greatly outweigh the stress of sitting in traffic and being distracted by the office atmosphere.”It becomes clear that the best employees are the ones not stuck in traffic,” he said.

     

• How to Work with Someone 12 Hours Away | Macadamian Blog

  Terrific article about one team’s experience with a very widely dispersed organization.

  tags: wideteams telework

  • It’s awesome when the critical path moves seamlessly from North America to Western Europe/Asia. For example, say you have 80 hours of tasks that can’t be done in parallel. A local team will need two weeks to do these tasks. A global team, on the other hand, can work separate 8-hour shifts and get them done in one week. That’s twice as fast!

    It’s awesome when my code is tested while I sleep. A small team of local developers can be extremely efficient when paired with a remote QA. I spend my day fixing bugs and adding features, and by the time I come in the next morning, these issues have been tested and either re-opened or closed. Prioritizing tasks is a breeze, and we don’t lose as much time on code freezes leading up to a release.

     

     

• Google Docs Turns Its Comments System Into a Conversation System – ReadWriteCloud

  tags: collaboration wideteams documents office remote communication

  • The new comments system works like a conversation thread on a Facebook, complete with @replies. When someone is tagged in a conversation, they will receive an e-mail notification. The user can then either click-through to the document, or simply respond to the e-mail. All the conversation is captured and stored in Google Docs with the document. If the notifications become too much, users can mute notifications.

     

• Implicit Communication and Virtual Teams | Leading Virtually

  Really insightful article about high-context and low-context cultures, and the different ways they can react to the challenges of remote work.

  tags: communication

  • Indicate to your team that research for virtual teams shows that, because of the challenges inherent in virtual work, being a little more explicit in communication is probably necessary. This may mean more of a challenge to high-context team members who are used to implicit communication. To help them feel more comfortable with being explicit, frame virtual work as a totally new way of doing things with a lot of learning to be done along the way.

     

  • team members will create rules of engagement which make explicit the what, when, who, and how of decision-making and communication within the team. Among the things covered by the rules of engagement are the nature and frequency of communication, communication media to be used, the values that the team will live by, the response times for messages, how conflict will be resolved, and how the decisions will be made, including who makes what decisions.

     

This podcast is a departure from the dispersed software development teams I usually cover. I interviewed Susan Tenby and Jessica Dally of TechSoup, a nonprofit focused on providing other nonprofits with the technology they need to better accomplish their missions. One way they assist nonprofits is in helping them to use Second Life, a massive on-line “virtual world”, to collaborate and build community online.

I talked to Susan and Jessica about why TechSoup is a distributed organization, and why organizations are using Second Life to meet, network, and do their work. For someone who spends a lot of time doing remote collaboration, it was eye-opening for me to discover this whole new frontier of online interaction. After listening to this interview you may just be inspired to add a virtual world meeting space to your own remote collaboration tool box.

Show Notes:

• Susan Tenby is @suzboop on Twitter
• Jessica Dally is @jessicadally
• TechSoup is @techsoup on Twitter
• Nonprofit Commons is @npsl on Twitter.
• A video about NPSL’s work in Second Life
• Second Life
• Hypergrid Business, a blog devoted to “enterprise users of virtual worlds”
• Community Voice Mail
• 5PM project management tool
• Evernote
• HootSuite
• BaseCamp