Frictionless Standards; How To Have Better 1:1's; Fagan Finder
Remember: this is installment one of two, today.
Frictionless is an open-source toolkit that "brings simplicity to the data experience - whether you're wrangling a CSV or engineering complex pipelines." I'll likely cover the entire toolkit at some point, but today I'd like to introduce their Frictionless Standards, which is the foundation for said toolkit.
The standards are a set of [design] patterns for describing data including:
Table Schema🔗 (for tables): a simple language- and implementation-agnostic way to declare a schema for tabular data. Table Schema is well suited for use cases around handling and validating tabular data in text formats such as CSV, but its utility extends well beyond this core usage, towards a range of applications where data benefits from a portable schema format.
Data Resource🔗 (for files): a format that describes a data resource such as an individual file or table. The essence of a Data Resource is a locator for the data it describes, and a range of other properties can be declared to provide a richer set of metadata.
Data Package🔗 (for datasets): a simple container format for describing a coherent collection of data in a single 'package'. It provides the basis for convenient delivery, installation and management of datasets. A Data Package consists of metadata that describes the structure and contents of the package, and resources such as data files that form the contents of the package.
I always struggle against putting "boxes" around what I do (which may explain the "
Untitled 47" tab I inevitably end up with in RStudio/VS Code at the end of the week). For casual work, this is likely "OK", but when I get involved in something bigger than a breadbox, structure should be one of the goals, since without it, chaos is usually the outcome.
Most everything in modern work revolves/centers around "data", and I believe having a structured approach in defining, packaging, and accessing data can be a force multiplier for teams and organizations.
The design philosophy behind the Frictionless Standards is both brief and (IMO) sound:
Seek zen-like simplicity in which there is nothing to add and nothing to take away.
Design for extensibility and customization. This makes hard things possible and permits future evolution – nothing we build will be perfect.
Specifications should preserve human readability and editability whilst making machine-use easy.
Reuse, and build on existing standards and formats.
A broad range of languages, technologies and infrastructures should be supported to avoid being tied to any one specific system.
The last bullet is what sold me on trying to adopt this "Frictionless" mindset: I despise vendor/ecosystem lock-in and having standards that can be applied across ecosystems makes easier for me to invest time and energy into learning and adopting them.
The specs are a quick read, and they have examples (which I found helpful in fully groking their philosophy). They also have links to tool implementations across many languages and environments.
How To Have Better 1:1's
My hope for you, dear reader, is that — unless you're a 1-person consulting company (since it'd be kinda weird for you to talk to yourself) — is that you already have outstanding 1:1's with your manager, and also have outstanding 1:1's with any direct reports you may have. Unfortunately, it is far more likely that your manager 1:1's aren't ideal (if they happen at all), and that you may struggle with those you have with your direct reports.
Organizations of all shapes and sizes, from startups to 200 year old institutions, generally do a poor job at providing solid guidance for managers and directors on how to do most things, let alone have meaningful 1:1's.
This newsletter cannot solve the entire 1:1 challenge (at least not in one edition), but I came across this [crowdsourced] list of 1:1 meeting questions which may help you steer existing less-than-stellar ones into a better direction.
There are definitely some engagement statements (they aren't all "questions", per se) I'd never use, like "Hey, what’s going on?" (your time and career are much more valuable for such an opener), but most are decent-to-great, and it can be helpful to have a list of prompts to ensure you aren't forgetting some key topics to cover.
One nit I have is that the list is presented in more of a "manager asking direct report" style, but — as I've been reminded of all too well lately — you are ultimately the one in charge of your career, so there's nothing stopping you from making a version of those questions to take to your manager (or their manager, depending on the situation you're in and what you want to discuss).
A word of caution: many of the questions/engagement statements assume a certain level of trust, safety, and openness within an organization. You may not be in such a situation, and getting asked "Are you happy here? What makes you say that?" in such an environment may make it hard or impossible to be honest. In fact, I'd go so far as to suggest reviewing the list and asking yourself "Would I feel safe discussing this?". If the answer is not "Yes" to a decent chunk of the list, it might be time to reflect on if that perception is real (sometimes we're our own worst enemy when it comes to trust). If it is, it might be a sign that you may need a bigger change than just a new project or promotion.
This is a quick one, but it's a go-to tool in my daily arsenal for finding things.
Fagan Finder is "a collection of tools to, maintained by Michael Fagan (@faganfinder) help you find anything online."
It launched way back in 2001 and still going strong.
You may ask "Why not just use Google?", and Michael has some answers for that:
You may not find what you want on Google because:
it’s in Google but you don’t know what to search for
it’s in Google but is not listed high enough
it’s not in Google because Google has not found it yet
it’s not in Google because Google did not think it was important enough to include
it’s not in Google because the site refuses to be listed
it’s not in Google because you must log in to access it
it’s not in Google because you must pay to access it
it’s not in Google because it is not published in a way that Google can access it
it’s not online
That's a wrap for
.01! I hope the resources are interesting/useful for folks. See you in