The most reliable test I found, and by accident, was fighting bots on a certain Quake 3 map
For me, it’s playing a TF2 Scout on a well-populated server running a Scout-friendly map. A kill/death ratio of 3:1 or greater means that I’m sharp, 2:1 is okay, and 1:1 or lower means that I’m sluggish.
However, in my case, using a game (especially a twitch-aim FPS) as a performance test defeats the purpose of testing because it primes me away from the task I’ve planned for the day and considerably shortens my attention span, so I never play anything before work.
How do you test yourself?
I think the best test is the task itself. Instead of testing, I just take a stab at the planned task. When I feel that I’m not performing well (I usually can tell that fairly quickly), I try to downshift to a less demanding subtask within the same task (to keep the priming advantage) and see how well I perform there. Quite a few times I manage to get into “the zone” and upshift back to the original task.
In general, my approach to bad days is not “how do I test if I have a bad day?” but “how do I squeeze the maximum progress out of a bad day?” The approach boils down to a series of downshifts to less demanding but still useful tasks. My typical bad day looks like this: thinking about the #1 item on my todo list, feeling dumb, discussing small problems (e.g. minor GUI tweaks) with the programmers, feeling dumb again, and ending up with declaring an Errand Day (mostly reacting to email).
(What I described above is a “good bad day”. A “bad bad day” is when I slide into procrastination at the start of a day and remain useless for the rest of it—which, thankfully, doesn’t happen that often.)
For me, it’s playing a TF2 Scout on a well-populated server running a Scout-friendly map. A kill/death ratio of 3:1 or greater means that I’m sharp, 2:1 is okay, and 1:1 or lower means that I’m sluggish.
However, in my case, using a game (especially a twitch-aim FPS) as a performance test defeats the purpose of testing because it primes me away from the task I’ve planned for the day and considerably shortens my attention span, so I never play anything before work.
I think the best test is the task itself. Instead of testing, I just take a stab at the planned task. When I feel that I’m not performing well (I usually can tell that fairly quickly), I try to downshift to a less demanding subtask within the same task (to keep the priming advantage) and see how well I perform there. Quite a few times I manage to get into “the zone” and upshift back to the original task.
In general, my approach to bad days is not “how do I test if I have a bad day?” but “how do I squeeze the maximum progress out of a bad day?” The approach boils down to a series of downshifts to less demanding but still useful tasks. My typical bad day looks like this: thinking about the #1 item on my todo list, feeling dumb, discussing small problems (e.g. minor GUI tweaks) with the programmers, feeling dumb again, and ending up with declaring an Errand Day (mostly reacting to email).
(What I described above is a “good bad day”. A “bad bad day” is when I slide into procrastination at the start of a day and remain useless for the rest of it—which, thankfully, doesn’t happen that often.)