Some thoughts on meetings in distributed development teams

I've been working in distributed teams - either working remotely, or as part of a dev team split across multiple offices - for the last eighteen months. In that time I've had enough remote meetings to have formed some opinions about how to take them seriously.

Here are some things to keep in mind when dealing with meetings that span offices or timezones. There are plenty of pain points involved in this kind of development environment around communication in general which I'm not even going to try and address today. Meetings are just one facet of this problem, but they're surprisingly easy to do in a way that is horribly inefficient and frustrating.

Remote meetings suffer from the same problems as local meetings, but the consequences are exacerbated. If you don't take them seriously it'll waste your time, and it'll waste other people's time.

Show up to meetings on time

Meetings should start when they say they're going to start. This doesn't mean they should be called to order immediately, though - if you want to spend a couple of minutes to catch up and be sociable it can be a nice way to break the ice and get comfortable.

In my experience this works better when everyone has connected separately with their own headsets, rather than when it's groups connecting from meeting rooms - but your mileage will vary depending on how big the group is and how well the participants know each other.

This should really go without saying, but if you're not going to make it, let somebody know as far ahead of time as possible. As a developer, there's nothing worse than planning time in your day for something that falls through at the last minute.

Know what you're going to talk about

It sounds really stuffy and bureaucratic to call this "putting together an agenda" but I often find that stopping to think about what I want to accomplish with a meeting can help bring together my thoughts on the topic. In some cases, I've discovered that really I just need to talk to one person, or that I don't really need to have a meeting at all. It's much better to discover this before you've got everyone on a call together talking about the weather.

It can be a really good idea to publish this agenda beforehand, especially if it's a regular team meeting and not just a one-off about a specific topic. This gives people a chance to get in the right frame of mind, research the problems or topics if they're unfamiliar, and start thinking about contributions or questions if they don't already have them.

If you've got documents or links you're going to want to refer to, it's really important to prepare these ahead of time. Links to wiki pages, JIRA tickets, relevant bits of code - it's better to spent a few minutes collecting these things before you start rather than awkwardly searching for things in the middle of a conversation.

Finally, as a developer of software, I know that it's really easy for me to go down technical tangents in conversations - especially when those conversations are with other developers. Don't be afraid to park questions for a 1-on-1 later if they're not relevant to the task at hand, just remember to actually follow up.

Timezones, like relationships, are about compromises

You might be lucky enough that all your remote groups live in the same timezone, but it's more probable that you're separated by a couple of hours. Even a difference of two or three hours can have a huge impact on your ability to schedule meetings. A leisurely 10 AM meeting in New Zealand is an 8 AM start for most of the year in Australia; likewise, an afternoon meeting in Eastern Australia is dinner time for San Francisco.

You should ideally try to rotate the responsibility for starting early or staying late, and it's much easier to do this when everyone is remote. Generally you're going to be beholden to wherever the largest group is. If you're in the situation where all the meetings are at your convenience, show some sympathy for whoever had to get up early or stay late and refer to the points above to make it as easy on them as possible.

Running Open Wound locally using WampServer and Strawberry Perl

TL;DR: I'm hosting it here now, too.

 

I posted to a poetry group I follow on Facebook (which I would link to but you need to be logged into facebook to see, which sort of defeats the purpose) about Leonard Richardson's Olipy library, seeing as there are several people in the group who enjoy work from generated text.

The resulting discussion turned to Matt Butler's project, Open Wound, and the potential for getting it to run locally using something like XAMPP, since the site's version of it is broken.

Anyway. To cut a long story really short, this is how you do it on Windows:

Download and install Strawberry Perl.  Where you install it isn't super important, but you'll need to remember it later. I just installed it to the default, c:\strawberry.

From the start menu, select Strawberry Perl > Tools > CPAN Client.

A Command-line window will appear.  Enter the following command:

    install Lingua::EN::Tagger

It'll need to install a bunch of dependencies from a server, so give it some time. With any luck, it won't shout any errors at you. Eventually, it'll dump you back at the command prompt - type "bye" to quit.

Next, download Wampserver and install it using default everything. The version I used was this one - 2.4, 32bit, PHP 5.4 - but I doubt it matters.  At the end of the installation when it asks you if you want to run it, uncheck the box.

Go to c:\wamp (assuming that's where you installed it) and create a new folder called cgi-bin. Go to this new folder and drop the index.pl from your Open Wound download. 

Open index.pl up in Notepad and change the first line from

    #!/usr/bin/perl

to

    #!"\strawberry\perl\bin\perl.exe"

 (assuming you installed perl to c:\strawberry).

Save the file.

Go to the start menu and run Wampserver. Check for the system tray icon (it should be a little green W).

Visit http://127.0.0.1/cgi-bin/index.pl

When you're done, remember to close to close wamp from the system tray menu (left-click it and select "Stop All Services" and/or right-click and select "exit").

Overbearing and OAuth

So I built another stupid widget because I wanted to try to use the Twitter API - but I ended up being pretty disappointed by the result.

My goals at the outset were:

  • A single page widget that, given a specific Twitter user, returns the distribution of users responsible for the posts in their timeline
  • Preferably just in HTML if that's possible, because hosting a sinatra application or whatever is beyond the scope of my interest in this project

But I was immediately stifled by the 1.1 API.

  • Every request needs to be magically OAuth signed by your application
  • (somewhat less surprisingly) the home timeline requires user authentication

So what I had naïvely envisaged as a single page with some requests to the API had blown out into something that required an OAuth library. At this point I should have stopped, taken a long hard look at what I was trying to achieve, chosen a library in a technology I was comfortable with, and built something that could handle the OAuth user handshake robustly.

Instead,  I found a PHP library that would let me do it on one page, without worrying about any additional infrastructure. At the time I just wanted data, but retrospectively this was a mistake (mostly because I haven't touched PHP in three years).

The sole benefit was that I could put my twitter application keys in what was otherwise an HTML page and not worry about exposing them to the outside world; the downside is that the code isn't particularly attractive because a) I was just hacking on examples, and b) more than half of the code on the page is boilerplate for handling OAuth authentication. It's hardly something I'd be proud to release the source for (which, really, was most of the point of the exercise),

Even after making all these technological compromises in order to get data, the data I got didn't turn out to be very helpful. The Twitter API only lets you read the first 200 tweets of a timeline at a time, and the rate limit is particularly aggressive (15 calls / 15 minutes, compared to 180 for something like a lookup of a user's tweets)

This snapshot doesn't do a great job of illustrating the stated point of the exercise - prove one of your friends tweets too much - because it can only look at your most recent 200 tweets. When your feed is active, this snapshot can be for a time period of less than an hour; if someone is tweeting more aggressively than the rest, it's going to be pretty obvious.

Anyway, the moral of the story is that sometimes you have a great idea and then it turns out that to actually get anything out of it requires more data than you can get in one go.

I called it "Overbearing".