• 0 Posts
  • 65 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle



  • I think you’re using the word “work” here to mean what I’m intentionally calling “job”. Maybe not, but if you are, then I agree with you.

    Most people want to produce things of value (for some personally held meaning of value) and to do things that matter to others or to be of service. It’s this sense of “work” that I mean. If we stripped away all the conditioning that I infer you mean, I believe this sense of wanting to work would remain for those who aren’t already burned out or depressed.

    But yes, there is certainly some religious and irreligious indoctrination to believe in toil as a virtue. I don’t buy it.




  • I was tired of Windows, so I tried Linux for a month, then switched to Mac OS for a decade.

    When Mac OS started to become iOS, I started leaning towards Linux.

    When my MacBook keyboard caps started falling off and Apple told me to replace the entire keyboard, I left them indefinitely.

    And now I’ve been here for a few years. So far, so good.









  • Yikes! That’s also a great cautionary tale for Primitive Obsession/Whole Value as well as a bunch of other design principles.

    I’m thinking about how I’d have done that refactoring and now I wish I had the code base to try it on. It sounds like it would make a really good real-life exercise in a workshop. “Remember folks, you have to get this right. There’s not really a way to check this with the real hardware, and if you get it wrong, someone’s going to get hurt.”

    Thanks again.


  • Wow. I love that story and I’m glad nobody was hurt.

    I wonder whether that happened as a result of unexpected behavior by the pitching machine or an incorrect assumption about the pitching machine in that coworker’s tests.

    I find this story compelling because it illustrates the points about managing risk and the limits of testing, but it doesn’t sound like the typical story that’s obviously hyperbole and could never happen to me.

    Thank you for sharing it.


  • This seems to happen quite often when programmers try to save time when writing tests, instead of writing very simple tests and allowing the duplication to accumulate before removing it. I understand how they feel: they see the pattern and want to skip the boring parts.

    No worries. If you skip the boring parts, then much of the time you’ll be less bored, but sometimes this will happen. If you want to avoid this, then you’ll have to accept some boredom then refactor the tests later. Maybe never, if your pattern ends up with only two or three instances. If you want to know which path is shorter before you start, then so would I. I can sometimes guess correctly. I mostly never know, because I pick one path and stick with it, so I can never compare.

    This also tends to happen when the code they’re testing has painful hardwired dependencies on expensive external resources. The “bug” in the test is a symptom of the design of the production code. Yay! You learned something! Time to roll up your sleeves and start breaking things apart… assuming that you need to change it at all. Worst case, leave a warning for the next person.

    If you’d like a simple rule to follow, here’s one: no branching in your tests. If you think you want a branch, then split the tests into two or more tests, then write them individually, then maybe refactor to remove the duplication. It’s not a perfect rule, but it’ll take you far…