• 0 Posts
  • 47 Comments
Joined 1 month ago
cake
Cake day: February 22nd, 2026

help-circle








  • Ok clearly it’s not literally about making CDs and people saying “just make your own streaming service” are both missing the point and vastly over estimating the capacity of the average person.

    The important part that’s largely missing from today’s music environment is the personal touch and investment. Many people, as the author says, just comfortably coast through an algorithmic smoothie of familiar music. That is inferior to a friend saying “I made you this mix” and then you actually listen to it, attentively, more than once.

    It doesn’t have to be a CD. It can be a zip file. But the intention and focus was important.

    I’m an outlier in that I never let “the algorithm” choose what plays. Sometimes I still make mixes for friends, though lately they’ve just been a collection of links. That process of choosing is meaningful. My friend still listens to the mix I made for them when their job laid them off, sometimes.


  • All code going to the main branch must have a corresponding pull request reviewed and approved by someone with knowledge of the codebase. You really shouldn’t have the front end guy approving backend code.

    Ai doesn’t count as a code review.

    At my previous job, the policy also said you were supposed to actually check out the code and run it locally. Found a lot of bugs and issues that way.

    At my current job, it’s often a rubber stamp. I’ve seen things like “that’s too many parenthesis. This won’t run” sail through. This is bad.

    There should also be automated tests and checks.

    A long time ago a director told me “software engineers are the most sensitive people on the planet” and I think he was right. Some people just can’t take feedback. They take something like “please sort your imports. We agreed to use isort last week” as a personal attack.




  • I think it’s like that dunning-kruger idea. People who are bad at things don’t know they’re bad, and are poor judges of quality.

    So someone who’s kind of bad at coding isn’t going to know or understand what the LLM puts out, so they won’t fix as many issues.

    Also humans are lazy, and when presented with something that looks good at a glance, we don’t really want to dive deeper.

    I saw a PR from someone today at work. Guy’s nice but I don’t think he’s much of a programmer. He asked copilot to fix a warning. It did, and generated a linter error. So he asked it to fix that. It did, but for whatever reason decided to delete an entire function call.

    Unfortunately that part of the code has no unit tests, so he just pushed it up for review. I look at it and I’m like if that call is important, don’t delete it. If it can be deleted, remove the now-unused code around it. We’ll see what he says.

    He probably spent more time fussing with copilot than it would have taken to do it right in the first place.