The PyDX Post-Mortem

We spent over a year planning PyDX. From my perspective, the result was worth every bit of stress. I’ve been thinking about what I want to say about the conference now that it’s over. I’ve stopped and started this post a dozen times so far. Several versions have been downright sappy.

Instead, here’s the top five things that stuck out for me during PyDX.

1. Bake Diversity in from the Start; It’s Not Something to Add Later

I have no shame when it comes to talking about diversity numbers in order to drum up sponsors, but I actually feel good about how we PyDX organizers handled questions of how to make our conference more diverse. We focused on what real people needed to feel comfortable showing up to a conference — providing a safe environment, offering child care, even small group opportunities.

  • We came within four tickets of selling out.
  • We provided full scholarships to more than 90 percent of applicants, and were able to offer free tickets to the rest through our volunteer program.
  • We didn’t keep official numbers on diversity, but I made some informal counts. About half our attendees and speakers were diverse on some axis.

We didn’t have to focus on creating diversity when we already had a space that welcomed diversity in — and we responded directly to what people told us they needed to be able to attend. Remember, you can’t assume you know what anyone else needs.

Given that I attended a conference earlier this year that was exceedingly proud that 15 percent of attendees were women, I feel great about PyDX on this front.

2. Technical Talks Don’t Get All That Much Love, Surprisingly

I was obnoxiously proud of our speaker line-up, but I was surprised by what attendees responded to most enthusiastically. Looking at social media during the conference and talking to attendees afterwards, everyone was excited by talks that focused less on code — talks about topics like how to learn and how to build culture did really well.

The exceptions — the technical talks that got rave reviews — all had one of two key characteristics. Either they were workshops, where attendees participated and left with code of their own, or they were doing something far outside of typical Python projects, like making music,

Just about all of the talks went well, by the way. I’m not critiquing any of our speakers here. I’m speaking solely about what attendees were most excited by.

3. Not Screwing Up Codes of Conduct Requires Planning

I strongly believe that having a code of conduct is a minimum requirement for a conference (as well as smaller events and even occasional meetups). Having one sets expectations and creates a safer environment for every single attendee.

Organizing PyDX has only solidified my belief. The experience also highlighted some areas where we can make setting up and enforcing codes of conduct much easier — PyDX was a learning experience, because I’ve usually only been in a position to think about codes of conduct for smaller events.

These are my key takeaways:

  • Create an incident response plan in advance. You never want to be trying to figure out how to deal with a specific issue in the moment, especially when you’re already stressed out of your mind about whether the keynote speaker’s laptop is going to work properly with the A/V equipment.
  • Talk to an expert when creating your incident response plan. We actually didn’t write our own plan — instead, Audrey Eschright sat down with us and went over potential issues and how we wanted to handle them. She put that information together into a document we could refer to during the conference and that had enough detail that we could hand it to a volunteer if need be. Budget the money for that sort of expertise; it’s far cheaper than a lawyer after the fact.
  • Every single organizer and volunteer is on duty for code of conduct issues. You should absolutely have a point person, but any attendee facing a problem will talk first with the staff member they most trust who they can catch alone. And those conversations are going to come up unexpectedly — no matter the events I’ve attended, restrooms are de facto meeting rooms because most people feel they can safely talk about anything there.

4. Venues Control So Many Things and They Could Use Their Power for Good

Our venue was our single largest expense. Our venue was also the most constraining factor in planning PyDX. Until we’d found a venue, we couldn’t figure out food, childcare, or even the actual dates of the conference.

First off, the UO White Stag Block was a great venue to work with. They were able to meet most of our requirements right away and there was really only one request we made that couldn’t be met, due to the classes that were in session in the building during our conference.

That said, any venue winds up controlling a lot of how a given conference runs. We had to work within our venue’s constraints:

  • We could only use specific tape for hanging anything on the walls.
  • We could only use catering that had already been approved by the building.
  • We had to have insurance for the event.

That last constraint has kept me thinking: Insurance is required in order to fix any problem that occurs during the conference, including legal dilemmas. Why don’t venues have similar expectations for tools that mitigate risk, like codes of conduct? Isn’t requiring events to do more work to avoid any problems or negative attention more cost effective for venues?

5. The Amount of Help People Offer is Amazing

PyDX is truly a community conference. We had two larger sponsors: MailChimp and Anaconda, both of whom made a major difference in our ability to put on the conference. But around 80 percent of our funding came either directly from ticket sales or from local companies supporting the conference (including a lot of consultants and other small businesses!).

I feel like everyone I spoke to in the weeks leading up to PyDX offered to help in some way. The whole experience has been an important lesson in gratitude for me — a reminder that people will help if you just remember to ask. A few will even go out of their way to help without the request.

Thank you to everyone who made PyDX a reality.

And for those inquiring minds who want to know, we were four tickets short of selling out, so I’m not getting the tattoo. At least, I’m not getting it this year.

A Preview of the Conference I’ve Been Planning for the Last Year

pydx-color-logo-blue

I’ve been working on PyDX for over a year. So have my phenomenal co-organizers, Rachel Kelly, Georgia Reh, Melissa Chavez, and Christopher Swenson. This weekend — October 10th and 11th — all of that hard work is going to pay off.

PyDX, by the way, is a community conference for Python programmers in the Pacific Northwest.

Our Schedule Rocks

I’ve already said that I sort of wish I wasn’t organizing PyDX, because I want to attend it. We’re filming all of the talks, in part because I would cry if I didn’t get to hear at least a few. Here are the talks that I’m particularly thrilled about:

  • Melissa Lewis’ keynote (Saturday AM) — I’ve had the pleasure of hearing Meli speak at PyLadies events and she is going to blow away the PyDX crowd.
  • Terian Koscik’s Build a Bot workshop (Saturday AM) — Terian has an impressive array of Twitter bots that do some cool tricks. She inspired me to start working on my own Twitter bot, but I need some help (I’ll probably watch the video of this talk repeatedly).
  • Evan Palmer’s Making MIDI Music with Python talk — I admit that I actually got to hear Evan practice this talk, but I’m still excited for the final version. He’s making music programmatically!

You can see the whole schedule here as a PDF. I’m biased, of course, but I think we’ve got a great line up across the board.

I’m incredibly grateful to our speakers for putting in proposals and agreeing to speak at PyDX. Many are traveling to Portland on their own dime to do so and I’m a little in awe of the group of people we’re bringing together.

A Conference for Everyone

One of our commitments from the start of organizing this thing was to create a welcoming conference where everyone feels comfortable. Every PyDX organizer has been to tech conferences where we’ve felt like we don’t belong and we’re willing to go to extreme lengths to avoid anyone feeling that way this weekend. A lot of these decisions, by the way, didn’t take all that much time or money to implement.

A Dry Conference: Tech conferences tend to be boozefests, even though many people either don’t drink at all or would prefer not to drink around people they know professionally. So we’re not providing alcohol as part of the conference (though attendees are welcome to meet up after hours for drinks if that’s their thing).

A Code of Conduct: I’ve reached the point where I just won’t deal with events and organizations that don’t have a code of conduct (as well as a way to enforce their CoC). It’s a matter of safety.

Scholarships: Our tickets are priced at $100, which isn’t cheap. The value is more than there (especially when you consider we’re providing food, childcare, great speakers, and more) but we are aware that it’s out of reach for many of the people who might benefit from attending PyDX. So we’re offering scholarships. And if you want to sponsor someone else’s scholarship, you can sponsor for any amount through this payment form. A full scholarship costs us $200 to provide, because we offer stipends for travel and other expenses, depending on the recipient’s need.

We had a good business case for diversity, by the way, which helped us explain the importance of these steps when fundraising and marketing. PyCon North America is taking place in Portland in 2016. We’re making sure that anyone who is considering learning Python before that point has an easy way to get started and to join the local community (which desperately needs more programmers).

Plenty of Pythonic Personality

Community conferences are great because they have more personality. When a conference hosts several thousand attendees, everything has to run like a well-oiled machine. But since PyDX is a smaller community conference, we can have a little fun.

Our entire vibe is a weird mix of hipster jokes and Monty Python references. I’m still not sure I’ve found all the jokes on our website, but I did have a great time writing our sponsorship prospectus (I did have to spend some time researching synonyms for ‘artisanal’).

And I’ve dared the community to help us sell out. If we sell out of tickets (and yes, scholarships count), I’m going to get the PyDX logo (the snake at the top of this post!) as a tattoo. I was originally threatening to get that tattoo on my butt. However, since I want to be able to show it off without violating the code of conduct, I’m thinking my leg is a better bet. Last time I checked, we still needed to sell about 40 tickets for me to get that tattoo. Want to make it happen? Buy a ticket (use FRIENDOFPYDX for 10% off) or sponsor a scholarship (same payment form as before). You know you want to see me all inked up.

 

My Template for Technical Resumes

Offline, I spend a lot of time helping friends with their resumes. I’ve even given a couple of workshops about technical resumes.

This is the template I use in helping someone get started in creating a technical resume:

You can also access the document here. You may notice a lot of comments in this particular document — I’ve laid out the logic and options for each section in the file so that anyone using it doesn’t have to refer to anywhere else. With that in mind, I strongly recommend copying the file to your own Google Drive and then editing that copy.

A Brief Review of PyCon 2015, Based Entirely on Swag

Last week, I flew up to Montreal for PyCon. I’m now home, without any new international incidents to add to my record. It was my first PyCon, but it won’t be my last.

If Python (or open source development in general) is your thing, all of the talks from this weekend appear to already be on YouTube. Since I mostly stuck to the hallway track, I’ll be watching a lot of these videos myself and don’t feel qualified to offer a review. However, the hallway track was fantastic and I would recommend it in future years.

I can review the swag I gathered at PyCon, though. Based on t-shirts alone, I’m pretty pleased. I found not one, not two, but three ladies tees that I liked enough to take home. Considering that booths at most other tech conferences only offer men’s shirts, the availability of ladies’ tees is a good indicator of an inclusive community.

Even better, though, there was plenty of non-shirt swag. Since I’m trying to make sure my wardrobe doesn’t entirely look like it came from a trade show hall, I’m always excited to see other swag that I’m actually interested in. I’m now stocked up on small notebooks for quite awhile, including a few that have a variety of pages for sketching different types of wireframes. I’m also up a beer glass, breath mints in reusable tins, and some pretty cool fake tattoos that I’ll actually wear.

I’d like to note that I’m totally cool with the booths that didn’t offer a whole lot of swag (or any at all) — I’m just as thrilled to just talk about cool products that I didn’t know about in advance and see some demos. I don’t have to have swag, but if it’s on offer, I like to see a variety that’s appealing to all sorts of conference attendees, rather than just to stereotypes.

And, as an added bonus, next year’s PyCon is here in Portland. If you’re interested in attending, keep an eye on the PyCon website. Just a head’s up, though: my couch is already booked for PyCon 2016 and tickets are guaranteed to sell out.

Are Tools Like Zapier the Same as Programming?

7413565310_f75199807d_o

Truly amazing things can happen when you can pair one app with another, integrating the results to get something better.

But the actual integration process slows down the speed at which such mashups can be rolled out — or at least it did. While there are still plenty of apps that require developers to write custom integrations for each set of apps they want to pair together, web-app automation services like IFTTT and Zapier make it possible to come up with new integrations on the fly, without writing a line of new code.

Personally, I find these services to be the greatest thing since sliced bread. While I know the basics of writing code, I’m still at the point where I have to write out exactly what I want to happen in fairly specific detail. That usually happens to be in the format that if this one thing happens, I want this other thing over there to happen next. As it happens, IFTTT stands for ‘If This Then That’ — the short form to the average approach to deciding what simple computer programs will do.

Are IFTTT, Zapier and Tools Like Them Enabling a New Type of Programmer?

As I started outlining this post, I had an incredibly difficult time figuring out just what these tools are called: “web-app automation service” seems to get the most use across various technology blogs, but it’s a mouthful. We just don’t seem to have the right words to clearly describe what’s going on when you log into one of these sites.

Part of the problem is that while the various web-app automation services seem to be doing something novel, the reality is that what’s on offer is more a matter of user interfaces than anything else. Every single app that IFTTT and Zapier offer connections for has some sort of API — an interface that a developer can use to make use of the app in her own programs. That API might be available for free or it might have a price tag attached, but it has to be already present for a web-app automation service to tap into it.

Furthermore, if you look at the actions you can take with a given app through a tool like IFTTT and you’re also willing to dig through that same app’s API documentation, you’ll find that the actions you can take using that app are basically identical whether you’ve got an automation tool acting as an interface or if you’re willing to write some code.

If you’re getting the same results a programmer would, using the same tools (albeit with a little something special added on), are you a programmer automatically?

The question of Zapier’s place in technology today is particularly interesting because Zapier has been on a big push to add new apps to the many it already integrates. The company added a new app every day in February. Last month, Zapier announced an improved developer platform, making it easier for developers to connect their apps up to the platform. (I may have taken the announcement as a cue to nag a few developers I know about why they should invest some time in improving their integrations.)

Good Programmers Use Time-Saving Tools, Right?

It’s tempting to dismiss web-app automation services as not meeting the ill-defined standards of exactly what counts as programming. But we shouldn’t be too quick to judge.

Programmers are well-known for a willingness to embrace all sorts of tools to make their work easier. Consider frameworks that sit on top of programming languages to speed up development dramatically. Ruby on Rails, for instance, has become a favorite of new programmers because it hides a lot of the more complicated aspects of programming under some friendlier tools. As a result, new programmers can build websites and apps much faster with Ruby on Rails than if they were to use Ruby on its own.

While I have heard some grumbling from old school programmers that anyone who uses a development framework isn’t a ‘real’ coder, I’m pretty sure that the same people find plenty of other ways to exclude as many people as possible from the little club they’ve built for themselves. I’m okay with being picky about the development frameworks you personally want to work with, but there’s no doubt in my mind that using such a framework is definitely programming.

Tools like Zapier and IFTTT aren’t much different than frameworks: the user still has to invest plenty of time into figuring out what they want as an end result (unless they’re willing to stick to premade recipes). Even those premade recipes, however, can feel a bit like templates that you should tweak to your own uses, just like every programming tutorial. Sure, using a web-app automation service isn’t a particularly robust approach to programming, but it requires enough of the same mindset that we should take it seriously.

The Real Gateway to Programming

I have plenty of friends and acquaintances who are working on the question of how to get kids interested in programming. One of the favorite approaches seems to involve getting kids playing games that incorporate aspects of programming. But while getting kids to play video games may be a logical strategy, taking a more basic approach may have more value.

Just because an individual happens to be young doesn’t mean that she doesn’t have problems in her life that she wants to solve: I can’t even count the number of times I get calls from younger friends and family members asking how to do something technical (I might be considered technically savvy in some circles). And, sometimes, I have to tell them that there isn’t currently a tool to accomplish exactly the results they’re after. Suggesting that they learn to program and build their own solution rarely goes over well.

But what if there was a web-app automation service that focused on the tools that younger users rely on? How hard would it be to convince kids to sign up for the service? Finding the apps to include certainly wouldn’t be a problem: Snapchat is pretty popular, but the various educational apps that teachers now use to assign and manage homework. Most of these apps already have APIs in place, even if those APIs aren’t widely advertised. With the right connections in place, I’m certain that it would be easy enough to get younger users to use such a service.

Having to start thinking in that if-this-then-that format provides a certain entryway into a programming mindset — one that would making teaching the process of writing code much easier. Even better, once kids start using such a service, they’re almost certainly going to come up with more ideas for combining pieces of technology, some of which will require more advanced programming skills. Making the leap just isn’t that hard at that point, especially in comparison to the change between thinking that you’re doing something just for fun and suddenly needing to shift to be able to think of that same process as work.

These Tricks Aren’t Just for Kids

Clearly I’m a big fan of web-app automation services (even if that name makes me cringe every time I type it). At the very least, I see them as a way to minimize copying and pasting information from one computer window to another. But I also see them as an amazing opportunity for how businesses can move forward.

We don’t have to have big behemoth software packages that all come from the same company in order to guarantee our tools work together seamlessly. We have more options (or at least will when tools like Zapier are a normal part of our day-to-day processes). We have the freedom to use the best application for a particular task, no matter who makes it, as long as the developer in question has built an API — and that’s fairly standard practice, even when an application doesn’t advertise its API as a feature. Just go through the web-based apps you already use and check for the word API. It’s usually down in the footer of the front page.

But these tools also do good things for how we think about business problems. We’re moving into an age where every business generates absurdly large amounts of data. Just being able to move that data around efficiently makes a web-app automation service valuable. But getting us in the mindset of thinking about how we can use that data in different contexts — if I take in this piece of information here, how can I push it out over there? — improves our ability to run our businesses.

Not everyone needs to know how to write code to run a successful business, but I would argue that every entrepreneur does need to understand at least the basics of programming. In particular, knowing what’s possible is crucial, whether tools already exist with a given capability or if you’ll have to go out and find someone to put together the code. If you don’t have the right mindset, you’ll slip behind the competition as they find and build new tools. But if you can just write simple statements of what should happen after a certain triggering action, you have the skills to team up with an experienced programmer to create the application that will revolutionize your industry. Beyond that, you don’t need much more than a good idea.

Image by Flickr user Thomas Amberg