After some bumps in the road, we got Google Code-in launched last week. It was a long time coming, let me tell you. We started pushing around the idea of doing the contest in March or April of this year and I've been working in some capacity on getting it up and running since June.
I put a lot of work into Google Code-in and I'm happy for that. I even got sick at the Grace Hopper conference earlier this year after spending all my time and energy trying to announce the program. It just seemed like it was one thing after another fighting against me. But after it all, I am so glad I did.
This contest, to me, is maybe more important than Google Summer of Code™ (insert standard disclaimer about these are not the words of my employer here). I think young developers - the kids we are specifically targeting with this contest - are the future. We need to get them interested and involved in open source software, in technology, and in working and thinking with a global community now. We need to give these kids their first "ah hah" moments while they're still wondering what they want from life, the universe and everything.
My "ah hah" moment came when I was 16. I had been futzing around on my web browser at home and realized I could view the source of the webpage. Not only that, but I could replicate said webpage and modify it to be my own. I could create a presence on the internet just like that. And so I did. I spent hours writing, modifying, editing, and publishing HTML webpages. I became a Geocities community leader and spent some time in web rings. I found an entire online community and an entire world I hadn't known existed. That experience was the first step in a train of events that put me in the job I have today.
I'm hoping there's a Google Code-in student out there somewhere right now having a similar experience. Maybe we'll hear from him or her in 10 years when he or she is creating the world's next Google or the world's next Linux.
Monday, November 29, 2010
Sunday, June 6, 2010
Important qualities and best practices for project managers
Please keep in mind this is not a comprehensive list and I am by no means an authority on the matter. However, these are some things I've discovered over the years that get me good/better results with engineers than not trying to incorporate them. Maybe they will help you too.
1. Assume you have 2 hours per week in which to schedule meetings with any given engineer. Any more than that and you've lost her productivity, her time, and probably a little bit of her respect for you. If she thinks you can't get the information you need from her in 2 hours every week she will probably start to also think of you as ineffective. Honestly, if its taking you 5 hours per week to get information on a project from a person, maybe you are ineffective. Or at least not empowered to do your job correctly.
2. Most people don't go to work in the morning with the intention of doing a bad job. Assume competence on an engineer's behalf unless you get explicit actions to the contrary. He is probably working on that thing you asked him for as fast as he can, even if he's not checking in with you as much as would make you happy. He's also probably trying to do a quality job on it and take pride in his work instead of just being a code monkey churning out shoddy tools on a regular basis. Don't pester him about it. Trust him to work hard on something and give him space.
3. Don't keep checklists. I mean checklists in a literal and also slightly metaphorical context here. Don't just assume you can write down everything an engineer is doing for you and then send constant pings on a daily, weekly, or monthly basis to get it done faster and checked off your list. This also extends to things you don't have context on - if you don't know what's required or involved in any particular task, you should assume you don't have the space to keep asking the engineer about it. I'm not saying you need to have the same technical savvy as her, but you do need to be able to have an informed discussion about it when she comes back to you saying, "I couldn't get this done today because of X reason and I need some ideas on how to change it."
4.Protect the engineers from your management. I'm sure most of you have read the article on the maker's schedule vs. the manager's schedule (if you haven't, its a great article). I'd like to take it one step further and say that as a project's manager it is your job to protect the engineers on your project from managers constantly pushing for deadlines, making everything important, and generally meddling. You talk to management and let the engineer do his job. Everyone will be happier for it.
5.Only use the emergency button when it really, really is an emergency. The less you tell an engineer that it's absolutely crucial this feature ships today the more you'll build respect. It will be slow-earned, but once she understands that when you say you need something today you really mean it (and you're not going to say the exact same thing tomorrow about some other feature) she will be a lot more likely to work through lunch time for you to get it done.
6. Build respect and karma with the engineers. Everyone has their own way of doing it - I bake cookies. Maybe you bring him chocolate he likes or send him emails thanking him for the work he's doing on your project. Whatever it is, do it regularly and do it without expecting any return. He will be thankful and much more likely to give you the extra little things it is in his power to give when the time comes for you to need it.
7.Add two weeks to any date you get from a engineer. This is not because I don't trust engineers. In fact, its because I trust engineers too much to try to give me the right answer instead of the realistic answer. Two weeks, of course, can be modified for your purposes - if it's a task she's saying will take a day, maybe you add two days to that number. I think it is human nature to want to say that you can do something well in a short amount of time. No one ever wants to hear from a peer, "What? It's going to take you that long?" People want to hear, "Wow! You delivered that so fast!" Underpromise to your management and then overdeliver when it comes in a week early.
I may amend this entry at some point, but that's the list for now. Your comments and experiences welcome.
1. Assume you have 2 hours per week in which to schedule meetings with any given engineer. Any more than that and you've lost her productivity, her time, and probably a little bit of her respect for you. If she thinks you can't get the information you need from her in 2 hours every week she will probably start to also think of you as ineffective. Honestly, if its taking you 5 hours per week to get information on a project from a person, maybe you are ineffective. Or at least not empowered to do your job correctly.
2. Most people don't go to work in the morning with the intention of doing a bad job. Assume competence on an engineer's behalf unless you get explicit actions to the contrary. He is probably working on that thing you asked him for as fast as he can, even if he's not checking in with you as much as would make you happy. He's also probably trying to do a quality job on it and take pride in his work instead of just being a code monkey churning out shoddy tools on a regular basis. Don't pester him about it. Trust him to work hard on something and give him space.
3. Don't keep checklists. I mean checklists in a literal and also slightly metaphorical context here. Don't just assume you can write down everything an engineer is doing for you and then send constant pings on a daily, weekly, or monthly basis to get it done faster and checked off your list. This also extends to things you don't have context on - if you don't know what's required or involved in any particular task, you should assume you don't have the space to keep asking the engineer about it. I'm not saying you need to have the same technical savvy as her, but you do need to be able to have an informed discussion about it when she comes back to you saying, "I couldn't get this done today because of X reason and I need some ideas on how to change it."
4.Protect the engineers from your management. I'm sure most of you have read the article on the maker's schedule vs. the manager's schedule (if you haven't, its a great article). I'd like to take it one step further and say that as a project's manager it is your job to protect the engineers on your project from managers constantly pushing for deadlines, making everything important, and generally meddling. You talk to management and let the engineer do his job. Everyone will be happier for it.
5.Only use the emergency button when it really, really is an emergency. The less you tell an engineer that it's absolutely crucial this feature ships today the more you'll build respect. It will be slow-earned, but once she understands that when you say you need something today you really mean it (and you're not going to say the exact same thing tomorrow about some other feature) she will be a lot more likely to work through lunch time for you to get it done.
6. Build respect and karma with the engineers. Everyone has their own way of doing it - I bake cookies. Maybe you bring him chocolate he likes or send him emails thanking him for the work he's doing on your project. Whatever it is, do it regularly and do it without expecting any return. He will be thankful and much more likely to give you the extra little things it is in his power to give when the time comes for you to need it.
7.Add two weeks to any date you get from a engineer. This is not because I don't trust engineers. In fact, its because I trust engineers too much to try to give me the right answer instead of the realistic answer. Two weeks, of course, can be modified for your purposes - if it's a task she's saying will take a day, maybe you add two days to that number. I think it is human nature to want to say that you can do something well in a short amount of time. No one ever wants to hear from a peer, "What? It's going to take you that long?" People want to hear, "Wow! You delivered that so fast!" Underpromise to your management and then overdeliver when it comes in a week early.
I may amend this entry at some point, but that's the list for now. Your comments and experiences welcome.
Wednesday, May 12, 2010
A minor divergence
To bring you this amazing news:
The awesome people at Wolfire Games decided to do something a little different: offer 5 quality games for download and ask people to pay whatever they thought was appropriate for the bundle. They've made over $1 million on the venture so far! I've seen recording artists do this before, but I'm not aware of a game company that's done something like this before. Do any of you know of such a phenomenon in the game industry before this?
In even better news, they have also donated a portion of the money they've made to the Electronic Frontier Foundation, and in even more awesome news than that, they've now decided to open source the software! One of the games in the bundle has already had the code opened.
This made my morning.
The awesome people at Wolfire Games decided to do something a little different: offer 5 quality games for download and ask people to pay whatever they thought was appropriate for the bundle. They've made over $1 million on the venture so far! I've seen recording artists do this before, but I'm not aware of a game company that's done something like this before. Do any of you know of such a phenomenon in the game industry before this?
In even better news, they have also donated a portion of the money they've made to the Electronic Frontier Foundation, and in even more awesome news than that, they've now decided to open source the software! One of the games in the bundle has already had the code opened.
This made my morning.
Tuesday, March 30, 2010
Libre Planet 2010
I took a redeye out of SFO and landed in BOS at 7:30am EST. I got into a cab with a driver who kept bugging me about paying cash even though I insisted I wanted to pay with my credit card. I arrived at 1 Oxford St., Cambridge, MA. at 8:15am for Libre Planet 2010. Needless to say, I was a bit tired already.
Leslie arrived later in the morning and we spent some time catching up. I reviewed the agenda for the weekend, saw the introduction, and stuck around for the Intro to the Command Line class. Having just announced accepted orgs for Google Summer of Code™ 2010, I was still responding to emails and trying to fix problems where we found them.
I met Selena very early in the day. We spent some time standing outside Hall D and charging our laptops, making presentations, and gabbing. Unfortunately my brain was slowly shutting down from lack of sleep and a bit of stress from the previous days. I decided to stay for a few more hours and then left after lunch. I checked into my hotel and got some sleep. I left the hotel feeling significantly more human than when I went into it.
Dinner with the Women of Free Software was great. I met some amazing women who are really doing some great things for free software and the community as a whole right now. I'm really looking forward to seeing them again and working with them on all manner of topics. I went to bed on Friday night thoroughly excited about the opportunities now presenting themselves for me.
Saturday was full of some great topics. Discussions throughout the weekend ranged from "should you pro-actively justify your use of proprietary software or hardware if you have an arm of your business that advertises its use of free software" to "what is the best way to get yourself recognized for your contributions to the community without the use of a patent?"
I think the best topics came on Sunday, though. Deb had arranged an entire track of topics on Sunday related to Women in Free Software and I found it incredibly useful. Selena did a talk on "50 Ways to Love Your Project" and I am now tempted to ask her if I can crib some of the presentation because it was so wonderful. I think encouraging people to give back to FOSS in more ways than just coding is really important if we want to continue to build the community.
Most important of all, though, I spent some time really thinking about how I feel about all these issues of privacy, freedom, and open now that I am apart of the community. It was a great learning experience for me and I hope to get to go back next year.
Leslie arrived later in the morning and we spent some time catching up. I reviewed the agenda for the weekend, saw the introduction, and stuck around for the Intro to the Command Line class. Having just announced accepted orgs for Google Summer of Code™ 2010, I was still responding to emails and trying to fix problems where we found them.
I met Selena very early in the day. We spent some time standing outside Hall D and charging our laptops, making presentations, and gabbing. Unfortunately my brain was slowly shutting down from lack of sleep and a bit of stress from the previous days. I decided to stay for a few more hours and then left after lunch. I checked into my hotel and got some sleep. I left the hotel feeling significantly more human than when I went into it.
Dinner with the Women of Free Software was great. I met some amazing women who are really doing some great things for free software and the community as a whole right now. I'm really looking forward to seeing them again and working with them on all manner of topics. I went to bed on Friday night thoroughly excited about the opportunities now presenting themselves for me.
Saturday was full of some great topics. Discussions throughout the weekend ranged from "should you pro-actively justify your use of proprietary software or hardware if you have an arm of your business that advertises its use of free software" to "what is the best way to get yourself recognized for your contributions to the community without the use of a patent?"
I think the best topics came on Sunday, though. Deb had arranged an entire track of topics on Sunday related to Women in Free Software and I found it incredibly useful. Selena did a talk on "50 Ways to Love Your Project" and I am now tempted to ask her if I can crib some of the presentation because it was so wonderful. I think encouraging people to give back to FOSS in more ways than just coding is really important if we want to continue to build the community.
Most important of all, though, I spent some time really thinking about how I feel about all these issues of privacy, freedom, and open now that I am apart of the community. It was a great learning experience for me and I hope to get to go back next year.
Tuesday, March 16, 2010
Making My Way in Open Source
I have to admit, I didn't plan to be here right now.
I spent a couple minutes a couple years ago looking around jobs at Google that random people were doing and came across the Summer of Code program. I knew that Summer of Code happened, vaguely, somewhere in the regions of Google I Didn't Participate In. I thought it was an amazing program, an amazing group of people, and not something I would ever get to participate in first-hand. Little did I know.
Around the same time I met another amazing guy named Rob Kaye of the MusicBrainz project. We saw each other in some of the same social circles but never really talked business. He knew I worked at Google, I knew he worked at Open Source, it was just one of those things.
Rob came to me a few months ago and said he'd lost the Treasurer and Secretary of his BOD. Would I like to do it? Sure, I said. I had experience as a project manager and an admin, so taking notes, getting people to do stuff, and running numbers was really up my alley. It was a fortuitous move - just around the same time I had a lunch with Leslie Hawthorn on a whim.
Talking to Leslie made me so excited. It got me back into the mindset of "I want to change the world and I just need to figure out how" and here was my opportunity. The more I learned about Open Source the more I felt like I could change the world. I really wanted to join the team. I told Leslie that and came and sat on her couch in Mountain View to prove my devotion to the cause.
Now I'm here and just the experiences I had in the last couple months in the midst of my transition to the team have been outstanding. The people I've met, the emails I've received, the happiness and the thankfulness of the community is just astounding. If I can give these people a fraction of what they've already given me I will have changed at least my own world.
I spent a couple minutes a couple years ago looking around jobs at Google that random people were doing and came across the Summer of Code program. I knew that Summer of Code happened, vaguely, somewhere in the regions of Google I Didn't Participate In. I thought it was an amazing program, an amazing group of people, and not something I would ever get to participate in first-hand. Little did I know.
Around the same time I met another amazing guy named Rob Kaye of the MusicBrainz project. We saw each other in some of the same social circles but never really talked business. He knew I worked at Google, I knew he worked at Open Source, it was just one of those things.
Rob came to me a few months ago and said he'd lost the Treasurer and Secretary of his BOD. Would I like to do it? Sure, I said. I had experience as a project manager and an admin, so taking notes, getting people to do stuff, and running numbers was really up my alley. It was a fortuitous move - just around the same time I had a lunch with Leslie Hawthorn on a whim.
Talking to Leslie made me so excited. It got me back into the mindset of "I want to change the world and I just need to figure out how" and here was my opportunity. The more I learned about Open Source the more I felt like I could change the world. I really wanted to join the team. I told Leslie that and came and sat on her couch in Mountain View to prove my devotion to the cause.
Now I'm here and just the experiences I had in the last couple months in the midst of my transition to the team have been outstanding. The people I've met, the emails I've received, the happiness and the thankfulness of the community is just astounding. If I can give these people a fraction of what they've already given me I will have changed at least my own world.
Subscribe to:
Posts (Atom)