Articles / Things I'm sharing!

2025-10-28

• Blog Feeds

  I definitely have to set up my RSS and Feeds page. Those are at the top of the Site Improvements list!

• Making liquid nitrogen from scratch (an absurd amount)

  Honestly, this is probably the one NileRed video I've seen where I went ... Maybe I could do this.

  Side note: Anyone wanna get his chemistry kit? Talk to me in real life, if so.

• We're in the Wrong Moment

• 🔥 Recall for Linux

• Amiga prototype "Lorraine" at the Amiga 40

  Wow! This is so cool! This computer is made on a breadboard. I remember in my ill-fated EE career (I got a Msc and that's just about it), how ... finicky this was. Granted, I was never really good at the physical hardware. Nonetheless, I think my EE experience makes this particularly impressive to me.

• Mistakes I see engineers making in their code reviews

  Some thoughts:

  Don't just review the diff

  Excellent point that I take into work every day. As I review, I ask myself "am I just reviewing the diff? Am I missing something?".

  Don't leave too many comments

  I think he burys the lede here actually which is "it's very hard to engage with that review on anything other than a trivial level". IMO, if you have 20 comments of the same complexity, most engineers manage this fine. But if you have 10 style comments, 9 refactor suggestions and 1 actual blocking issue, that last one is sure to be lost.

  So I think this should be reconstructed as two points:

  Make sure your review doesn't get lost:

  Make sure each comment is of a similar "weight".

  Be aware of the MR assignee's exhaustion:

  Multiple rounds of review can be very exhausting. Actually I would say you should never really do a third round of reviews.

  If you do not want a change to be merged, leave a blocking review

  This is very surprising to me that this needs to be said.

  Most reviews should be approvals

  I totally disagree, but maybe it is because I haven't worked in this inter-team context being described in the article, where the teams' incentives are not aligned.

  But within a team? I don't think the situation in the article necessarily applies.

  I also don't really understand their "N+1" example ... that is something that should be blocking. If you spot that, why would you ever let that into production? N+1 can be really, really expensive, basically immediately in production, though it might not look that way on staging / local.