• 21 Posts
  • 2.92K Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle
  • I’ve done it quietly 4y ago, only told some closer relatives. It was kind of funny when relatives I wasn’t talking to told my closer ones that we were keeping in touch on WhatsApp, not even aware I wasn’t in the platform for over 6 months at that point.

    Now after years and leaving 2 family groups, politics, and a whole lot of drama behind, I feel it was a great decision, and the only regret was not doing it earlier.





  • The way I see it, for any code review there are going to be different levels of recommendation regarding the comments. When I review, I try to make it clear what’s optional (/ nitpick) and what I’d really like to see fixed before I can approve it.

    So even making some assumptions, I can’t choose between 4 and 5 because optional and “less optional” changes are often in a same PR.

    The only one I haven’t done much of is #3. That one looks better if one has questions about code that was already reviewed, merged, and it’s likely in production.


  • As with a lot of things in life, it depends.

    I use 1-5 depending on the repo, who made the change, what the change is about, and how involved I am in the project.

    Though the “time-frame” idea of #4 is usually replaced by conversations if it’s a coworker, as it’s more effective.

    Q: about #3, do you mean on code that is already merged / committed to the default branch?







  • You don’t need that assumption. Your assumption can just be “the person and vessel (or a point in the vessel, like its center of mass) don’t diverge significantly over time”.

    Then, if you treat velocity as a vector and compute the person’s average velocity vector over time, you’ll have a pretty close estimation to the vessel’s velocity vector.

    After all, if those two average vectors (vessel’s and person’s) were to differ much, they would end up in different locations.

    The average basically zeroes the vector for each lap the person does, so the remainder must be the vessel’s.




  • Ok, I’m not suggesting replacing humans with AI and I despise companies trying to do this unsustainable practice.

    With that out of the way, I’ll restate that LLMs follow some rules more reliably than humans today. It’s also easier to give feedback when you don’t have to worry about coming across as a pedantic prick for pointing out the smaller things.

    On your point that LLMs are not improving; well, agents and tooling are definitely improving. 6 months ago I would need to babysit an agent to implement a moderately complex feature that touches a handful of files. Nowadays, not as much. It might get some things wrong, but usually because it lacks context rather than ability. They can write tests, run them, and iterate until it passes, then I can just look at the diff to make sure the tests and solution makes sense. Again, something that would fail to yield decent results just in the last year.