I’m sorry that you find yourself in an environment where you struggle to freely be yourself. I can strongly relate to this. I feel like I have to be constantly on guard and protect myself from people and it’s a shitty way to live.

Standing up for yourself often feels uncomfortable in the moment, but you are very likely to regret not doing it. Whichever of the various tricks in the comments you feel comfortable trying or have hope will help, go for it.

Yes.

Yes, but “GIF” is not etymologically Germanic. 😉

The people already with the money have orders of magnitude more freedom on average to decide and pursue opportunities.

Free market inventions do not guarantee persistent and open access.

Espresso in the morning. Cappuccino after meal. It’s been at least ten years.

I think MIT Open Courseware would be worth exploring.

Some people learn about the limits of their control over events by meditating. Even when you stop trying to do anything, your body tries to do things and things change around you and you have the impulse to control things. Repeated exposure to this impulse eventually caused me to start laughing at how silly I was to assume that I was in control.

Maybe something like that could help you. Peace.

Very specifically for me, two parts of Getting Things Done:

• get things out of your head
• always set reminders

I have felt so much lighter for over 15 years because I can safely forget all these things I used to struggle to remember so that they wouldn’t sneak up on me.

Getting things out of my head was easier to build as a habit at the dawn of having a computer in my pocket all day. Even back then, I simply chose to be an asshole for a few months, stopping everything to write things down or to do them on the spot if they truly took only 2 minutes. Especially taking photos of receipts and labeling them when traveling for business.

Setting reminders was similar, but rockier, since calendar apps sometimes have defects. I gradually learned which alarms to trust and learned to use those more often. Even so, Samsung Clock has at least once surprised me by setting my alarm volume to 0, causing me to miss one alarm in the last 10 years.

In both cases, I did nothing special except decide to build the habit and spend the effort to ingrain the habit through repetition over the span of a few months.

2010

A group of people who are tired of your unjust bullshit, who are not going to let you shrug it off or get away with it, and who are not going to stop confronting you with it.

Yes. I find it helpful.

Space Invaders.

I don’t think I’ll forget.

This is true Customer empathy.

Yes, any programmer who doesn’t care will do damage, but when I see durationInMilliseconds, I think more about what the int means than when I see merely “duration”. I don’t know how to help the people who read that and ignore it.

The story of the 125 mph knuckleball might help.

Indeed, this is a time for naming conventions that communicate the details that the type system can’t clarify. This leads to the long names that senior programmers make fun of. Don’t listen to them; let them laugh then make this kind of mistake.

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…