3 ms·

"Always know what the next thing to do is" is really powerful. I never end a work day without leaving a note for the next micro task I would have done if I coul

"Always know what the next thing to do is" is really powerful. I never end a work day without leaving a note for the next micro task I would have done if I could (or wanted to) keep going.

boiler_up800 3y ago
Completely agree. This is more than half the battle for me. You might say it’s the entire job for some roles.
PaulKeeble 3y ago
I really like leaving a unit test failing at the end of a session. Its much easier to write it at the end than the beginning and they are often pretty easy to complete. Its a surprisingly simple way to get back into things the next time you pick it up and it is I think superior to just leaving a todo list of microtasks because it solves the problem of what precisely you need to reload into your brain to get going, the approach is at least for the first 10 minutes already decided.
drekipus 3y ago
The "micro task note" is what unlocks this for me. I will leave a todo or comment of the next steps in the commit message, and each day i start out with a 'well what did i even do? git log -n 1'. "Leave a broken test" doesn't work for me, because the test can be breaking for other reasons, and it often takes a lot of time to set up a test, in which you wake up with a better / cleaner solution. (so the test you wrote is testing the wrong implementation.) I've been trying out "logseq"[1] for daily journaling, which allows you to see what you did yesterday VERY easily, and this has been pretty good for me. (but i don't normally use these note taking apps and it possibly won't last long, we'll see.) 1. https://logseq.com/ https://logseq.com/
- munksbeer 3y ago
  > and it often takes a lot of time to set up a test, in which you wake up with a better / cleaner solution. (so the test you wrote is testing the wrong implementation.) Isn't that a smell? There was a recent topic on testing. In my view, I should be testing the API of units of coherent logic. If I change the underlying implementation of that logic, why should my tests change?
  - drekipus 3y ago
    i agree absolutely, which is why when i'm stuck in the middle of writing implementation, i'll write a "TODO: now do foo then bar" and not bother trying to "write a failing test"

"Always know what the next thing to do is" is really powerful. I never end a work day without leaving a note for the next micro task I would have done if I could (or wanted to) keep going.

boiler_up800 3y ago

Completely agree. This is more than half the battle for me. You might say it’s the entire job for some roles.

PaulKeeble 3y ago

I really like leaving a unit test failing at the end of a session. Its much easier to write it at the end than the beginning and they are often pretty easy to complete. Its a surprisingly simple way to get back into things the next time you pick it up and it is I think superior to just leaving a todo list of microtasks because it solves the problem of what precisely you need to reload into your brain to get going, the approach is at least for the first 10 minutes already decided.

drekipus 3y ago

The "micro task note" is what unlocks this for me. I will leave a todo or comment of the next steps in the commit message, and each day i start out with a 'well what did i even do? git log -n 1'. "Leave a broken test" doesn't work for me, because the test can be breaking for other reasons, and it often takes a lot of time to set up a test, in which you wake up with a better / cleaner solution. (so the test you wrote is testing the wrong implementation.) I've been trying out "logseq"[1] for daily journaling, which allows you to see what you did yesterday VERY easily, and this has been pretty good for me. (but i don't normally use these note taking apps and it possibly won't last long, we'll see.) 1. https://logseq.com/ https://logseq.com/

munksbeer 3y ago
> and it often takes a lot of time to set up a test, in which you wake up with a better / cleaner solution. (so the test you wrote is testing the wrong implementation.) Isn't that a smell? There was a recent topic on testing. In my view, I should be testing the API of units of coherent logic. If I change the underlying implementation of that logic, why should my tests change?
- drekipus 3y ago
  i agree absolutely, which is why when i'm stuck in the middle of writing implementation, i'll write a "TODO: now do foo then bar" and not bother trying to "write a failing test"