dgunay
Joined 5 years ago
Joined 5 years ago
EDIT: I want to make it clear that 1) I'm not talking about the driving upside down thing, and 2) just because I am not sensationalizing the kickflip trick as some incredibly complex endeavor doesn't mean I didn't think it was cool and I'm some kind of hollow, depressed sad sack. The kick flip made me laugh my ass off, but be real. His companies make rockets that can belly flop and land themselves, stream hi res video of reentry using LEO satellite constellations, catch huge boosters in towers, and this is what's blowing your mind?
Having to read notes that are up in the ledger lines outside the clef kind of sucks. You just have fewer visual landmarks to hang off of.
This is partly a consequence of the physical instruments we have and their natural ranges, but clefs as a general concept are annoying to deal with when you have to juggle them constantly.
IMO it doesn't do a good job of communicating dynamics and expression. The notation used is vague (accelerando... okay how much faster, over how many measures, etc).
Maybe I'm holding it wrong, but recently I transcribed some of my friend's songs and managing repeats that don't neatly fit into a rigid song structure is difficult without writing very "WET" music that takes up a lot of space.
In a more meta sense, most sheet music is garbage. There is no inherent pit of success when it comes to creating sheet music, and writing a very good, readable score is something only well-trained musicians and composers can do. Look at free sheet music or read notation written by amateurs, you'll see missing key signatures, misspelled chords, etc. Sheet music doesn't make any concessions for people who understand music as sound first, you have to adhere to tradition and theory to produce good sheet music. Lots of musicians with decent ears cannot do this.
IDK, this is me trying very hard to come up with reasons to hate on sheet music.
I'm looking at what we can do to alleviate this. Here's what I think the near future may look like, as far as getting more value per time spent out of human code review. I'm coming at this from the POV of an org that still mandates human code review and I think a lot of this advice doesn't hold if you are all-in on the black box software factory approach.
If you're reviewing code you're responsible for, your job now is to provide stewardship of its long term technical direction even if you are not personally reading and writing every line of code. This means preserving the coherence of designs past and present, and ensuring that they are not being worked around in service of a short-term goal.
Stop reading every line of every file to look for minor gotchas. Focus on core business logic and whether invariants are modeled well & to the fullest extent possible by the type system. Agents are better than most humans now at spotting insane gotchas. At least one frontier model should review most PRs.
In the before times, you could argue that TODO comments and small nits on PRs should be addressed, because most likely they'd never get attention again once the PR merges. Now, small issues should instead be automatically recorded and followed up on quickly by another agent. Minor code quality issues should become rules, and old code should be constantly revisited by agents to bring it up to par with new code.
Provide the transcripts of the session with the PR. Look for evidence of thoughtful direction & solid premise behind the conversation that led to the PR being made. In addition to providing more mentorship opportunities to the author, this also discourages meat proxying/low-value-added uses of AI. Asking someone to rewrite or completely discard a PR that's just a bad idea should no longer be the ego bruising event it once was (at least with respect to the cost sunk to make the PR).
Require a higher bar for proving that code works and stays working. The testing pyramid IMO should now be more of a testing hourglass. Or an upside-down pyramid, even. Automated E2E tests should be abundant. Every feature should receive adequate manual testing by an agent, with proof of work.
In the vein of "stays working," look for good observability and guardrails around a feature. If you're doing a good job of leveraging agents to keep code up to par, this means adding (and cycling out) feature flags, ensuring that there's adequate logging, having a cohesive monitoring solution with good coverage, and a plan for what to do if there's an issue in prod.
1. I ask it to list out all my old Keep notes that are just throwaway task lists, reminders, etc. to propose deleting them.
2. It comes up with like 4 of them (I know for a fact there are dozens, if not hundreds). I ask it for an exhaustive list.
3. I see its thinking trace briefly show "Refusing to produce an exhaustive list..." and then it says "Yes, that is all of them."
Not sure whether it's lack of intelligence, bad tools, or both, but that was extremely frustrating to see.
I know this analogy breaks down a little bit since this behavior does actually happen, sort of, in real life p2p markets but the point is, it sucks and if you've ever sold anything on fb marketplace you know how obnoxious it is dealing with people who demand a lot of you but do not intend to actually commit to buying what you're selling.