I'm working through some thoughts in my head about social media, as I've been doing since founding this blog well over a decade ago. Back then I thought it was going to be a savior of democracy in oppressed societies around the world, and we see how that's turned out.
Lately it's an issue closer to home. My kids are creators. At some point years back they got inspired by Captain Underpants and started making their own comic books. We have bookshelves full of 8 inch sketch pads from AC Moore (RIP) and our middle son especially made visual art and story telling his thing. It's amazing to see how far he and they have come, especially with the story telling part.
In recent years, they've taken to making movies with iMovie and other tools like it with an iPad. They've started making animated movie shorts as well. None of this is the stuff they want to post on YouTube, but I know it's coming.
My middle son went and signed himself up a YouTube account. He's been posting content lately, mostly gameplay stuff from Minecraft. His brothers, of course, want their own YouTube accounts and so far I've said “no” without really understanding the why. Michelle hit on it the other day when she said to one of them “I don't want anyone telling you what you're worth” and I think that's it.
Especially when you're young, other people's opinions matter a lot. Social media is a wide open gate to put yourself out there and be judged in the form of likes and subscribes, and no matter what they think they will or won't care about, the human brain is wired to want to fit in with a community. The part that really bothers me WRT the boys is that the stuff that gets likes and subscribes is often the lowest common denominator and I don't want them molding their creativity around that. We've seen how that plays out.
“Run your data team like it's a product team” was a common refrain at the DBT conference for the last two years. What does that mean? I am still figuring that out, but I have had an aha in the last few weeks about what a “data product” is, exactly.
Your standard software development process requires two main components to deliver the Things – a software developer and her wits. She takes those wits and expresses them into a text editor, and thereby makes something from truly nothing.
Data products differ in 1 key way – they require raw materials in the form of data. The process of building a data product therefore requires at least 1 additional step that standard software product development does not – refining that data into something consumable by the system that is delivering the product.
There can potentially be an additional step even before this one, which is to get the data in the first place. My current employer built an Observability suite and stack to be able to deliver metrics to our customers about their projects that they run/host here. This process took multiple quarters because the entire metrics creation and delivery pipeline had to be built from scratch. Once the data existed, it was then a process of refining the materials and building the product.
The good news is that many data products can be consumed in a standard way through some kind of BI or reporting or data visualization tool, we use Metabase. It has taken me a while to understand that the method of delivery of the products is the more standardized part, whereas the gathering and refinement of the raw materials/data is where the action is.
Headed to dinner last night with the fam, this song comes on (Deep Waves I think?) and my oldest says “oh, this song”. Michelle, cutely, starts looking for something to like about it. I, predictably, do the opposite.
So here's the observation -
Basically all pop music these days is made exclusively on computers. Nothing wrong with that in and of itself, but what's missing is the accidental interactivity that happens when you have a group of people playing instruments and giving each other things to play off of. This, in my opinion, is partly why shit is so boring these days. Pull up a couple premade loops, add a bassline that's worked a hundred times for you before, add some trite lyrics and ship it. That's all that seems to get picked up these days, right?
The wonderful thing about playing music with people is that people are imperfect, and these imperfections are where the interesting bits come from. Everything out of a pop music computer is, by definition, predictable.
I was listening to Taylor Swift yesterday – Everything Has Changed from her new version of the album. There's this bit in the bridge at about 2:30 where the backgrounds do this “haaaa, ahhhh, ahhhh” thing that's so wonderfully out of tune and everybody involved in the making of this album had the courage to leave it.
Nobody does that anymore. I started thinking about how auto-tune has really enabled the elimination of musical talent as a condition for creating music, and made it that much easier to just create pure product with no musical value at all.
I am on my way to San Diego for the first Platformer meetup thing that I've been to since the Beforetimes, at least the first that's not just my team. On my way to San Diego I stopped by Austin for the FinOpsX conference, an amazing little thing put on by ... maybe the Linux Foundation through some other community community, idk.
Anyway, it was really amazing. Open source is just so much fun, I'm really glad that I found it all those years ago. This conference was smallish, like 400 people, but had all the open source vibes that the Drupal scene had back in the day, or the Python scene had the only time I dipped my toes in a few years back.
I'm really rather enjoying my gig these days after a long dark winter of feeling pretty hollowed out. Been doing some work and am feeling much healthier now. One of the lovely things about going to a conference or just getting outside your bubble in general is learning a little about how other companies operate.
See, here inside the bubble at Platform it seems sometimes like everything is going to take so long, and it's so difficult coordinating all these people and their worklives. Sometimes it's hard to see the bigger picture. One of my main takeaways is that we actually have our act together in many, many ways at Platform and one of the way in which I am most proud is in our data setup where pretty much everything we need is in a place where you can find it. Most companies don't even have this much.
I am about to fully inherit the FinOps function here when one of my people moves on to a new gig in a few weeks, and I'm mostly pretty excited about the opportunity to remake a little part of the world here that seems to cause a couple people some stress.
So yeah, somehow data and finance are the things that are interesting to me now.
Just thought I'd drop myself a line here and remind me about that time that I was getting FinOps certified, because it's so much more interesting than I would've thought.
Basically, back in the old days, there were data centers and if you wanted a new resource in one of those data centers you had to go through a procurement cycle involving finance and probably a procurement team. You'd buy the resource and that would count as Cap Ex in your P&L or whatever. It'd get installed and then you could use it. That Cap EX would be depreciated and the world would keep turning, pretty predictably, just like the Finance teams likes it.
This meant much longer planning and procurement loops for most technology teams, loops that are gone now in the era of “Cloud” and “devops” generally. This is mostly great. It also meant that the old methods of controlling costs are gone and that the ability to spend company money has been handed directly to development teams. This is potentially bad.
This should require much more feedback between the two teams – Eng and Finance – and much greater visibility into the company's resource usage for the Eng teams spending the money.
This is FinOps. A continual process of building, monitoring, and optimizing that allows companies to move SO much faster than they used to be able to.
This blog is interesting to myself because like I said in a recent-ish post – it really maps out a 12 year master Dunning Kruger cycle in technology, with baby Dunning Kruger journeys into different topic areas along the way. Early in this blog I had so much to say. Later in this blog I am aware of how much I don't know. The post frequency maps almost exactly with this chart that I recently took a look at again:
I don't know, this just came to me. For several months now I've been trying to make some changes to old behaviors. One of them is a lack of communicating, of building up a thing or a plan in my head without talking it over with the people whom it affects.
I've summarized this as something like
When I have a good idea – when I see the path – I assume everyone sees it too.
So I've been making more of an effort to communicate everything in the last few months, whether it's the Big Idea that I have at work or the difficult conversation that I don't want to have with this coworker.
It just popped in my head a second ago that part of the reason that people don't see The Path is that it's not their path. They have their own paths they're moving down. It's my job to explain my path to them as soon and as often as possible, especially if I need their help getting down it.
My wife is a Glennon Doyle podcast listener, and on a recent trip she put her on for a little while. Plenty of good stuff, but the phrase that's stuck in my head right now is
The intention doesn't matter. What matters is the impact.
One expression of micromanagement is the inability to sit and let your teammates (possibly) make a mistake on their own. The way I caught myself doing this just now was an innocent question being asked between two teammates for which I knew the answer. I am also on vacation, so I shouldn't be there. They were talking it out and I jumped in and answered it.
Implicit in this action was that I didn't trust them to figure it out correctly for themselves. It's not that I didn't trust them, but it probably comes across that way and what matters is not my intention but the impact. I'm potentially stunting the ability of this team to think on their own and that is something I am totally grossed out by.
“Data modeling” is a kind of nebulous concept, but I define it loosely as
The empathetic act of thinking ahead about how somebody might actually use this data that you're creating or storing.
It turns out to be a skill that not everyone possess, and which a previous career stint as a web developer served me well. I think for the next technical interview I give, regardless of position, I will ask the candidate to explain how a simple blog data model works. A data model like this one...
