Oversight and Programmer productivity
Over the last three years, we've run a project called the Summer of Code, in which we pair up university level software developers with open source software projects. If the student succeeds in fulfilling the goals set forth in their application (which the project has accepted) then they are paid a sum of $4500. We wanted a program that would keep software developers coding over the summer and it would also help out our friends in the world of open source software development.
The passing rate last year was 81%, which means some 700+ students completed their projects to the satisfaction of their mentors.
This last year, we did a cursory study of the code produced by these students and reviewed, among other items, how many lines of code the student produced. The lines of code thing has been done to death in the computer industry, and it's a terrible measure of programmer productivity. It is one of the few metrics we do have and since we make the assumption that if they pass the project then their code has passed muster. So after that the lines of code becomes somewhat more significant than it would normally.
Over the summer of the average student produced 4,000 lines of code with some students producing as much at 10, 14 and even 20 thousand lines. This is an insane amount of code written weather you measure by time or by money. By some measures this means the students are anywhere between 5 and 40 times as productive as your 'average' employed programmer. This code, mind you, was written by a student who is almost always geographically separated from their mentor by at least 3 time zones and almost never has a face to face meeting with their mentor.
This is an absurd amount of productivity for a student or, heck, anyone, writing code. This is often production and user-ready code being produced by these students. It's really something to see and made me revise what I consider a productive developer to be and what indeed I should expect from the engineers that work for and with me.
But, and here's the thing I changed my mind about, is the tradeoff for silly high productivity that I have to run my projects the way we run the Summer of Code? Maybe. Can I keep my hands off and let things run their course? Is the team strong enough to act as this kind of mentoring to each other? I now think the answer is that yes, they can run each other better than I can run them. So let's see what letting go looks like. Ask me next year? Let's hope next years question is 'what chance are you least regretful you took?' and I can talk about this then!
