I have a bit of a cold start problem when it comes to new projects.

Modern coding projects have an intimidating list of requirements needed to bring your project to passable quality at any major software outfit. Theres linting, of course, and unit/integration tests. And proper logging. Don’t forget about continuous integration workflows. Matrix Testing. We also know that only a slob would think to leave out dynamic configuration. You don’t have good docs? pathetic. Don’t tell me you’re using your system python interpreter to run your code 🤮. Ok I’ll stop there (and we haven’t even gotten started on IDE config). The point is that each of those things is actually useful for writing quality/predictable code and the longer you wait to implement something like linting or create a virtual env, the more entropy your project accumulates. Prevention is the best medicine.

In my, unplanned sabbatical, I’ve started a number of python projects to test out new concepts or ML tools. I have been continuously annoyed at the seemingly unending boilerplate that comes with new projects and decided there had to be a meta-coding/scripting technique that gets rid of most of this problem for coders outside of large companies. As luck would have it, I was not wrong.

Cookiecutter is one such tool that’s been fairly popular in the python community. It’s a dead/simple interface to set up:

• You define a JSON file with a list of variables you’d like to ask the project creator to define at the outset (Think project name, targeted python versions)
• You set up a generic project. You can do this once by setting up a project as you normally would with manual steps
• You this project by inserting the “{{ cookiecutter variables }}” you want to replace throughout your generic project. See example here

This is essentially infrastructure-as-code for your local development. It can get rid of almost all of the undifferentiated work associated with a new project, and more importantly lives as crystallized example of your teams coding practices. New team members can see your linting rules, logging styles, have their IDE set up for them automatically and your repositories will be protected with tools like pre-commit hooks and CI/CD verifications.

I’ve linked my template above which is a fork of a fork. It has some specific upgrades around conda, git handling, logging and linting. I’m hoping cookie cutter continues to be improved upon, as some of it’s issues seem a bit long-in-the-tooth. If not, there are newer alternatives on the block such as Copier and Yeoman. These should all be language-agnostic, since they are essentially mad-libs for software engineering. I’d imagine most companies have an opinionated alternative for projects internally, though an informal poll of my SDE friends indicates they aren’t that frequently used for personal projects. If that includes you, I’d recommend you give my template a try. It dramatically lowers the cognitive load of tinkering and creates mechanisms to nudge you to best practices from day one.