* Write tests and run then on CI. Try to figure out how to write tests with a least amount of pain - you'll need lots of them. Use py.test or a similar framewor

* Write tests and run then on CI. Try to figure out how to write tests with a least amount of pain - you'll need lots of them. Use py.test or a similar framework. Doctests are great, but it takes some time to learn how to use them efficiently and when they're not appropriate. * Measure test coverage to be aware of what is not tested, but don't just pursue exact coverage % number - doing that leads to many integration tests and a few unit tests. Both kind of tests is important. * Extract libraries from the main code, to make the main project smaller; write docs and tests for these libraries. Docs are important for these libraries. Try hard to maintain boundaries - a library should have a single purpose, and it shouldn't be tied to the rest of the code. If you find writing docs complicated them maybe the library does too much, or maybe its API is too hard to use. Fix that. * Don't write all code yourselves, consider using open-source libraries. But don't use open-source libraries if you're not comfortable with contributing to them - there will be issues (like in any code). If the library you're going to use is not an industry standard read its source; if it is "ah, yeah, this is almost how I'd written that" use it, try to find another library or write your own otherwise. I'd say the trick to handle large Python projects is to resist making them large. Don't be sloppy in code organization, be pedantic about which part "knows" about which part, extract non-specific utilities to libraries. Often projects can be kept under 20-50K lines of code after a few years of development by a small team if a team tries to maintain code quality and moves non-specific features to external libraries. flake8 and alike linters may help with consistency; it is important, but not the main problems by far. The main problem to fight is non-locality: if one can reason about a piece of code just by looking at it, without checking lots of other components, the overall project size doesn't matter much.