Day Camp 4 Developers: Telecommuting

About two weeks ago I took part in the second online Day Camp 4 Developers, on the topic of telecommuting. The idea behind the Day Camp events is to provide software developers with practical knowledge and advice in the area of "soft" skills, to complement their expertise with "hard" skills (i.e. actual coding). In this case five speakers gave consistently excellent web presentations (slides and audio) with different perspectives on remote working, while an IRC chatroom gave all participants a forum to discuss the issues behind the scenes.

Lorna Jane Mitchell started off by asking "Could You Telecommute?". As a teleworker herself, Lorna Jane looked at the environmental, organisational and personal factors that influence the happiness and productivity of the remote worker: for example, ensuring you have a good home working space, and set clear boundaries between work and personal life (both for yourself and for others). In particular you have to be aware of the tendency for other people to think that working from home is easy, and that your time is infinitely flexible. She also noted that there are some big differences between being part of a distributed team and being a telecommuting member of a co-located team (where you risk feeling isolated), and further differences between employees and freelancers. Particularly for lone telecommuters, it's important to build professional and social support networks that might otherwise be taken for granted in more conventional work settings.

Next self-described "entreprenerd" Ivo Jansch talked about "The Business Case For Telecommuting". Ivo's company Egeniq is built around a distributed team (essentially using remote working as an organisational model) - so in addition to benefiting individual workers, he suggested ways that telecommuting could positively impact the company's bottom line, for example enabling access to an bigger talent pool and increasing its geographical reach (if providing consultancy services). He acknowledged that this distributed model won't suit every company or industry however, and success requires (amongst other things) a results-driven culture where individuals are trusted to self-manage and have a sense of shared responsibility. Ultimately good communication between team members is paramount.

After the lunch break, Jack G. Ford gave a manager's perspective on setting up a telecommuting programme in his presentation "Can I Work From Home Tomorrow?". Jack introduced himself as an ex-coder who is now the manager for 17 developers in a more conventional environment than Ivo's, but in spite of that his key points seemed remarkably similar: beyond asking whether the company infrastructure can support remote working, the main issues are trust (both with the manager and with the team) and good communication between the manager and the individual. Jack emphasised that as a manager, when you telecommute, "I can't see you," so the telecommuter must stay connected, keep the manager informed, and must not only act professionally but be seen to do so. Although it might seem obvious, this was a fascinating insight into telecommuting from the other side of the management chain.

Ligaya Turmelle's presentation on "Managing the Work/Life Balance" emphasised the challenges of balancing work and home life, with her lists of "the good, the bad and the ugly" of remote working from a teleworker perspective. Ligaya focused especially on balancing family commitments with work commitments, and among some interesting observations (for example, no longer doing the daily commute means you lose some "me time" to yourself), I was most struck by the admission that if you love your work then it can mean sometimes that you want to go on working, and are in danger of not respecting your own ground rules. While noting that situations can differ both for individuals and companies, her advice was: clarify everyone's expectations (e.g. policies for "on-call" hours, weekends, and holidays); set up ground rules and limits (and be disciplined in adhering to them); and try to be flexible and imaginative in how you approach your work.

The final presentation was Avdi Grimm talking about "The Well-Equipped Remote Worker". Avdi is a freelance software developer who is also a "dispersed teams facilitator" and runs the Wide Teams blog. As might be expected from the title, some of the focus was on the hardware and software tools that can help with remote working, but there was just as much information on practices that can support distributed teams. Once again promoting communication is key, and using tools and practices that help team members create good working relationships (for example, utilising social media like Twitter and Facebook, and holding regular face-to-face meetings) can really contribute to this.

Looking back over all the talks, a few common themes had emerged for me:

• Good communication (both with managers and with other team members) to build trust, keep people informed and avoid misunderstandings;
• Clarify expectations on all sides, and establishing well-defined boundaries between work and personal life. Set ground rules to ensure that those boundaries are respected by others (your boss, your family and friends) and have the discipline to also respect them yourself;
• Build and maintain your social and professional support networks for when there are problem times;
• Provide yourself with a good working environment and (software and hardware) tools.
  

I was also able to relate some points to my own experiences: when I worked briefly as a remote member of a co-located team, I did feel a real sense of isolation; another time as a home teleworker I got the impression from some people that they assumed (not maliciously) that I only did a few hours work a day; and previous experience as part of a large organisation makes me feel that there was some truth in Ivo's comment that "co-location is over-rated", in that it doesn't automatically lead to great communication between individuals or groups.

Overall it was an excellent event and a good use of 8 hours of my Saturday - although the time difference (coincidentally another telecommuting issue) meant that it didn't finish until 10pm UK time I surprised myself by staying with it to the end. Hats off to Cal and Kathy Evans for organising the day and to the speakers for their excellent presentations. Here's waiting for the next Day Camp 4 Developers!

MadLab: pancake café and the Omniversity of Manchester

Yesterday I dropped into the Manchester Digital Laboratory (aka MadLab) in Edge Street for the MadLab Café Pancake Day, and enjoyed a couple of hours chatting to various friendly people while eating an extremely tasty pancake and drinking cups of tea (one of my favourite pastimes), and at one point even discussing Outkast's back catalogue.

MadLab describes itself as "a community space for people who want to do and make interesting stuff - a place for geeks, artists, designers, illustrators, hackers, tinkerers, innovators and idle dreamers; an autonomous R&D laboratory and a release valve for Manchester's creative communities." I'm not sure precisely where I'd put myself in that list - I've only been there a couple of times before, for the Python Northwest user group meetings - but the folks I met seemed to be a representative cross section of the target community.

There's a packed and eclectic schedule of (mostly free) events hosted there, which is well-worth checking out (see http://madlab.org.uk/events/), but their most recent new development is the Omniversity of Manchester - a programme of professional-level training courses that so far have covered experimental film making and physical computing with Arduino, with plans to extend to topics as diverse as web design, Ruby on Rails, writing workshops and urban gardening. These courses won't be free, but the fees will go towards keeping MadLab sustainable and supporting the other free events.

If you're interested in learning more then you can watch out a video, and register the subjects you'd like to see covered by taking a moment to fill in their survey:

• The Omniversity Crowd Sourced Cirriculum Survey

Personally I think it's a really exciting idea - I'm generally a fan of courses, and many of the proposed workshops are things that I'd love to learn more about, so it would also be great to see the Omniversity take off and help MadLab expand and flourish as a focal point for Manchester's digital community - the more people who find out about it and get involved the better. And in the meantime I'll be looking forward to the next (undoubtedly tasty) MadLab café event.

Book review: "Simply SQL" by Rudy Limeback

Rudy Limeback's "Simply SQL" (Sitepoint) is an overview of SQL targeted at web application developers, and intended to fill a gap between the basic "SQL 101"-type tutorials (seemingly compulsory in just about every introductory article or book about web programming) and more advanced texts covering topics which at first glance don't seem so relevant to the straightforward day-to-day requirements of many web applications.

The chapters are grouped into two main sections. The first deals with the details of the SQL language and comprises the bulk of the book. It starts with a short introduction to the SQL commands most commonly needed by web developers to create and modify data within the database (all the usual suspects - CREATE, ALTER, INSERT, UPDATE, DELETE and so on - are quickly dealt with here). The rest of this section focuses on the SELECT command (the one used to retrieve information), with each chapter covering one specific clause - FROM, WHERE, GROUP BY and so on - in quite extensive detail, and illustrated with examples from sample applications.

The second section of the book has three chapters covering some basic database design concepts, specifically SQL data types, relational integrity, and the use of "special structures" (such as tables that refer to themselves) for particular situations. The appendices then outline the basics of using some specific SQL implementations, along with details of the sample applications and scripts used in the main part of the book.

The heavy emphasis on the SELECT statement might seem odd, but it makes a lot of sense in the context of web applications where data is typically read from the database far more than it's written. The detailed examples are also excellent - at times invaluable - for clarifying things like (for example) the nuances of the different types of JOINS, the subtleties of the GROUP BY and HAVING clauses (useful for aggregating data from subsets of rows in conjunction with summing and averaging functions), and the issues with working with time data. I certainly learnt a few things - the GROUP BY clause was completely new to me, as were the distinctions between the FLOAT and DECIMAL data types (DECIMALs are exact - within certain limits - while FLOATs are approximate). I found the brief sections on views, derived tables and subqueries extremely enlightening, as was the discussion of foreign keys in the chapter on relational integrity, and the clear writing style throughout made the book a pleasure to read.

It's important to note that "Simply SQL" is based on the SQL standard, rather than the syntax of specific implementations (although in places it does indicate where there are notable deviations from the standard, particularly for MySQL) - also it doesn't cover any of the programming APIs, so it's not really a reference text (admittedly it doesn't claim to be). However with its clear and detailed explanations it looks like it would be a useful companion to more traditional reference or cookbooks and will definitely reward re-reading - least ways, I'm sure I'll be squeezing plenty more juice out of it in the future. So overall highly recommended.

Don Knuth: BCS/IET Turing Lecture

Earlier this week was the annual Manchester BCS/IET Turing Lecture, and this year's guest speaker was Don Knuth. Possibly he's best known (at least to me) as the author of the seminal "The Art of Computer Programming" (a multi-volume book which he began in 1962, and continues to work on to this day - subvolume 4A is the most recently published, with another 5 sections still to come), and the typesetting system TeX (pronounced "tek", and used for typesetting countless Ph.D theses - including mine). However Knuth's contributions to computer science throughout his long career (he's now in his seventies) are staggering - as are his "extra-curricular" activities, which include writing novels and playing the pipe organ.

So it was quite an opportunity to be able to listen to this giant of computing first hand - even more so since rather than a straightforward lecture, this was actually a Q&A, with Knuth taking questions from the audience. After opening with a concise explanation of the significance of the number 885205232 (which I won't spoil by revealing here, since it's a puzzle in his book "Selected Papers on Fun & Games", other than noting that it involves Alan Turing's manual for programming the Ferranti Mk. I computer), Knuth fielded questions on various topics including: elegance in programming languages, the public's fear of computers, "busy beaver" numbers, the best way to teach programming to elementary schoolchildren, and whether an aptitude for programming is an art or a "genetic defect".

Throughout his answers were thoughtful, often surprising (for example, making a case for pointers in C as an elegant language feature), consistently interesting, and delivered with characteristic humour (Knuth was once published in MAD magazine, and is famous for the quote "Beware of bugs in the above code; I have only proven it correct, not tried it", amongst others). In response to a question about "what are we 'enabling the information society' to do" (a reference to the BCS's current mission statement), Knuth initially replied "to have jobs", before more seriously reflecting that "there's a long way to go improving what we already have at the moment."

Although Knuth's world of computing feels like it's a long way from the one I inhabit, it was a great privilege to see and hear such a legendary figure - in spite of his age he seems as lively as ever, both physically and intellectually, and still enjoying it - and his career is truly inspiring: when asked what he'd do differently if he had his time again, his reply was that he wouldn't change anything. "In my case," he said, "Murphy's Law hasn't worked - so many things that could have gone wrong didn't."

The What, Where and How of Open Data

Last week I attended a seminar at the Cathie Marsh Centre for Census and Survey Research, given by Rufus Pollock of the Open Knowledge Foundation (OKFN) on the topic of "open data".

Rufus started by showing two example applications built using open data. Yourtopia makes use of data from the World Bank that measures individual nations progress towards the Millennium Development Goals. Visitors to the site balance the relative importance of different factors (for example, "health", "economy" and "education"), and their preferences are matched with the data in order to suggest which country meets them most closely. Where Does My Money Go? offers various breakdowns of UK government spending and presents these in a way that allows the site visitor to see (for example) how much of the tax they pay is used for things such as defence, environment, culture and so on.

Both sites are eye-catching and fun (and can provide some surprising insights), while at the same time serving more serious purposes. In the context of the seminar Rufus noted that building the two sites also highlighted some key issues when working with these kinds of datasets:

• Completeness: i.e. the data are not always complete
• Correctness: i.e. the data are not always correct
• Ease-of-use: it can take a lot of effort to put the data into a format where it can actually be used (for example an estimated 90% of the time developing Where Does My Money Go?, as opposed to 10% actually building the site)
  

These issues can largely be mitigated by "open data", which has two key characteristics:

• Legal openness: the data must be provided with a licence that allows anyone to use, reuse and redistribute the data, for any purpose. ("Reuse" in this context can include combining it with other datasets and redistributing that.) An explicit open licence is required (such as those offered at Open Data Commons) because the default legal position for any data - even that posted "openly" on the web - doesn't entitle someone else to reuse or redistribute.
• Technical openness: the data should be in a format that means that it's easy to access and work with, that it should be possible to obtain the data in bulk, and in a machine-readable, open format. These are pre-requisites for the data to be useful in a practical sense: for example, it's not sufficient to provide the data via a website that only returns subsets of that data via a form submission.

(See the official definition at http://www.opendefinition.org/.)

The data itself can be about almost anything: geographical (for example, mapping postcodes to a latitude and longitude), statistical, electoral, legal, financial - the OKFN's CKAN (Comprehensive Knowledge Archive Network) site has many examples. The key point is that the data should not be personal - that is, it shouldn't enable individuals to be identified, either directly or indirectly.

The motivation for making data open goes back to the initial issues of completeness, correctness and ease-of-use - it can take a lot of time to assemble a dataset (for example, the Government already collects a lot data), but once the effort has been made then the added cost of releasing it is small, and then sharing it reduces the cost of merging, filling gaps and correcting errors. To make an analogy with open source software, it's a essentially Linus' Law for data: "given enough eyeballs, all bugs are shallow". Rufus also talked about a corollary to this, the "many minds" principle: the best use of the data you produce will probably be thought of by someone else (and vice versa).

One argument against openness is that it precludes the possibility of commercial exploitation in order to offset the costs of compiling the data, and is a topical point given the current economic climate. Rufus's counter-argument is that there are many other ways to fund the creation of data aside from making it proprietary, by considering the data as a platform (rather than as a product), and building on that platform to sell extensions or complementary services (such as consultancy - again there are parallels with open source software). (Some of the audience expressed also concerns that in principle at least, open data is might be used irresponsibly - but arguably if the data is available to all then it means that others could challenge that interpretation.)

The final point that Rufus's talk addressed is how to actually build the open data ecosystem. To some degree it's up to the people who hold the data, but his suggestions are:

• Start small and simple (which I took to mean, start with small sets of data rather than doing everything all at once).
  
• If you're using someone else's dataset then you can make an enquiry via the OKFN website to find out what the licensing situation is.
  
• If you have your datasets then put them under an open data licence and can register it at CKAN so that others can find it.
  
• "Componentize" your data to make it easier to reuse (which I took to mean, divide the datasets up into sensible subsets).
  
• Make the case with whoever holds the data you want (government, business etc) to release it openly.

For me as a "lay person", this was a fascinating introduction to the world of open data. Not unreasonably the seminar didn't go into details of actually working with such data (I think many of the seminar audience members were researchers already familiar with the available tools). However afterwards Rufus made the point that writing a paragraph of text after looking at the data is just as valid as the slick visualisations provided by Where Does My Money Go? and other sites. Ultimately it's having open access to the data in the first place that counts.

Python North-West: The Python Challenge

Last week I went to my first-ever Python North-West meeting, at the Manchester Digital Laboratory (aka MadLab). The webpage describes it as a "user group for Pythoneers and Pythonistas of all levels and ages, open to everyone coding 'the way Guido indented it'", and meetings alternate between talks and coding dojos (group coding sessions where people get to share code and ideas with the aim of improving their knowledge and skills - see http://codingdojo.org/cgi-bin/wiki.pl?CodingDojo for more information).

This particular meeting was a coding dojo and so as a group we worked through The Python Challenge (http://www.pythonchallenge.com/), which is a series of puzzles that can be solved using Python programming combined with some imagination and lateral thinking. While most people had come with their own laptops, the format that developed was for one person to "drive" the laptop connected to the overhead projector, typing in code and taking suggestions from the others.

Although I'd already looked at the first two challenges earlier in the day to get an idea of what was involved, the group setting provided a great opportunity to see how other people worked, and to learn about bits of Python that I was unfamiliar with - one example for me was being introduced to list comprehensions, which are concise ways to generate lists, e.g.:

>>> [[x,x**2] for x in vec]
[[2, 4], [4, 16], [6, 36]]

(although there were several other examples which I won't write about here so as not to spoil the challenges for others). Also, as many of the challenges began with having to figure out what the programming problem actually was, it meant that collectively we didn't get stuck for too long on any particular puzzle - I know that at least a couple would have had me completely stumped if I'd been on my own. For me personally it was also an opportunity to play with IDLE - Python's IDE - under Windows (not an environment that I've used much in the past but quite handy for this kind of exploratory programming process.)

Overall it was great to get out and interact with other Python developers in an enthusiastic and friendly atmosphere, while at the same time broadening my knowledge of the language - and now I've had a taste I'll definitely be back for future meetings.

City Tickets

Recently someone on the MySociety mailing list posted a link to Mayo Nissen's blog entry about an interesting project called City Tickets.

While it's not immediately obvious from the post (especially given the very convincing pictures), City Tickets is Mayo's final thesis project at the Copenhagen Institute of Interaction Design, rather than an actual existing system. In it he proposes augmenting existing parking ticket machines so they can also dispense so-called "city tickets": small receipt-like forms specific to the local area around the machine, to be filled in with details of repairs or suggested improvements (e.g. potholes in the road, or providing a bench to sit on). Completed tickets would be submitted to the local authority for action, and tickets would also show the "to-do list" of pending works.

The principle of City Tickets is very similar to MySociety's existing FixMyStreet website. FixMyStreet provides a simple but efficient way for people to report problems such as graffiti, fly-tipping, broken pavements and so on to their local council: problems can be pinpointed on a street-level map (making them easier for council representatives to locate), the details are forwarded to the local by the website on your behalf (removing a significant barrier to reporting problems), and lists of unresolved problems can be viewed and discussed (making it easier to follow up).

FixMyStreet is a great idea (as are all the MySociety projects) and does get results. The interesting twist with City Tickets is the possibility of extending this beyond the web, removing another potential barrier to participation (the reverse of a trend to move access to government services and information online, arguably depriving a significant proportion of the UK population without internet access). More generally, the idea of co-opting an existing technology infrastructure for social good feels like it should have potential. While using parking meters might not work everywhere, what about ATMs or payphones, for example? Or perhaps it could be a very worthwhile target application of ubiquitous computing technologies?

It seems unlikely that we'll see anything like City Tickets in real life any time soon, which is perhaps a shame. But one of the great things about projects like this is that they can suggest exciting possibilities we might not otherwise have imagined. And in the meantime, keep supporting FixMyStreet!