I wrote a blog post last year, How to have a great first PyCon, in which I gave quite a few tips for making the most of your time at PyCon (if you’re a first time PyCon attendee, go read it). One thing I didn’t mention at all in that article on PyCon was the sprints.

I didn’t mention the sprints not because I don’t like them (I actually love the sprints and I usually attend at least the first two days of sprints every year), but because first-time PyCon attendees often don’t stay for the sprints. This is partly because the sprints can be very intimidating for first-time PyCon attendees. The fear that the sprints aren’t for me is a very real one.

This year PyCon has multiple options to help you have a successful sprint, including their annual “Introduction to Sprinting Workshop” on Sunday and, brand-new this year, the mentored sprints a hatchery track for underrepresented beginners. The applications for the mentored sprints have closed for PyCon 2019, but that’s something to keep an eye on for future PyCons.

In this post I’m going to share some advice for how to get the most out of the PyCon sprints and I hope to address the fears that folks often feel. I’m hoping this post might encourage you to add an extra day or two to your PyCon trip and give the sprints a try.

The sprints are a very different experience from the talk days at PyCon and they’re hard to compare to the rest of PyCon. Some people like the talks better, but I’ve also talked to first time sprinters who said the sprints were their favorite part of the conference.

In this post I’m going to share some advice for how to get the most out of the PyCon sprints. I’m hoping this post might encourage you to add an extra day or two to your PyCon trip and give the sprints a try.

Your fears going into the sprints

We’re going to start by addressing some common concerns. I’ve heard these concerns from folks I’ve encouraged to stay for the sprints and from folks I’ve interviewed about their advice for first-time sprinters.

I’m not experienced enough

I’ve never contributed to an open source project before and I don’t really know what to do. I’m a junior programmer and I’m afraid I’m not experienced enough. I don’t write code for a living and I’m afraid I won’t be able to get anything done because I don’t know how to do much yet.

The sprints are a great place for a first-time open source contributor. Making a contribution to an open source project while sitting next to the maintainer is a unique experience. If you contribute to open source at home or at work, you’re unlikely to have a project maintainer nearby.

If you’re a junior programmer or you don’t code for a living you might be afraid of your inexperience: maybe you’re pretty new to coding in general and you don’t understand git, testing, version control, and GitHub. But there’s very likely a project for you to contribute to. The sprints include sprint coordinators who can help point you to projects they’ve heard are particularly beginner-friendly or who have quite a bit of low-hanging fruit in their issue tracker for newcomers to dig into (something as simple as updating the on-boarding documentation can be a great benefit to maintainers).

It’ll be too fast-paced for me

You might think the sprints involve smart people coding for many hours on end, racing against the clock. This is false. From my experience, sprints usually aren’t like that at all.

There are some very smart people at the sprints, but there are a lot of newcomers too. Everyone at the sprints is new to something and most of us are mediocre programmers (who are more skilled in some areas and less skilled in others).

The “pace” of the sprints is really up to you. The name “sprints” is kind of a misnomer: I never find myself sprinting while at the sprints.

I’ve attended at least one day of sprints at PyCon US for each of the last 5 years and my sprint experience has almost always consisted of:

• Some high level conversation about an intriguing feature, topic, or idea
• Some low level conversation about how pieces of a project work (conversations about the inner-workings of a project are so much easier to have in-person)
• Some writing time. Sometimes this is writing code. Sometimes this is writing text copy for documentation or marketing material. Sometimes it’s my own writing time for a talk or article I’m working on.
• Some rubber duck time. I often wander around asking people what they’re working on and sometimes act as their rubber duck. I also often wander around seeking my own rubber duck if I get stuck on a particular topic or idea (whether on my own personal project or an open source project I’m contributing to).
• Plenty of personal break time. I very often take mental breaks during the sprints to wander the halls, often aimlessly. Breaks feel great, but they also often help my subconscious work on a task for a bit while my conscious mind rests.

Sprints are what you make them: some people prefer many hours of furious coding with their earbuds in most of the day but many people prefer something that looks a bit more like coworking with new friends in a coffee shop. Sprints are an intense experience for some people, but they don’t have to be intense for you.

My sprints are often more relaxed than the conference and many of the best conversations I have during PyCon come out of the sprints.

I won’t be able to get enough done while I’m there

If you’re only planning to be at the sprints for one day, can you really expect to get up to speed quickly enough to accomplish something meaningful?

This fear is very real for all sprint attendees.

If you’re just getting started on contributing to a new (to you) code base, you may not be able to submit a viable change (often in the form of a pull request) by the end of the day.

This fear is about framing: what is your goal at the sprints?

If your goal is to get a pull request merged into an open source project by the end of the day, try to find something minor that needs fixing in the documentation, website styling, or something else that the project maintainer agrees needs fixing. It’s much easier to get a minor change merged if you get an early start and pick a small issue.

But if your goal is to make a more substantial improvement to a project, then you probably won’t get much code merged (if any) by the end of the day. For bigger changes, you’ll likely start your work at the sprints and continue it at home, often with help from the project maintainers (via comments on pull request and/or emails).

What to expect from the sprints

What can you really expect while attending the sprints? What is sprinting really like?

Some projects are easier to sprint on than others

Different projects sprint in different ways. Many projects go out of their way to welcome contributions from newcomers, some projects may struggle a little in welcoming newcomers, and a few projects might hold a sprint that’s focused entirely on engaging existing contributors since they might not meet to work in-person often (but you’re unlikely to stumble upon those).

If you’re not sure what project you’d like to sprint on during first day at the sprints, I recommend picking a project to sprint on that seems particularly newcomer friendly. The Pycon Sprints page has several projects that will be sprinting and after the conference ends on Sunday evening you’ll get a chance to hear many of the sprinting projects come on stage and tell you who they are and how you can help. Alternatively (or additionally), if you’ve identified a project that particularly suits your interests, talk to the maintainers and see if they think (and you think) their project would be a good fit for you.

Keep in mind that newer projects and smaller projects often have more to be done. It can be quite challenging to find issues that need fixing in big and stable projects like CPython and Django, but newer or smaller projects often need more help.

It’s also usually more fun to be a big fish in a small pond rather than a small fish in a big pond. It might take you the same amount of effort to make a small improvement to a big project as it takes to make a big change to a small project.

The maintainers are there to help you

During the sprints, project maintainers are there to help you. Project maintainers can quietly write code at home, but it’s hard for them to encourage you to quietly write code at home. So many project maintainers consider it their primary responsibility to help you contribute to their project during the sprints.

The maintainers of projects are usually focused on enabling your contributions during the sprints because they want your help. If you contribute to a project during the sprints, it’s more likely you’ll decide to contribute to the project again after the sprints. That would be great for the maintainers (they’re getting your help) and might be quite fun for you too.

You might be thinking “surely, the maintainers can’t be there entirely to help me”. And you’re right: a number of maintainers do contribute code to their own projects during the sprints. Generally the amount of code maintainers commit to their projects increases as the sprints stretch on. There are far fewer people on the third and fourth days of sprints than on the first and second days. If a maintainer stays for all four days of the sprints, they’re much more likely to commit code to their own project as the number of sprinters working on their project dwindles and as those still working start to need a bit less help than they did on the first day. During the first couple days of the sprints, most maintainers are there primarily to help you.

The sprints can be more relaxing than the talks

The talk days of PyCon can be pretty overwhelming. The sprints are a bit more structured (in a sort of odd semi-structured way) because everyone at the sprints is working on something together (or at least they’re working on something and they’re together).

The sprints are sort of like an introvert party: everyone is sitting at tables next to each other, sometimes talking and sometimes working quietly, but always sitting next to other humans without the need to constantly talk and interact. And even if you’re not working on the same thing as someone else, you’re still a PyCon person in a room with other PyCon people, doing whatever it is you’re all doing.

For some people the sprints really are a sprint, but for most of us the sprints are more like an endurance run, one with plenty of breaks.

Contributing at the sprints is often easier than online

Contributing to open source projects at the sprints is usually easier than contributing online. The ease of in-person communication often makes the experience less intimidating.

It’s easier to express oneself and empathize during face-to-face communication than over text-based communication. Emoji are great, but they’re not a substitute for body language and tone of voice.

It feels less awkward to chat with a project maintainer about your goals and your skill level in-person than via a GitHub pull request.

Little bits of seemingly meaningless conversation happen while folks sit next to each other for hours: conversation about weather, hobbies, what we thought of our lunch, pop culture, and whatever else comes up. That kind of natural conversation brings people closer together and makes us feel more comfortable communicating later, whether in-person or online.

Continued communication online is also often easier after face-to-face communication. After you’ve met a project maintainer in-person, you’ll likely find communicating online via their issue tracker less intimidating because you and the maintainer already know each other.

The in-person nature of the sprints makes them a uniquely favorable place for your first open source contribution.

How to get the most out of the sprints

The sprints are a unique experience that might give you a greater sense of community, purpose, and belonging than the (often not quite as communal) talk days of the conference.

What steps can you take to increase the likelihood that you’ll have a wonderful time at the PyCon sprints?

Don’t underestimate your skills

If you’re trying to get a feel for what project might be a good fit for you, let the maintainers know what skills you do and don’t have and see if you get a good vibe from both the maintainers and the project. If you do, run with it!

If you’re afraid you won’t have something to contribute, remember that, like businesses, open source projects have a wide variety of needs.

If you know something about marketing, you can offer to sit with project maintainers and help them improve their marketing materials. At PyCon 2016 I interviewed some project maintainers and then crafted slogans and wrote marketing copy that explained what problem their project solved and who needed it. I feel those were some of the most valuable contributions I made in a pretty short amount of time.

If you’re pretty good at design, you could offer to create visuals for projects (maybe logos, diagrams, or other visualizations).

If you know CSS or JavaScript, you could find a web-based project that needs help with their front-end. Being the “front-end dev among Pythonistas” or the “UX person among developers” can really help you make uniquely helpful contributions to projects.

Also keep in mind that there are often small projects that you can make big contributions to at the sprints simply because they’re in great need. Sometimes people even start a project at the sprints because it’s easier to get help from others when you’re in a room full of folks who might know a few things about the technology you’re using. If you join a newer or smaller project at the sprints (or start your own), you’ll often be able to find a whole bunch of low-hanging fruit that hasn’t been taken care of only because no one has had the time to work on it yet.

Attend the intro to the sprints the night before

Some maintainers list their projects on the PyCon sprints page to note that they’ll be attending the sprints. Some maintainers simply announce their project during the sprint pitches after the main conference closing, on the last day of talks (Sunday). If you are looking for a project, stick around after the last talk of the day and dozens of maintainers will walk up on the big stage to give an elevator pitch for the project they’re sprinting on, with each pitch taking about a minute.

During the sprint pitches, each maintainer will talk about what their project is, what kind of help they’re most in need of (fitting as much as they can in the very few seconds they have) and generally close with some commentary on whether their project is a good fit for newcomers. You don’t have to attend the sprint pitches, but doing so will increase your chances of hearing about a project that you’d actually really like to work on.

Another thing to pay attention to on the last day of talks is the hands-on Introduction to Sprinting tutorial on Sunday evening. The Intro to Sprinting tutorial is open to walk-ins (first-come, first-served) and is purposely held after the main conference closing so you won’t need to miss any talks.

Last year the Intro to Sprinting tutorial room filled up pretty quickly, so rest assured you won’t be alone. Definitely try to get the Intro to Sprinting workshop on your calendar (once the room and time are announced) and show up on-time if you can.

Try to prepare yourself for the setup time

Getting started on a new project can take a lot of time, so try to prepare yourself and your development environment as much as you can early on.

Make sure you have git, GitHub, a code editor, and a modern version (maybe multiple versions) of Python installed on your machine.

Get an early start if possible. The setup process can take a long time for some projects. Many projects will have a documentation page set up with instructions on what to install and how to install it. But be aware… sometimes the setup process is a little buggy and the first pull request you make to a project may be related to improving the setup instructions.

If you show up to sprints early, you might be able to pick a project and get that project setup on your machine before break time. If you’re feeling extra ambitious, you could even get a head start and prepare your machine the night before the sprints. I’ve never done this because I’m rarely feeling ambitious, but I know some folks do this to make sure they can get in a little more quality sprinting time on the first day.

Another way to prepare yourself for setup time is to stay longer. If you’re staying for 2 or 3 days of sprints, you can take it easy and spend more time on setup and getting your footing during the first day. That way you’ll feel more confident and more independent on the second day. If you stay more than one day, you might also get the opportunity to sprint on two different projects if you decide you’d like to switch projects on day 2 (or even mid-day if you’d like).

Oh and another way to prepare yourself: remember your laptop and your laptop charger (and if you’re from outside the US, a power adapter if needed).

Ask for help

If the maintainer of the project your sprinting on is in the room they’re likely there because they want to help you contribute to their project. On day 1 of sprints, project maintainers tend to prioritize helping you, over writing their own code. Please don’t forget to ask for help when you need it.

Also if you’re stuck on laptop setup issues, the PyCon sprint coordinators will be hosting a help desk during the first day of sprints (on Monday). The help desk is a great place to get yourself unstuck when you have a general issue that could use another set of eyes.

If you’re at the sprints to learn, you do want to struggle some. Struggling is a great way to learn, but don’t let yourself flounder for too long on issues that aren’t your area of expertise. If you get stuck, attempt to fix your problem by trial-and-error and Googling, talk to your neighbor or your rubber duck and after you’ve given yourself some time to troubleshoot, ask for help!

Plan to follow-through when home (if you’d like)

Keep in mind that you may not complete your work at the sprints. You’re likely to find yourself still in the middle of a pull request back-and-forth at the end of your sprints. Pull requests often require more work before merging. Expect to get started at the sprints, but not necessarily to finish while you’re there.

If you plan to complete your pull request at home, ask the project maintainer what form of remote communication would be best for questions you have regarding contributions.

Empathize with others

Your project maintainer may not show up early on day 1 and they might even leave early, depending on what their plans and schedule look like. If they’re at the Sunday night pitches or if you interact with them during PyCon, you might consider asking them when they plan to be present and how they plan to operate (will they be writing code or helping others write code or both).

When sprinting, try to empathize with your project maintainer. Empathy is challenging during remote open source contributions, but it can be a struggle even for in-person contributions.

Consider what your project maintainer’s motivations likely are and remember that they’re often trying to balance getting many new contributors to their project, getting bugs fixed, and maintaining the quality and consistency of their code base. Balancing multiple goals which sometimes compete with each other can be a challenge.

Text-based communication is hard, so seize your face-to-face communication while you’re at the sprints and try to get a sense for how your project maintainer thinks. If you do decide to contribute more after the sprints are over, that in-person empathy can help you continue to empathize remotely as well.

Some other places you may want to use empathy: empathizing with users of your code/documentation/design (someone is going to use your work) and the other sprinters in the room with you. It’s nice to congratulate your fellow sprinters when they get their code working or if they get a pull request accepted.

If you bring snacks, candy, donuts, or a small power strip to expand one power strip port into multiple, your kindness might give you happy neighbors at the sprints.

Be kind to yourself

Don’t go into the sprints with a very specific thing that you absolutely must do: have a goal but allow yourself to change your goal as you learn new information about your environment. Be flexible and be forgiving with yourself.

You’re allowed to switch projects at any time, as often as you like, and for any reason you like (i.e. the project isn’t as interesting as you hoped, the onboarding process isn’t as smooth as you expected, or the project isn’t a good fit for you). If you need to switch projects, don’t feel you need to offer elaborate explanations.

You’re allowed to stop sprinting at any time and take a break. You aren’t obligated to follow through on a pull request you opened (it’d be lovely if you did, but you don’t have to).

Time-wise, there’s lots of flexibility at the sprints. The maintainer of the project you’re sprinting on might get an early start or they might not show up until later on the first day of sprints. You need to give yourself flexibility as well.

Don’t feel obligated at the sprints: you don’t have to make a code change, you don’t have to be productive, you don’t have to show up at a certain time or stay for a certain amount of time, and you don’t even have to sprint on an open source project (I frequently don’t).

If you’d like to take half of a sprint day to explore the city you’re in with a new friend (or on your own because you need personal time), go for it!

Embrace self-care at the sprints, whatever that means for you.

Remember that sprints are lots of things to lots of people

During my first PyCon sprint in 2014, I helped a project figure out how to migrate from Python 2 to Python 3. The project maintainer wasn’t looking forward to that migration so they were grateful to have another brain troubleshooting with them.

But during that sprint I also got an idea for a contribution to another project (Django), was encouraged to pursue the idea, and a few weeks after the sprints I proposed the idea publicly. After my suggestion sat without feedback, I sort of abandoned it.

But at the PyCon 2015 sprints the next year, I brought up my abandoned idea to a Django core developer and they offered to shepherd my change through, so I continued my efforts during the sprints. A couple weeks after the sprints ended I finished up the idea at home and finally implemented the changes, which were eventually merged (after some scope tweaks).

My first two years of PyCon sprints involved some substantial code contributions that I hadn’t expected to make. Most of the changes I made were started at the sprints but finished at home.

The sprints were a source of idea generation and inspiration, not a place to get lots of work done. Since 2015 I’ve started sprinting on ideas more than code.

During my PyCon 2016 sprints I helped a few open source projects improve their marketing copy (so someone hitting their website would better understand what their project did and who it was for). My pull requests during these sprints were text-based changes, not code changes.

My PyCon 2017 sprints involved a lot of community work: discussions with folks about the PSF and the new Code of Conduct working group. I spent much more time in Google Docs tweaking documents than I did using git.

My sprints at PyCon 2018 involved writing talk proposals, meeting with new friends, and chatting with core developers about the soon-to-be-written PEP 582. I don’t think I made any contributions to open source projects (outside of possibly inspiring a bullet point or two in that PEP). But I had a great time and sitting quietly in the sprint rooms helped me get a lot of work done on my talk proposals.

The sprints aren’t one thing. If you’re not feeling like a code contribution is the thing you’d like to do during the sprints, get creative! Your time at the sprints can be spent however you’d like it to be.

Running your own sprint

This could be a whole article on its own, but I want to give a few quick tips for folks who might be attempting to run a sprint for their own project.

While I’ve maintained open source projects remotely, I haven’t run an in-person sprint on my own projects. So my tips on running a sprint on your own project come from the perspective of a contributor and a floating helper for maintainers who needed an extra hand.

As a project maintainer on day 1 of sprints, I’d consider your primary responsibility to be one of helping encourage other contributors. You want to help folks get their environment setup, help folks identify good issues to work on, help folks with their code contributions, and even help other contributors as they help out their neighbors.

Your job often isn’t to write code, it’s to be interrupted by people who are trying to make contributions but need your help.

For the in-person, in-the-moment part of running a sprint I have a whole talk and a bunch of related resources for folks who are coaching others in-person. But your job doesn’t start at the sprints. Ideally, you’ll want to prepare your project for the sprints a while before the sprints even start.

Many projects use issue labels to indicate issues which are specifically good for first-time contributors (something like “newcomer”, “good first issue”, “first-timers only”, etc.). I’d recommend looking at the many other contributor-friendly projects, studying what they do, and figuring out how you can make your project more friendly to new sprinters.

The PyCon sprints page also recommends this in-person events handbook made by the OpenHatch folks. Take a look at it! And if you can, ask questions of other project maintainers you admire who will also be sprinting: how do they ensure newcomers feel appreciated, how do they help folks feel accomplished, what do they do to get their project and their minds ready?

Take note of the key events

Put the events you’ll be attending for the PyCon 2019 sprints in your calendar!

The sprint pitches are on the last talk day at PyCon, just after the closing of the main conference. The Intro to Sprints tutorial usually starts just after that. And during the first day of sprints the next day, the sprint help desk will be available to help you get some extra help on day 1.

Also remember the mentored sprints (if you’ve gone through the application process already) which are designed for underrepresented groups and are on Saturday during the talks.

Ask others what they think of the sprints

Much of the above advice was borrowed or enhanced by wisdom from others. I’ve held interviews with folks during the last few PyCon sprints, I’ve asked folks online what they think of the sprints, and I’ve chatted with first-time sprinters about what their concerns were going into the sprints. If you shared your sprint experiences with me in the past, thank you.

If you’re still uncertain about whether you should attend a sprint, please talk to others about what they think of the PyCon sprints. I’ve found that most PyCon attendees are more than happy to talk about their perspective on the various parts of the conference they’ve partaken in.

If you can’t afford to stay for the sprints, I completely understand. Most PyCon attendees will not be staying for the sprints. But if you’re lucky enough to have the time and resources to stay, I’d suggest giving it a try.

If you can afford to schedule some extra time to attend a day or two of sprints and then decide that the sprints aren’t for you, that time could always be spent exploring the city you’re in, working, or doing something else that makes you feel whole.

And if you’re from an underrepresented or marginalized group in tech and you’re new to sprinting, consider applying for the mentored sprints for PyCon 2020.

Whatever you decide, have a lovely PyCon! 💖

Thanks to Asheesh Laroia for encouraging this post and Chalmer Lowe for quite a bit of helpful feedback while I was writing it. Thanks also to the many folks who sent me ideas and shared their perspective and advice about the sprints.