It’s just a week ’til the first Ladies Learning Code workshop in Toronto, and the list of instructors is pretty impressive. Thanks in advance to:
- Pearl Chen
- Crystal Preston-Watson
- Mike Conley
- Gavin Lobo
- Jay Goldman
- Phyliss Lee
- Christina Truong
- Laurie MacDougall Sookraj
- Svetiana Kolupaeva
- Monika Piotrowicz
- Melissa Luu
- Emir Hasanbegovic
- John Lim
and of course to Heather Payne, Amrita Mathur, and everyone else who pulled it together. W00t!
On the same day (August 6), a much smaller group will be having a learn-in at Mozilla’s Toronto offices, where Zuzel Vera will get us up to speed with Lernanta development. If you’re interested in Python web programming, Django, and online education, there’s still space to join us, and you can sign up online.
Seven years ago, Michelle Levesque and I wrote in “Open Source, Cold Shoulder“:
Proponents of free, libre and open source software (FLOSS) often describe their campaign as a struggle for civil rights. They portray FLOSS as a great equalizer: Not only is it freely available to everyone, but anyone who wants to help shape it can do so, regardless of race, nationality, faith, politics or sexual preference.
But for a movement that claims to be open to all, very few women are involved. Take a look at the roster of speakers at O’Reilly’s annual Open Source Conference, or at the names of core developers on any of the thousands of successful FLOSS projects. While the gender ratio in the industry as a whole is roughly five to one, the ratio in FLOSS appears to be several hundred to one.
Our aim is not to complain yet again about gender imbalance in computing. Instead, we believe that the gender skew in FLOSS is the most visible symptom of a fundamental unfriendliness in that community. We also believe that if this unfriendliness is not addressed, it will limit FLOSS’s growth and success more than misconceived lawsuits or FUD from would-be monopolists.
Things have improved a little since then: by my count, 32 of the 327 people listed as speakers at this year’s OSCON are women (i.e., just a hair under 10%), and female participation in open source seems to have risen to roughly 2% (which is still 7-8 times worse than the gender ratio in computing as a whole). The biggest change, though, is the number of people who acknowledge that this is a problem, and are trying to do something about it, despite the sneers or embarrassed silence of their peers. I’d therefore like to salute my personal OSCON’11 hall of famers—those speakers who have made a point of stepping up where O’Reilly has once again chosen not to:
- Donna Benjamin
- Selena Deckelmann
- Audrey Eschright
- Matthew Garrett
- Gareth Greenaway
- Peter Krenesky
- Clinton R. Nixon
- Jacinta Richardson
- James Turnbull
So what about it, Tim: will we be able to add your name to this list next year?
Later: O’Reilly has announced an Anti-Harassment Code of Conduct. Yay, and thank you to everyone who helped make it happen.
We all do it. We start fixing something over here, in this file, then notice something unrelated ten lines above in a different method that should be cleaned up as well, so we make that little change, but then we have to change the three calls to that method, and while changing one of them we see an opportunity to combine two methods, and so when it’s time to check in, our commit message is a bullet-point list of unrelated changes. Yes, the right thing to do is to make notes for ourselves about those other changes, then defer work on them until we’ve finished the first change, but few of us are that disciplined 100% of the time.
But wait: why can’t our version control system help us here? When I commit, why do I have to commit all or none of a file? Wouldn’t it be cool if I could say, “I want to commit these lines of this file, and those lines of that other file, but not inflict my other changes on my teammates just yet?” Well, there’s at least one good reason why it would be a bad idea: we almost certainly won’t have tested the exact combination of lines that we’re checking in.
But what if we could pull the changes we don’t want to commit out and save them, then re-run our tests, commit (assuming the tests pass), and then put the pulled-out changes back in place? It doesn’t seem like a particularly hard thing to build, though the user interface would have to be thought through carefully. I suspect it would make the check-in history of many projects cleaner…
Following up on Wednesday’s post, it looks like Saturday, August 6, is a better day for a Lernanta code-in than July 23. Four people have said they’re interested in learning about GitHub, Django, jQuery, and Lernanta itself—if you’re in Toronto, and would like to join us, please give me a shout or sign up at Meetup.com.
When Buddhists want to remind themselves that scripture is a guide, not a goal, they say, “The finger pointing at the moon is not the moon.” I think we need a similar metaphor to explain what testing is really about to junior developers. When I say, “Don’t check in code until all the tests pass,” I do not mean:
- comment out test cases that are failing, then check in, or
- take failing assertions out of your methods, then check in, or
- throw away features whose tests are failing, then check in.
The purpose of testing is not to get all tests to pass. The purpose of testing is to tell you what state your software is in, and your goal should always be to gather as much useful information as you can (as economically as you can, but that’s a topic for another post). If you don’t have any automated tests, then all you really know about the software comes from the interactive testing you’ve done since you last made a change. No other knowledge is reliable, not even the things you tried out 30 seconds before you made those changes.
If you do have automated tests, and some of them are failing, but you know why, that’s OK (temporarily). Right now, for example, I know we’re not creating a link object to connect A and B, because we decided we would do that implicitly rather than explicitly in this one special case, and I haven’t implemented that code yet, so test #1234 is failing as expected, and that shouldn’t stop me from checking in the code that makes test #5678 pass. I shouldn’t let very many failing tests pile up, but leaving them in the failing state to remind me (and the rest of the team) that some things aren’t working yet is a lot better than taking them out just to get a green light. The latter reduces how much I know about my program; the former may not be good for morale (“Jeez, we still have that to do, don’t we?”), but it’s more honest, and more useful.
Lernanta is the web application that powers p2pu.org, the peer-to-peer university project backed by Mozilla. On Saturday, July 23, Zuzel Vera Pacheco (its lead developer) and I will be running a one-day code-in for people who’d like to get up to speed with it, and with all the nifty things it’s built on top of: Django, jQuery, GitHub, and more. (Note: I sort of know a bit about Django, but I’m a jQuery and GitHub newbie, so I’ll be asking questions, not answering them…) The venue is still to be determined, but will be somewhere in downtown Toronto. Attendance is free, but some prior experience with Python web programming is a must. If you’re interested, please email me.
Debuggers make programming much less painful and much more productive, but a lot of students never pick up the habit of using one. Personally, I think this is because teachers have never figured out how to put questions about using debuggers on mid-terms: most computer science programs don’t have an equivalent of the “lab exams” that are common in chemistry and biology, and if students are never examined on their ability to do things the right way, they never have to climb the learning curve. But that’s just a guess, and tangential to the main point of this post.