mastermedo

Thanks for pointing it out. TIL

Anticipate Change - Get Ready For The Cheese To Move

Monitor Change - Smell The Cheese Often So You Know When It Is Getting Old

Adapt To Change Quickly - The Quicker You Let Go Of Old Cheese, The Sooner You Can Enjoy New Cheese

Change - Move With The Cheese

Enjoy Change! - Savor The Adventure And Enjoy The Taste Of New Cheese!

Be Ready To Change Quickly And Enjoy It Again - They Keep Moving The Cheese.

Change Happens -- They Keep Moving The Cheese Anticipate Change -- Get Ready For The Cheese To Move Monitor Change -- Smell The Cheese Often So You Know When It Is Getting Old Adapt To Change Quickly -- The Quicker You Let Go Of Old Cheese, The Sooner You Can Enjoy New Cheese Change -- Move With The Cheese Enjoy Change! -- Savor The Adventure And Enjoy The Taste Of New Cheese! Be Ready To Change Quickly And Enjoy It Again -- They Keep Moving The Cheese.

The main problem is that when you’re comparing two products you’re bound to be comparing apples to oranges. Every product solves a slightly or majorly different challenge.

So when you run n tests on two different products some tests are bound to perform better on one product and some on the other. Misleading marketing comes into the picture if you only publish the ones that went your way or just partial results.

But that’s why if you believe in your own product and want benchmarks you hire a reputable third party to do them on their own accord.

- Oh, _gfuby_ can now monitor my instance in production in addition to being a code versioning system!?

That’s great. How often do you test it?

> I used to work as an alarm technician

Ok, that explains a lot.

> you can't really prevent the pros breaking in, getting what they came for and getting out. But you can prevent someone spending a long time inside the house looking for things to steal.

That’s the main use-case for such an alarm then.

I think organized criminals would call off an operation if circumstances they haven’t predicted occur. Especially those that significantly increase the time or reduce the chances the operation will be successful.

One thing is having the inside doors lock. Another is encountering an armed individual. Finding non-portable hard to open safes, etc.

But then again, it’s mostly better to diversify where you keep your belongings so you don’t end up a victim of organized crime in the first place.

But then again, one could have a short lasting warning siren, and then a full blast one when someone does break in.

Reading this post I was coming up with so many questions.

1. Shouldn’t there be a way for police to turn it off?

2. What are the legal consequences of the alarm accidentally firing and disturbing the neighbors at night?

3. Do sound alarms deter only small burglars?

Just a few weeks ago at work, one of the TLs told me I should ‘just do X’, and when I pushed back saying it’s going to take a few weeks, he said ‘oh it’s just a couple of lines, I can do it in 10 minutes’. I challenged that. 5 integrations and 2 weeks later we had a first working version, that caused more harm than good in the end because of an assumption that didn’t hold.

I think easy things might be easy in theory, but not necessarily in execution. So when a student comes to you, I suspect they have thought about theory, but find the execution hard because of the knowable unknowns they are not aware of and you are. Many times people don’t even propose things that might seem obvious to them out of fear they might say something stupid. Indicating something is easy in a demeaning fashion is bad. Phrasing it differently has a different effect. E.g. Oh, I think that might be solved with X. It should be relatively straightforward. Look at the work I did <here>, it should match your use case.

One thing that I would definitely change is getting stuck. There shouldn’t be a state that you can’t get out of.

What is the benefit here?

The biggest problem was when reviews took a while because people forgot to check MRs for replies if the MR wasn’t assigned to them. So we built a bot to ping them in slack and/or assign the MR to the person that needs to reply.

If the MR is to big we close the MR, and the initial dev has to split the changes up into multiple MRs.

Etc.

I’d say 99% of issues with code review is everyone not being on the same page about how MRs should be done, but once we sync on that, issues are scarce.

A true life changer.

On the point about drinking water, I bought a desktop water dispenser, much more convenient than having to refill the water bottle.

Instead of the rowing machine, I'm considering a barbell with weights.

On the multiple equipment point, I fully agree. I got myself multiple hubs, one for each desk. No more carrying cables!