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...
I caught this thought train last night and hopped off before writing it down. It has to do with the visible trappings of success. First the obvious bits.
True success isn't something that someone gives you. It's not something that you get. It's not a thing. It's a feeling. I am currently riding the wave of it for maybe the first time ever. I am doing my best work. This post, written over a decade ago – I'm finally there. It may not last, and I'm ok with that. I'm grateful for it now.
Thing is, for a long time up to sometime in the last handful of months I thought about the visible trappings of success – title, how many people report to me – they took up mental space. I think because I've always kind of had self-confidence issues and those things function as kind of a buoy or channel marker for me to know that yes, in fact, I'm headed in the right direction according to societal norms. They boosted my confidence in a fleeting but still meaningful way, because eventually the flywheel is spinning on its own and I realize I'm not thinking about any of that shit anymore. I mean, I need more reports because I need more brains and hands to execute on the job now, and not because I care how many reports I have.
This is one of those thoughts that's buried under a lot of muck and I don't really understand it much more clearly than I've attempted to lay out here. It's sort of like when a coworker recently asked me “did I just make a mistake by turning down the unexpected opportunity to have more folks reporting to me?” and my first reaction was something like “don't optimize the wrong metric” but that's a bit overly simplistic.
Whatever you need to help you feel successful is helpful to get you to the place of being successful, as long as you don't confuse it with success itself. It's like career therapy for middle aged white guys.
Not sure if I mentioned this in the last post, but what I'm doing right now is essentially building a data warehouse for the company. It's from scratch, there was 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.
