It depends on your workflow. I'd say your approach is interesting, but it's mostly driven by availability of the data ("searching under a streetlight") except for your sleep monitor (however, being an under pillow solution, it's not essentially different from the accelerometer data from a smart watch)
I would suggest you invert the logic: design objective (ex: mental acuity), conclude on what things you want to track (ex: time slept, cups of coffee per day, time you drink it, errors in shell) and get the data accordingly, spending as necessary (ex: smart coffee maker? or maybe a smart plug that can let you infer when the machine is being used from the wattage drawn)
As for data tricks, L distance is a good one, yet not applicable for shell, as it's sensitive to the string length so you would need correction. Also, it's missing the essential metric: did the command work? Only the error return code will give you that.
TLDR: think about what you want, but before that think about why you want it. Collecting useless metrics is another form of data hoarding.
Yeah, it's a good point, and I'm indeed a bit guilty of hoarding data I can't immediately process.
However, the problem with the 'objective first' approach is that it's gonna require a lot of data to draw meaningful rigorous conclusions from small interventions, so I'm making sure to 'secure' the data first, and then gradually process it.
But also, it's a challenge in itself -- I'm automating a lot, sharing my system and trying to interoperate with existing tools, in the hope that my work can be useful to other people and make quantified self easier for them.
I would suggest you invert the logic: design objective (ex: mental acuity), conclude on what things you want to track (ex: time slept, cups of coffee per day, time you drink it, errors in shell) and get the data accordingly, spending as necessary (ex: smart coffee maker? or maybe a smart plug that can let you infer when the machine is being used from the wattage drawn)
As for data tricks, L distance is a good one, yet not applicable for shell, as it's sensitive to the string length so you would need correction. Also, it's missing the essential metric: did the command work? Only the error return code will give you that.
TLDR: think about what you want, but before that think about why you want it. Collecting useless metrics is another form of data hoarding.