Last week I was fortunate to represent my startup at PyCon. This year's conference was hosted in Portland following last year in Montreal.

👋🏻 PyCon is really diverse

One recurring challenge of this conference is attending all of the sessions you really want to. There are simply too many interesting topics and the quality of every talk is very high.

I try to find a personally optimal subset by blending three factors:

  1. Work - Does this talk provide near-term value to something I'm working on or for a challenge we've had before?
  2. Personal interest - Is it something just really interesting to me?
  3. Else - Is this an off-the-wall talk where learning something could be valuable down the road?

Of course these aren't mutually exclusive. Like most startups, our stack is built on open source, so lessons learned in personal exploration lead to new ideas for work and vice versa.

There's also diversity in subject matter. One difference between Python vs. competing languages [1] is that we have strong communities beyond APIs and web apps. Python is used extensively for research and data science, dev ops, scripting, and automation.

🔋 Why PyCon?

Jenny Cheng put it best:

I’m not sure if it was the talks or the general atmosphere, but I felt excited/inspired about software development in a way that I hadn’t been for a while.

Image: Chart Attack

I believe every interaction in life impacts one's energy level.

Each conversation had, talk watched, and conference attended either consumes your energy or boosts it.

PyCon and its attendees gives me so much energy. After attending PyCon and regional descendants like PyOhio for a few years now, I've left with this feeling every time.

🛠 Refactor all the things

Brett Slatkin's talk Refactoring Python: Why and How to Restructure Your Code was one of the most practical sessions I heard this year. The thought and effort put into every detail to be clear, clean, and Pythonic really aligned with my coding values. While it is an opinionated reference, I've found the opinions well thought out and justified by experience.

I first discovered Brett's work through his book Effective Python. It covers 59 cookbook-style recipes (view all 59) that can be applied to your code to make it better in many ways. The talk he gave is based on a few chapters from the book.

If you happen to subscribe to Safari Books Online, the content is also available as a video. I've skimmed many chapters and perused the videos these past few months.

Bonus - Brett was kind enough to publish a list of what he discovered and learned at PyCon this year: Links from PyCon 2016 in Portland.

🗡 Binary machetes

Where's the machete emoji when you need one anyway?

So Ned Batchelder gave an interesting talk called Machete-Mode Debugging: Hacking Your Way Out of a Tight Spot. Normally someone talking about monkey patching the standard library would spark concern… but sit tight.

This is throwaway code to solve a problem right now, not something to be committed. Ned emphasizes that, and with a language so flexible, we might as well take advantage of everything it offers to help solve problems faster.

He also commented on something I've always wondered — why our method to create breakpoints programmatically is called set_trace(). It doesn't take much Python debugging before you come across one oddly un-Pythonic line:

import pdb ; pdb.set_trace()

It's so common in fact that many of us map it to a snippet (I use "pdb`" in Sublime). But we're creating a breakpoint, not a tracepoint… so, why is it named like that?

He explained it's not because of being a good public API method name, but for consistency with the underlying implementation. The pdb.set_trace() function creates a pdb.Pdb instance which calls pdb.Pdb.set_trace(...) on itself, and that implementation calls the lower-level system method sys.settrace(...) where the system's trace function is actually set.

👌🏻 Little surprises

These events are mostly serendipity from being in the same room with some of the best Python developers in the world.

  • At lunch I was lucky to be able to pick the brains of some more experienced speakers — Ned Batchelder and Dorian Pula.
  • Getting a few requests stickers from Kenneth Reitz is something that made me irrationally excited.
  • Discussing Cookiecutter and hackathons for a moment with pydanny (co-author of Two Scoops) was really cool.
  • A. Jesse Jiryu Davis gave a motivating talk on why we should share our expertise by blogging writing essays in Write an Excellent Programming Blog.

pip install requests sticker $ pip install requests

I want to emphasize that I'm just a "normal" person at PyCon. Anyone can do these things and interact with our community leaders in the same way.

Blogging is something I've been wanting to start; by that I mean not writing, but actually publishing to the world from my dozens (hundreds?) of drafts across Ghost, Medium, Notes, and more. After Jesse's talk, I sought him out for feedback on issues I've had with blogging (perfectionism, scope, publication timing, finding an editor, etc), and he was thoughtful and helpful.

📝 Sharing my notes

My session notes are openly available on GitHub. Some are on paper to be digitized. I share all my notes on tech books and articles this way too [2]. Follow along on GitHub for updates.

Notes - PyCon 2016

☕️ Written at Stumptown & Tea Chai Té in Portland

  1. Mostly Node, Ruby, Go; occasionally Java, PHP. I'm referring to any startup building a web apps or API, but this could be extrapolated slightly to include most companies building something similar. See last year's post for more — PyCon 2015: Are we still changing the world? ↩︎

  2. I started publishing my notes publicly last year. For example:

    ↩︎