Rethinking Coders

Some problems

• Projects move very slowly -- way more slowly than expected.
• People who are the impetus for starting a project often move on before it's completed.
• Volunteer coders often implement changes without much coordination, leading to incompatible code.
• Entire projects are abandoned (or at least forgotten)
• New coders are often overwhelmed by the learning curve

Some analysis

What motivates volunteer coders?

• Some people want to learn useful skills
• Some want hands on experience
• Some want to teach others what they know
• Some just want to help out

Comparison with the Build Program

I often compare the Coders program with the Build program as a start to figuring out what might work better for coding at Free Geek.

In the build program, volunteers:

• can sign up for any of nine shifts per week
• need to work at Free Geek
• trade time building and QCing in exchange for something (often a computer, often skills)
• go through a Prebuild program where they are exposed to skills they'll need later on
• in prebuild, folks sometimes realize they're in over their head and drop out
• once you teach someone how to build a computer, they (basically) need to repeat that task several times

In contrast the volunteer coders:

• can come in once per week, but can work on their own time
• can work from home or elsewhere if they choose (though some things need to be done at Free Geek)
• trade time writing code in exchange for skills
• don't go through any prerequisites program
• sometimes realize they're in over their head and drop out while coding
• once you teach someone how to write a program, they cannot repeat that task several times in any kind of a useful way

The build program is quite successful at involving a lot of volunteers at Free Geek, while the coders successer are much more modest (and that may be putting it charitably).

Some conclusions

The biggest overarching problem is that projects move so slowly that coders drop out and work doesn't get done.

An advanced coders group that plans out projects, and identifies the specific tasks to be done would give us a foundation for identifying the next task appropriate to a given volunteer that should be done. This would make us more organized to the incoming coders. (See #Extreme Programming at a Glacial Pace )

A series of repeatable workshops in basics could happen, comparable to the command line for builders class, for new coders. These could cover:

• text editing
• ssh / scp
• cvs
• unit testing
• hello world in:
  • python
  • php
  • shell
• hello world from the database in:
  • python
  • php

Extreme Programming at a Glacial Pace

From Wikipedia comes this list of characteristics for extreme programming:

• Incremental and iterative developments - small improvements after small ones
• Continuous, often repeated automated unit test, regression testing.
• Pair programming
• User interaction in the programming team (Onsite Customer)
• Refactoring
• Shared code ownership
• Simplicity
• Feedback
• Organising the system with a metaphor
• Sustainable pace

Clearly we're not achieving a sustainable pace, and several other points could use some work. But this model fits Free Geek closer than most. We need to adapt it to our needs and prepare an infrastructure to make it work. Specifically, we need to have small enough tasks that are clear enough for us to hand them out to coders such that they can complete them and see that as an accomplishment.