Many folks I interview write scripts for things like notebooks and not frameworks or tooling to do deeper data processing. 2/2

I've seen folks who have non programming backgrounds start diving into data tooling and it can be very daunting. It's relatively straightforward to use many libraries in Python without knowing the ins and outs of more advanced coding. 1/2

Not considering data quality and trying to fix it before using it.

Case in point, spreadsheets and SQL. They have a lot of capabilities far beyond their original intent. Yes, they are great for testing things out or smaller use-cases, but are they the best tool for your environment with that functionality? 2/ #databs

It's always good to show that fancy tools aren't required to get the fundamentals taken care of. They may make it easier to monitor but starting with a doc with an outline like this is worth a ton.

The read 📖 that caused this stitch: open.substack.com/pub/dataprod...

Happy to share and enjoyed the conversation :)

CI/CD with data is a fun one for sure!

Not everyone is on Bluesky, so shoutout to @opendataalex.bsky.social for one of my absolute favourite interviews that's full of humour and hard-won insights:

www.datafold.com/data-migrati...

Many companies stick with older tech because it's the skill set they have in house and/or it is legacy enough that switching over is scary/dangerous. 2/2

Oh I assure you, there's a reason companies make those switches. It usually ends up being money savings (which in the short term just ends up vanishing because of the cost of switching over but can save in the long term), internal politics, or kickbacks. 1/2

It's good to come in with fresh ideas but take time to observe not just the technology, but the people. Learning how folks interact with each other is just as important as showing how you can help improve things. General rule of thumb: observe and absorb for two weeks then hit the ground running.