I'd actually argue it has some wicked problem characteristics. The input space is enormous (all possible audio), perception is subjective and nonlinear, and there's no objective function to optimize against, only "does this feel right?". Every solution you try reframes what "good" means. It's not as hard as social planning but is way harder than it sounds, no pun intended.
fta: The biggest unsolved problem is making it work well on all kinds of music.
The wickedness comes from wanting something that works just as well for John Summit as the Grateful Dead as Mozart and Bad Bunny.
But it seems like you could cheat for installations where the type of music is known and go from there. The other cheat is to have a "tap" button, and to pull that data and go from there.
mental note: the thought "it can't be that hard" when obviously it is sent me down a rabbit hole for a couple of hours
isn't it the exact same problem than "making a good movie" or "making a good book" ? this is just thoroughly subjective.
When the author says:
> Every commercial audio reactive LED strip I've seen does this badly. They use simple volume detection or naive FFTs and call it a day. They don't model human perception on either side, which is why they all look the same.
well no, if they sell, then they are doing just fine until someone comes up with the $next $thing
I didn't go into much detail about it but there's a whole rabbit hole of color theory and color models. For example, the spectrum effect assigns different colors to different frequency bins, but also adjusts the assignment over time to avoid a static looking effect. It does this by rotating a "color angle" kind of like the HSL model.
I really like your LED installation in Rosetta Hall, it looks beautiful!
what I meant with "DevOps won't want to support it" was someone saying this before DevOps had even been asked, and by someone who wasn't even on DevOps, who just assumed that they probably wouldn't like this sort of thing.
If this meeting doesn't include devs, I don't know what the context of anything in the article is supposed to be about. There are no major new ideas in business that don't involve software.
If it is not the case that "devs" is not functionally equivalent to saying "DevOps", then "DevOps" doesn't exist. You have an operations group, and you need their buy-in, so they should be invited to the meeting.
the "good for them personally" reaction is so true. It's almost like a team-level version of the inonvator's dilemma, where protecting the thing you already own feels more rational than supporting something that might replace it.
That's fair. The title is provocative and probably overstates my actual position, which as you note is closer to "the way people practice critique in meetings is low value and here's how to do it better". The point about making critical thinkers feel worse is taken too. The people I'm describing in the post aren't the careful, thoughtful critics, but instead the reflexive ones. I could have drawn that line more clearly.
I like that angle a lot, and this very thoughtful comment. Distinguishing between the idea and the person is a good way to think about it. I think sometimes people cross that line without realizing it. Your point about making sure people still want to bring ideas next time is really what it comes down to.
you're right that a good idea should be able to survive scrutiny. The issue I'm describing isn't "someone asked a tough question". It's when objections pile up so ast that nothing can survive long enough to be properly evaluated. That's not a rigorous process, that's just a kill zone. The difference between a productive and unproductive kill zone comes down to culture. Teams that default to "here's why it won't work" end up very efficient at producing nothing. The teams I've seen do this well still kill ideas but they just do it after giving them a fair shot. The proposer has to do their homework but the environment has to let them get far enough to do it.
Heilmeier Catechism is really interesting, thanks for linking that. I like how the questions break down different major aspects. It treats risk as one of the dimensions of evaluation but not entire conversation. That's the shift I was trying to describe. Critique is valuable as part of a complete picture, not when it is the only lens.
Thanks for posting this. I'm glad I'm not alone in the monorepo club! I really believe in the benefits. Especially for a personal monorepo where the amount of code is not usually enough to run into the limits of git.
I'm curious about your CLI tool, what do you use it for?
Ah I was hoping to get a discussion started but no one bit the bait, haha. But I'm glad you saw it so I can personally thank you for a thoughtful article! I like the "Dot a Day" idea too, and enjoyed seeing a glimpse of the workspace.
As for the CLI, it's a primitive script (was Bash, now TypeScript with Bun) that does a few common actions like scaffolding a new project with minimal base, some shortcuts for Git, SSH, taking notes. I really liked this part of the article too, aside from the monorepo idea, seeing how other people are making their own personalized CLI tools to manage projects. Like that ASCII art, the feeling I got was a mix of nostalgia and camaraderie.
