Re: naming things

Not sure if I mentioned this in the last post, but what I’m doing right now is essentially building a data warehouse for my employer. It’s from scratch, there was effectively nothing here beforehand, so I get get to/have had to chose everything from the tech stack to the processes to my favorite part of late: naming things.

The name you give to a piece of software, or a command line flag, or a column in a database is an act of asynchronous communication with another human. You are asking them to care about the thing you’ve built. If they chose to work with your tool, you are asking them to understand the choices that you made in its design.

The most selfless thing you can do is think about how much effort it takes for the user who did not design the thing to understand how to use the thing. Name things according to what they are and what they do, make it intuitive. This is what design is. It’s not the parts that most people will never see, it’s the parts that most people will only see.

Where this fits into a FinOps context - and I've probably written about this here before because it's not a new concept to me - is that huge part of the early job of FinOps is taking AWS's terminology and vocabulary and translating it into that of your company. This is how you get engineers to pay attention to costs, by making it easier for them.

All those tags you have on all those resources - make it easy to query them by hoisting the important ones out to their own column. Make the default view of the billing data do this automatically, create a SQL view that performs this drudgery. Are there inconsistencies in the data, different spellings of what should be the same segment of data? Normalize them in that SQL view. This all makes it easier for the person after you to hunt down 1 name, rather than 3 or 300.

The more care you take in naming these constructs that you're unearthing, the more immediately effective they'll be to the person you ultimately want to engage with them.