select links from 2025-10-19
I'm new and what is this?
Hi everyone!
Everyone is writing a substack these days so I thought I would make one too. But I have a good reason as well! Lately I’ve been running into so many great data resources, blog posts or anything data-adjacent that I now want a place to collect them (RIP Pocket). I found them useful and/or interesting. If you’re a data professional, chances are they’re useful to you too!
If all the world were a monorepo
Julie wrote a great blog post recently about R’s package ecosystem. Coming from R to Python was difficult because I myself was so used to the ecosystem and the comfort it provides for me as a user. If you’re not familliar with R, this is a fair explainer why some people LOVE R.
Configuration files are user interfaces
Configuration files are user interfaces | Adolfo Ochagavía
My current team has processes where the config is…a YAML file. So it’s great to see we’re not the only ones having a dilemma of how to write scalable configs. Luckily, we’re at a point where we append things to our config rather than change what’s present. This lets us have big config files without maintenance hassle.
Your Data Model is Your Destiny
Matt’s post about the importance of data models is a good reminder to think about your data architecture. The idea is that your data architecture reflects the way you perceive your business activities but it also frames how you operate your business. For example, Photoshop’s atomic unit is the .psd file while Figma’s atomic unit is a design object within the shared web canvas. If Adobe wanted to compete with Figma, they would have to abandon their file-centric data model. And we all know how data migrations can be hard!
I would love to talk specifics but all I can say is that I see comparable examples at my current workplace too. Examples where the previous data model is ingrained in the business mindset and moving to a new model is hard. Or examples where the atomic unit is not the one we ideally want, keeping the business ideas from leaving the whiteboard.
This is important to understand for data teams as well. We definitely had cases where our data model was not flexible enough to a point of abandoning the dashboard we’ve built. I don’t think you can build the perfect data model in advance - the business you’re in will change - but you can build with the intention of refactoring the model later. The idea that your code will be refactored in the future is a tough pill to swallow. But data teams that internalise this are at an advantage.