PyGotham 2012 was a fairly typical tech conference. It was small and regional. This being New York, there were plenty of hipsters. There were a few more women than normal. The venue was quite unusual, but more about that later.

As mentioned, one surprise was that there were more women than expected; I’d say they accounted for at least 10% of attendees. PyGotham is organized by a woman, Gloria W., who is very active in women’s programming and startup circles and blogs, such as DevChix and Women 2.0 (linked article is about last year’s conference). I daresay her influence and planning had something to do with the gender balance. However, there were not many female speakers at this year’s conference– only one, that I can recall.

There were roughly four talks going on at any one time, impressive for the conference’s small size. Talks were scheduled with some overlaps, which made for a nice excuse to vote with our feet when it got boring, something I did several times.

That said, there were worthwhile talks. The biggest standout was by an engineer at Enthought (whom I cannot properly credit, because the PyGotham list of talks and speakers is not online at time of writing). The speaker’s experience was in running parallelized scientific code on clusters at various national labs, and he gave a great front-to-back overview of how to parallelize your Python code. He included tons of tips for debugging, rewriting for speed and memory efficiency, and testing your results. Interestingly, he said his use of Fortran and C had decreased substantially over the years, in favor of using Python. He talked a lot about the many benefits of NumPy arrays, and also recommended using tools like Cython for code in need of serious optimization. The speaker also mentioned the productivity boost you get by using Pyflakes in your editor, a suggestion which I can enthusiastically support. I get Pyflakes functionality embedded in vim via Syntastic.

There was a Python best practices panel, where the major ideas I filed away for future reference were:

• a sense that the Python community is growing increasingly interested in continuous integration;
• Cython is a popular tool for getting C-like speed with fairly minimal changes to your Python code (simply specifying C types), particularly amongst the heavily represented scientific and financial analysis crowd at the conference;
• and it’s a really good idea to use coverage.py to catch bugs in untested code.

Another great talk was given by Paul Winkler, a colleague of former Labs member, Kevin Webb. His talk was on future-proofing our websites against spammers. Sadly, I arrived too late, thanks to starting out in a much less interesting talk, to hear most of his suggestions, but it was delivered thoughtfully and with some live demonstrations. Once he opened things up for questions, some rather lively audience back-and-forth took place, with the main point of disagreement being on whether it’s good to let spammers know whether they’re being filtered out or not. This was refreshing in a conference where the majority of talks seemed to be introductions to various, new open-source libraries authored by the sponsoring companies, the live equivalent of blog posts or documentation.

Which brings me to my big question about typical tech conferences. Not to beat a dead horse, but why don’t they contain more talks of the case study variety? The nuts and bolts of overcoming particular challenges are some of the most interesting things about our jobs as programmers. Did you choose to go with a really abstracted, high-level solution to your problem? Were you able to find existing libraries to cobble together and get around your issue? Did you find a really quick, clever hack in the end, or was it more of a long slog through all the difficult stuff? Perhaps we don’t take enough notes as we dive into our rabbit holes. I have often had the feeling that I would learn more, become far better at what I do, and be able to spread more knowledge to the rest of the community, if only I documented my work with the rigor of a scientist (or our sysadmin) in his or her lab notebook. On the flip side, we programmers spend plenty of time reading tech blogs, and really don’t need to sit through talks that tell us little more than we get from obeying the perennial command to RTFM.

On an entirely different note, the coolest thing about PyGotham 2012, by far, was the venue. It took place aboard two boats owned by Hornblower Cruises, docked at Pier 40 in NY. The boats afforded a panoramic view of the Hudson, Jersey City and the west side of New York, as they gently rocked us through the talks, armed with plenty of gedunk. As part of the conference, two of the ship’s engineers gave a presentation on the technology that went into the vessels. These were no ordinary ships, but rather among the first hybrid diesel-electric drive ships ever made. When their company, based in San Francisco, won the contract to run the ferries going to Alcatraz, part of that contract stipulated that they would design and build the first hybrid-drive ship technology. Tens of thousands of engineer hours and millions of dollars later, they had a ship unlike anyone had ever tried to build, and that the regulatory officials at the Coast Guard had a hard time approving of! They told tales of having to reclassify high-efficiency LED light systems connected with Ethernet cable as “control systems” to comply with requirements about wire thicknesses for lighting systems, with some requests even having to go all the way to the central office in Washington. Eventually, it all worked out, and PyGotham attendees found ourselves enjoying the first event hosted aboard these novel cruise ships. There were a few drawbacks and kinks in the system, which hopefully they can work out. One conference space sat above the engine and was cursed by overwhelming afternoon glare on the presentation screen, rendering presentations hard to both see and hear, but it was nothing a few strategic curtains and better sound engineering wouldn’t fix.

Ultimately, PyGotham 2012 was a nice, small conference. In the future, I’d like to see greater speaker diversity, both in gender and in subject area– two or three sponsoring companies dominated most of the sessions– as well as a little more fun injected into the regular conference schedule, evening parties and hackathons notwithstanding. Offering a couple rounds of lightning talks might help promote a more lighthearted atmosphere, as well as diversity and breadth of topics. But PyGotham is still young, only in its second year, and offers a promising look at an evolving and maturing NYC tech scene, and will hopefully continue to do so in the future.