Leaving NASA

This has been a hard post to write.

I was delighted that on January 3rd, 2005 I started my first day working for the National Aeronautics and Space Administration (NASA). While I wasn't working on science efforts, I was at least contributing to the cause. In 2005 I was introduced by co-worker Chris Shenton to Python, which became my favorite programming language ever. I also learned tools like Zope, Plone, and Django. Over the past five years, I've met a lot of fascinating people in and around the agency, a list that seems endless in size and scope. That includes astronauts, scientists, engineers, developers, managers, and so much more.

This meant so much to me, and maybe because my first memories of television as a child were the moon landings of the early 1970s. I dreamed as a child of being an astronomer or astronaut, and sometimes I plot how I would redo my life to fit these dreams if I got a second childhood.

In the past year I've had some incredible opportunities present themselves to me. I've been presenting frequently on Django and Pinax. I've had the singular honor of writing course material for Holdenweb, LLC on behalf of the O'Reilly School of Technology. Representing NASA as a contractor to the Python and related communities has been both enjoyable and a great honor.

Yet all things, even good ones, must come to an end.

I've decided to become an independent consultant. My first project will be working with Revolution Systems (Jacob Kaplan-Moss and Frank Wiles) on a neat stealth project that looks very promising and once launched will help people. The project will be Python/Django/Linux based, and the client insists on accessibility, testing, and quality work. We'll be exploring the boundaries of what has been done with those tools and besides what must remain proprietary, a lot of our work will end up going back to the community. Sounds like my kind of thing!

My last day is April 1, 2010. I'm both excited to explore this new project, and saddened that my professional world for the past five years is coming to an end. Yet the overlap in technology and the participation of the NASA SMD python group in the open source world means that my work with NASA isn't coming to an end, its just transforming into something different.

Nevertheless, this is the end of an era for me.

Which is partly why I'm happy that I'll still be in touch with my fellow NASA SMD Python contractors such as Katie Cunningham, Chris Shenton, Chris Adams, James Saint-Rossy, and others. I also plan to be real friendly with the awesome Ames Research Center Python/Django/FOSS groups such as the intrepid Mark Friedenbach and the entire incredibly awesome Nebula team.

I'll miss having the pleasure of working with Leslie Cahoon, Jessy Cowan-Sharp, John Kasmark, Bob Ryan, Candace Solomon, Bill Keeter, Gamble Gilbertson, Meredith Mengel, Malik Ahmad, Jenny Mottar, Mike Brody, Virginia Butcher, Dawayne Pretlor, Michele Montgomery, Jim Consalvi,Siew Chin Hon, Hans Goetzelt, Shannon Lantzy, and many more.

Lastly, I'll miss the honor of serving civil servants such as Gretchen Davidian, Sharron Sample, and Ruth Netting and others.

Pycon 2010 report III: Sprints

My report for the sprints of Pycon 2010. This isn't a general review of the sprints, just how it affected me.

Pinax Sprint

I don't have a hard count of how many people participated on Pinax this year. Last year's sprint looked like we had a lot more, but last year the Pinax room was home to people doing other things, albeit mostly Django related stuff. In any case, this year we had probably about 10 people working on Pinax, or things that went directly into Pinax.

While James Tauber is the leader of the Pinax community, this year Brian Rosner stepped up and did an amazing job being both a technical resource and director of geeks. The mutual clarity of vision and obvious telepathy between Brian and James is truly a joy to behold.

I also appreciate the entire Pinax community. Besides coaching me on Git branches (work uses SVN so I just don't get enough Git practice) they also gracefully understood that I was a bit distracted this year.

My specific contributions to Pinax

One of the things that had bugged me about Pinax for some time were the individual project tag apps. These were a per project extension of django-tagging, and were used to simply display tagged data. I was never happy about the displays of the tags, the lack of pagination, or that you had to create/modify an entire project level application just to control a display.

So last DjangoCon I wrote django-tagging-ext. What it does is let you control the displays of tags via a root urlconf wiring. It still needs some work (cleaning a query, 100% test coverage, better documentation), but its a big step up from the alternative.

For Pycon I volunteered to go into all the Pinax projects that used tags and replace the tag_app there with django-tagging-ext wiring. I thought it would be relatively trivial, but in practice it was not.

The issue was that immediately prior to the conference, changes had been made to Pinax trunk that caused a small number of errors. All them passed existing tests but failed when you actually clicked through pages. Yeah, that does mean that Pinax code coverage needs improvement, but that is something we are working feverishly on. In any case, what that meant was that by implementing the new tag display system, I got the chance to fix a number of small but poignant bugs.

I also worked some to help the code coverage of tests. Brian Rosner worked with me and gave me some excellent pointers. I feel sad because I think we had a disconnect on what we consider pair programming, and want to assure him that the time he gave me was a high mark of the conference.

In regards to pair programming, I don't mind working with someone until you figure something out, but spending hours and hours sharing a computer drives me nuts. Once a person 'gets it', go do something else and let them go forward.

Volume of Contribution

Looking at the Pinax impact chart on github I can claim that I had the most impact during the sprint. Heck, I even jokingly claimed it on Twitter.

Except that claim is false.

The truth of the matter is that how many commits I did in a brief period is nothing compared to what Brian and James did to equip others to make commits. Or what they've done during the history of Pinax. Or what they might have done to side projects that touch Pinax. Also, during the sprints my work was really focused to a specific area of Pinax, and besides some work I did with Skylar Saveland, I worked mostly by myself.

So that claim is full of hubris and rather silly. If that claimed annoyed anyone in the Pinax community I'll buy your forgiveness with a beer.

Conferences are a double edged sword

This post isn't for developers, its for managers.

In the Python world once a year there is Pycon. In other languages, tools, and frameworks they all have that one big conference where all the top people go. There are classes, tutorials, scheduled talks, open spaces, keynotes, and tons of networking. All your developers will want to go, and the ones that do will rave about the time they had. So how do you as a manager handle a big conference?

Conferences are a double edged sword. If handled well they will be a huge boon to you and your organization. Handled poorly and they can be devastating to you, your projects, your team, and your organization. Knowing which way to swing the 'conference sword' in such a way that you don't get cut is a handy tool to have in your pocket.

First, remember that at the big conference there will be lots of networking. Make sure your developers are really happy with you before they go. Also have your developers go with business cards. Ask them to bring back business cards. Remind them of whatever referral policy your company might have. Why pay for a headhunter when your own staff can do the hiring for you?

Second, remember that people will be scoping out your staff for potential hire. Don't anger your developers immediately before, during, or immediately after a conference. Keep deadlines as far away as possible from the conference. Don't begrudge them leaving and task them with petty work. Because what would have been training plus an energizing break for your staff will now be considered job fair by your staff.

Third, try to cover even a portion of the costs of the conference. If your organization doesn't officially do conferences, then offer to pay for their time during the sprints just so long as that open source work even tangentially affects what they do back at the office. That way they don't use up so much leave and odds are they'll have lots of smart comrades around to help them through some of the tricky parts.

Fourth, when the developers come back, ask them what they learned. Ask if they can incorporate these lessons into current or future tasks. They'll gush about twenty new things and most of them will be inapplicable. But there will be one or two things that are a perfect match and you'll both be grinning at each other in regards to challenges now effortlessly overcome or new services you can offer.

Fifth, try to go yourself. In fact, try and organize the whole trip. If you are close enough, rent vehicles and drive down. Set up the hotel rooms. You'll be able to network with other manager types and your staff will rave about you. Hiring will become that much easier.

So lets look at two ways to handle a big conference like Pycon:

The Wrong Way

• Block any attempts the developers make in getting reimbursement for the trip.
• Schedule deadlines around the conference. If anything goes wrong, declare that this is why people should not go.
• Before the conference, grumble about developers going away and then when they come back grumble about time lost.
• Developer time lost at the conference should not be compounded by talking about the conference when they come back.
• Act surprised when your team comes back angry and at low morale levels. Act more surprised when they leave for positions elsewhere.

The Right Way

• Get business cards and fliers for your staff to bring to the conference.
• In the meeting before the conference, go over the company referral system for new hires. Also offer beer or a meal for new hires.
• At least get the developers paid hours for the sprints. Beg and borrow from your own manager to try and cover other parts of the conference. Act surprised with the gratefulness of your staff.
• Afterwards, dedicate a staff meeting to things learned at the conference.
• Go yourself and hang out in the vendor room. Hand out cheap but goofy swag. Bring thousands of business cards and hand them out. Visit a few talks. Invite developers from other companies to meals. Boast about your staff and company. Be amazed by the new hires you pick up.

Apologies to Katie

Katie Cunningham is a good friend of mine. We met about nine years ago through a mutual acquaintance. We had a number of similar interests all tied to general geekery and kids. I've always appreciated her honesty, humor, and work ethic. In December 2006 I got her a job at NASA, which eventually got her involved in Python and various related communities.

One thing I like about Katie is that she likes to cook and she always does so from scratch. Her focus is on a mix of various savory dishes and baking. Since she takes care to find out her friend's allergies and preferences, it is a rare moment when people do not like what she cooks. One of my absolute favorites is a blackberry cobbler that she makes, which she does not destroy with loads of sugar. She knows that when taken in quantity sugar adversely affects me and that I also love blackberries.

I'm good at entrees and appetizers and sides, but baking is beyond me unless I use a pre-mix. So I really respect what Katie does.

So anyway, recently on twitter when she was discussing bagels with Jacob Kaplan-Moss I called her out publicly for putting icing on cheesecake. As an Ashkenazi Jew from family who spent generations in the New York area (although I was raised in Maryland) I'm picky about cheesecake. Legal toppings are berries, and going crazy with toppings is having those berries in a heavy glaze.

Well, it turns out that the illegal toppings cheesecake instance was not done by Katie, but rather her mother. Katie's mom is a wonderful lady who is also a cook whose work is worth tasting and all around wonderful person. But she puts a thin layer of sour cream icing on cheesecake. While I'm sure somewhere there is a Jewish law against illegal toppings on cheesecake, Katie's mom's defense is that she is not a Jew. And I certainly appreciate her Southern style fare.

So, for what it is worth, this is my public, formal apology to Katie. She rocks and if you are smart, you'll convince her to bake for you.

Pycon 2010 report II

The first half day report for formal conference activities on February 21.

Plenary: Introduction

I helped in registration so I arrived late to listen to Van Lindburgh start the conference. Which was a shame because I like to listen to him speak. Nevertheless, I consoled myself with the knowledge that I had contributed my time and service to help him launch what turned out to be an amazing conference.

Keynote: Steve Holden

In December Steve had presented to the NOVA-Django a much earlier draft of his speech. As much as his stuff back in December was good, what he did at Pycon was right on the money. He was in fine form, and the conclusion was very much Steve Holden at his best.

The next night Steve was in rare fine form, but that is a story for another day...

Keynote: Guido Van Rossum

Being that I am Guido's biggest fan, and have trouble breathing in his presence, you might think I'm a bit biased. Alas, in this case, Guido's talk was not my favorite of the conference. If memory serves, at last year's Pycon he mentioned a desire to remove the "For Life" from BDFL and this year I think that showed a little bit. It was nice to have him field questions from the Eldarion supplied pycon.djangodose.com feed and the audience, but from Guido I guess I want vision and on-high judgements.

Leafy Chat, et al by Alex Gaynor

Alex Gaynor is great at public speaking. He is unafraid of crowds and speaks with good clarity. His talks are always informative, and this was no different. The downside was that for his talk he had 35 minutes to present a lot of information. So he didn't have the time to explore some of the technical hurdles they overcame in each effort. Nevertheless, it was informative, and by the end it seemed clear that one of the lessons re-learned was to focus on a simple core architectural design and make it work.

A Short Pinax Tutorial by Me

I've given variations of this talk at least three times previously. Once at DjangoCon, once for NOVA-Django, and once for Django-District. So I'm rather practiced at it, which turned out to be a good thing. Because, brand new good luck charm or not, this talk ended up having a host of problems.

First off, we couldn't get any Apple laptop to work with the projector. So we started 7-8 minutes late on a Windows machine. So I had to speak very quickly, especially if I was going to include the technical side of things.

So I finished the majority of slides with time to spare and then things went wrong again. The Windows machine... didn't do what was needed. Displaying Pinax and showing off its tricks just wasn't going to happen. So we ended up with an extended Q&A session.

Not my best presentation, but memorable.

In the works is me giving the talk a least a couple more times. Once with my local friends at ZPUG-DC and once at LA Django.

Managing the World's Oldest Django Project by James Bennett

James is always on the ball when it comes to presentations. His stuff is well researched and documented, and his voice is both relaxing and invigorating. It was good to hear about lessons learned, experiences, and some of the more interesting foibles they've been through.

An Underwater Python: Tortuga the Python Powered Robot by Joseph Lisee

Python powered underwater Robots? I was so excited by this talk!

Yeah, odds are it would have almost no professional applicability, but sometimes you just have to see what other people are doing with one of your favorite tools. I was impressed by the energy and creativity of the students at the Robotics group at the University of Maryland and am trying to figure out how to include robots in my next project.