Side project advice

"I pointed out that for software engineers, the code is the product. For research, the results are the product, so there's a reason the code can be and often is messier. It's important to keep the goal in mind. I mentioned it might not be worth it to add type annotations, detailed docstrings, or whatever else would make the code "nice"."

"But the more you can make "nice" a habit, the less work it will be to do it as a matter of course. Even in a result-driven research environment, you'll be able to write code the way you want, or at least push back a little bit. Code usually lives longer than people expect, so the nicer you can make it, the better it will be."

Software engineering treats code as the product, while research treats results as the product, so research code often becomes messier. Keeping the project goal in mind helps decide where to invest effort in documentation, types, or tests. Making cleanliness a habit reduces future work and enables pushing for better practices even in result-driven environments. Side projects offer control over standards and goals, allowing some projects to be pristine and others informal. Different projects merit different workflows; examples include a rigorously tested library versus informal math art experiments. Side projects provide a low-risk place to practice styles and to forgive rewrites driven by perfectionism.

Read at Nedbatchelder