A few weeks ago, I attended a code sprint. This code sprint had the goal of enhancing Drupal taxonomy (core and contributed) modules in a way that will make it possible for scientists to import massive quantities of taxonomic information about all of the different species on this planet.
I would like to share this experience of group module development, especially with DrupalChix! So I wrote this article
What happened at the code sprint...
As I mentioned, module developers from all over the world were brought together for the code sprint. The EoL people, and Vince Smith from the British Natural History Museum (he's got ScratchPads, another drupal-project), presented, and gave information about what was technically needed for the EoL. They were building LifeDesks, which are Drupal installations which can be given to taxonomists to help them organize their information about species so that it can be shared with us all in the Encyclopedia of Life. That's 2-10 million species, 100 million common names. A huge amount of information.(read more about the technical aspects of what we did)
Basically, part of the success was that there was already an idea of what was needed technically. They needed to import a lot of data, to manage huge trees of information, to be able to make taxonomy a little more like cck, so that terms could be extended and classified themselves.
Each of the module developers laid out where their own modules needed improvement, and consideration was constantly given to how the development we did would benefit the developers and drupal community as a whole. Some modules were written in drupal 5, but needed to be upgraded to drupal 6. Some modules needed new features, such as a way to save data. A taxonomy importing module needed to be set up to import lots of data, a little bit at a time.
After we understood what was needed, we self-organized into teams. My personal interests were in extending the term information, since I was interested in how, in the future, observations of nature, by individuals, can be made really easy to share, search and visualize. Also, most of my work had been with cck...so making terms more like cck was realistically the best place I would be able to help. (and that worked out. I figured out how to get the extended terms (taxonomy enhancer module) to work with the new drupal theme engine, making it possible to theme, but still not in the 'just make it pretty' realm of work. )
The helping out part is really important to note. My fear of participating in a code sprint had a lot to do with having no idea if I knew enough to be helpful. So you should know that yes, writing modules is challenging, but you do it one step at a time...just like if you are hacking at drupal to try to understand how themeing works, or trying to modify drupal to get it to do what you want. There were some people at the code sprint who were really very skilled and understood a lot about strucuturing their module efficiently. Fortunately, these smart people are very kind, mature, gentle and have spent a lot of time on their computer working - not blabbing their mouths. So it was really awesome to watch some module developers learning from people who've done some gymnastic feats with their drupal code.
This is why I think that it's important to not listen to the fears that keep you from thinking not you're smart enough to participate in a code sprint. It seemed to me like a willingness and motivation to find a place where you could contribute is all you need. I did have to be directed and actively search for a place to contribute...but it wasn't too hard. I knew my limits and how much challenge I could deal with in a certain period of time. So I just found a way to help out.
In normal working life, as a technical/web developer, it seems like most people ask things of you, hoping you will do miracles for them. They may pay you well, or not - they may ask you to single handedly replicate work that took hundreds of people to accomplish (that's why they love drupal now, isn't it?) People get aggravated at you no matter what (because they forget we're people) -- and I would be willing to guess that this wears technical developers down a little bit...and could possibly even make you feel tired and not confident. But maybe that's just me!?
What's so awesome about group module development was having a common goal (a good/cool one)...and working together to achieve this. This kind of collaboration must exist somewhere...probably on bigger software teams, and maybe among people who've always had code buddies. But as a female developer, I can say that I do not usually have code buddies and that it has taken me years and years to build those relationships. It is not easy - even though I totally crave it. Most of the places I have worked have broken up all the developers into projects. We might be put in competition, or 'managed' and even in cases where people would like to collaborate -- the deadlines and amount of knowledge needed make this super difficult to work together. I think a lot of these organizations are limiting themselves.
So what I learned from the code sprint is that I'm not usually challenged. Plenty of people have told me that I complain about all my jobs because I'm never challenged. I tend to disagree with this, because I might be thinking to myself "what do you mean not challenged...these browser bugs are driving me insane!!!") -- but this isn't the same 'challenge' that they were talking about. I think that a lot of technical developers must be horribly un-challenged.
First, we're serving all these whacked-out visions of other people - trying to make a living. So we make weird shopping carts for people, we help all these visions cause that's our job. So, technically, we might be challenged...but that kind of challenge is really different from this other challenge that actually lets who you are as a person, and what you care about and believe in, come out.
Also, a 'challenging work environment' maybe sometimes also means that all the people who work somewhere are insane & overworked (thus, it's 'challenging') - or you're supposed to turn somersaults in order to make lots of money for the project. That's also challenging, but that's not the same challenge that happened at the code sprint.
The challenge from the code sprint came 100% from having an open problem. And this is why I love Drupal so much...Drupal sits there in the land where there aren't existing solutions - problems in society, on the planet, in science, in media and other places -- and lets you go for it -- add something useful. That is a different way to work! This is a place that I think it's important, especially for DrupalChix, to pay attention to. It's awesome to make contributions for something that matters. It's great to be in a place where you have to think, and use all the experiences you have - where you have to listen deeply, quickly, and tons of information comes at you and you are just completely absorbed in a problem. You know that every little movement is creating something new, something we hope for with our hearts. And maybe that's why some of us are drawn to Drupal and drawn to technology - we're artisans hoping to design in ways that heal ourselves and bring us back to a place that lets us be fully human. I think that is what a challenge is.
So I'm not sure that most of us are even half as challenged as we could be. With a tiny bit of coordination and direction, we can actually work together and build tools that people really need. This certainly is not expected of me in my jobs, and instead I'm given a whole lot of busy work which actually distracts me from this other kind of work that's really way cooler and more meaningful.
It's fun to write modules.
Developing modules is really different from themeing. Personally, I didn't like a comment I heard that module writing is the "heavy lifting" -- because a module with no user-interface actually can't go very far all by itself...and all the thought that goes into making usable web interfaces, building up a user's interest in clicking, designing it to be an emotional experience, and then getting that to work in multiple browsers is kinda rough. Writing modules really isn't harder than themeing. It's just different. If PHP and programming starts to make sense to you, then you'll be able to go on the path of being someone who makes inventions that everyone can use.
And there is design in modules -- design of what the module does, design of how the code is going to accomplish those tasks. I have been programming on my own for a few years now, and just to be with other people and trying to figure out how functions are/aren't working is fun. And it's faster to do this with other people and bounce ideas around, and ask questions, than suffering alone on your computer because you're nervous that people will put you down for asking. Well, good news, the guys that I met who write modules were all total sweethearts. I actually get the feeling that a lot of the guys who do drupal development want women to succeed and join them. Doesn't seem like they want to be coding all alone - but coding with everyone (the drupalers, not necessarily employers.) Maybe they are a little wary of inexperience and having to explain what they've learned in 5 years of constantly being on their computer, but for the most part, they just assumed that if you were there then you were probably OK.
So just keep learning PHP and programming, and get out there and working on these sorts of collaborative projects. It's really awesome, and you will probably find that you're good at it. Module development is like engineering...you're making inventions people need (assuming you think about what is means to 'need' technology) -- learning module development will let you write and build tools that your community needs.
- Chach Sikes
Some ideas on how to have a successful code sprint
- invite people who are dedicated to working and collaborating
- keep team small-ish (this sprint was about 15 people)
- emphasize building tools that will benefit everyone (win-win)
- invite people with experience
- provide an interruption-free space and make it possible for people to just focus on only the task at hand
- come with clear technical goals (having researched before hand)
- establish deliverable goals, and have the whole group agree on those goals
- if possible, financially support the sprinters -- the sprint is like a focused short-term job
other things not as planned that made the sprint successful
- everyone invited was pretty quiet and thoughtful
- enough people with long-standing experience with their own modules and taxonomy work were invited that progress could be made (invite knowledge!)
- everyone didn't know each other, so there was not much on-going personality conflict
- everyone was challenged, therefore all ideas on how to proceed were open
(these things definitely helped avoid big egos creating conflicts and disagreements) - everyone acted professionally and responsibly - the goal was real, meaningful, and we took it very seriously
- people involved found ways to help and contribute to the best of their diverse efforts.
(as a result, the drupal community was able to grow in many ways on all levels of experience. 'talent' wasn't sequestered)
Backstory
When I attended DrupalCon, everyone was saying 'oh you should totally go to the code sprint.' First - that sounded frightening. Also, I was already wiped out and needed to visit with my family. So I couldn't go.
Months later, I found out that the Encyclopedia of Life was coordinating a code sprint - and since I love biology so much, this sounded like a totally dreamy opportunity. For work, I work at science museums, and for my job at the Exploratorium, I had done a lot of biology-related projects. Also, I've got a biology-related Drupal project/organization going - and was hoping to coordinate information between my project and other projects. So I had to go!
I started with Drupal a year ago, and had used and set up taxonomies -- but nothing as extensive as what we were about to do during the code sprint. The EoL code sprint was very focused. David Shorthouse had spoken with Acquia beforehand -- and they had invited key taxonomy module developers, from all over the world, to come and build the modules. So you can imagine how I may have had a moment of freak-out. I've made modules, and used taxonomy, but not created taxonomy modules, and so I had a moment of !#$!%@ -- what the 1$#!% have I gotten myself into?? But that's precisely the point of why I am writing this article.
When I went to the DrupalChix meeting at DrupalCon, I hadn't actually met or spoken with so many female technical developers before. Drupal is really good in that DrupalCon is about 10% women (open source is like 2%!!! crazy!!) So, there were 30 of us in the room, and that was half the women at the conference. So, for me, this was a pretty awesome experience...just to meet more female developers and learn that the experiences we have vary from some of the crap you might assume...but actually not as much. Sounded to me like we only grow professionally by jumping jobs (cause we get put in these dumb little boxes and no one can expect that we do more, til we get a new job and do just fine at it) -- and also that we have too much work and have to deal with that.
What I also learned from the other women Drupal developers is that it seems like a lot of us hide our talents. Someone even said that they keep noticing that there are a lot of us who are "secret drupal ninjas." I don't know what I think about that yet. I kinda feel like maybe I have really high expectations about what I'll be able to do with Drupal in the future...and that keeping quiet about what I know, and just constantly learning and improving is what needs to happen.
So I want to spell out what happened at the code sprint, and what it was like to do module development (not theme development) because it's really fun and almost cooler than theme development. I think that more drupalchix can set their aspirations to actually writing modules...cause the coding really isn't that much different from hacking at drupal and web browsers...it's similar skills.