Reading and understanding code is a huge part of what we do as software developers. If we make it easier to understand our codebases, we make everyone more productive and help each other write fewer bugs. This is doubly important for an open-source project: the easier it is to understand your code, the less of a barrier you have for new contributors. That’s why Python now features *optional static types*, described in [PEP 484][1] and implemented with the [mypy type-checker][2]; why Dropbox has adopted static types on 750+ kLOC of its Python codebase and supports a full-time mypy core team; and why Zulip, an open source group chat project, [has adopted it][3] on 100% of its 90 kLOC Python codebase. Dropbox, Zulip, and others have found static types work for making code easier to understand and more fun and productive to work in. Adopting static types in your own code is easier than you might think: you can start on a small piece of a big codebase and start getting the benefits from the beginning. And it works great on Python 2.7 and 3.3+ — both Dropbox and Zulip were entirely on Python 2.7 when they started. In this talk, I’ll share lessons from Zulip’s and Dropbox’s experience — having led the mypy team at Dropbox and working now on the Zulip core team — for how you can start using static types in your own codebases, large or small. We’ll discuss how to make it a seamless part of your project’s tooling; what order to approach things in; and some powerful new tools that make it even easier today to add static types to your Python codebase than ever before. [1]: https://www.python.org/dev/peps/pep-0484/ [2]: https://github.com/python/mypy [3]: https://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/