An opinionated section

This section is for our python hot takes - things that we don’t consider strict guidelines but have strong/controversial thoughts on, feel free to ignore them.

• Any function that is used in an analysis that will end up being consumed externally (e.g. in a report), should have a unit test.
• We often use tools that are not really the best at what they do, but because “we’ve always used them”. Examples of this include conda (which we use in the cookiecutter but has much better alternatives), and pandas (which we use extensively but is comparably quite slow to similar packages). As a practice we could aim to be better at being innovative in our choices of tools.
• Using an IDE (VSCode) with lots of plug ins (e.g. from just highlighting spaces to code suggesting LLMs) will in the long run make you much faster at writing good code, compared to sticking to using something like vim/emacs/notepad++
• Most python ‘tips’ and ‘guidelines’ won’t really make your code run faster, but will make your code way easier to read/understand for others that also follow the same guidelines.
• A data science project doesn’t need to bottom out into a streamlit demo - there are many ways to showcase the outputs of data science methods, from blogs to a really nicely written codebase.
• [From a data scientist!] Although we often talk about interdisciplinary, across team working at Nesta, I think there is more we can do to optimise within our own team. We are not only data scientists - it’s therefore worth learning a thing or two from other DAP disciplines to better work with the whole practice. For example, learn how to deploy a docker container, use CPUs via metaflow or a bit of CSS to better customise your graphs. Picking up simple engineering skills beyond the scope of DS means that others will be grateful; you’ll learn something new; you won’t be your own bottleneck; and ultimately, you’ll have a much better sense of what other teams within DAP need