5 ms·

Yep. When there are no clear tasks, I sometime leave a syntax error at the place work should continue tomorrow. This is quite effective. It can make the answer

by jraph 1y ago

Yep. When there are no clear tasks, I sometime leave a syntax error at the place work should continue tomorrow. This is quite effective. It can make the answer to the "Where was I?" question immediate instead of taking a few seconds and this is one fewer barrier.

euroderf 1y ago
Yes. It's funny how this kind of trick can instantly snap the entire working context back into your mind. Essentially leaving you free to forget about the context during your free time and overnight. Truly a useful "hack". It's also useful to jot down a quick list of (say) three items that are at the top of your mind when you leave work for the day, and they too will help with a context restore.
- bravesoul2 1y ago
  Also just chuck Todo comments in the code The magic of Git means you can immediately find them in the working index and get back on to it. Just remember to remove them before the commit.
  - diggan 1y ago
    > The magic of Git means you can immediately find them in the working index How does git help you find certain texts in files? `grep` should do the trick just fine, unless I misunderstand what "chuck Todo comments in the code" mean, the code lives on your disk no?
    - cjbillington 1y ago
      They'll show up in the diff. Grep will find them too, but any in the diff you'll know for sure were added by you.
      - diggan 1y ago
        Parent mentioned specifically finding them from the index, so they've been added but not committed, so they're not even remote nor have an author associated with it, yet. And why it matters to get them from the diff if they're on disk already? Literally one command to find all of them, rather than going through git?
        bravesoul2 1y ago
        One advantage of git is it shows you any uncommitted changes. Great way to get context the next day of where you were up to anyway even if you didn't use TODO to make it searchable.
    - bravesoul2 1y ago
      Grep works too. I just spend a lot of time in git or tools that wrap it. It's an unconscious habit to check the status and diffs when I open my editor.
      - diggan 1y ago
        Yeah I mean I use the git cli exclusively too, and use it switch contexts, but I'm not sure why'd I use it to find stuff that is already on disk. But, you do you, was just trying to understand if there was any benefits I didn't knew about :)
        deleted 1y ago
        [deleted]
    - MaxBarraclough 1y ago
      To get your bearings regarding where you got to with your uncommitted work, you might do something like: git status && git diff HEAD That will tell you which files you've touched and will show you their diffs. If necessary you can search within the diff: press '/' to bring up the search feature (assuming you're using the default less pager). To search for all mentions of 'TODO' in the repo, ignoring untracked files: git grep TODO or, case insensitive variant: git grep -i TODO
      - gcarvalho 1y ago
        I have a very involved `gq` alias that helps me find and finish pending work. It works either in the current repository or a folder containing multiple repositories. Basically, my assumption is that `gq` should return empty, which means I have a clean slate, and can start taking on new work. Otherwise, there is ongoing work that needs attention. It just lists: * modified/untracked files * stashed changes * local-only branches (not tracking a remote branch) * branches out-of-sync with their upstream (either ahead or behind) * branches that aren't the main branch (even if tracking and in-sync with a remote upstream) Getting this command to return empty is a surprisingly effective way to stay productive, especially when losing focus due to too much work. It's basically inbox-zero for git. But it only works if you like working with a clean worktree.
      - diggan 1y ago
        I know how to use git :P The question is why use git for something when the TODOs still sits in your files on disk. You're not doing anything with those commands that `grep` by itself cannot do...
  - rmwaite 1y ago
    If you do this often enough you can create a simple commit hook that searches for these markers and will fail to commit if it finds them.
- Henchman21 1y ago
  "focus division multiplexing"
apwell23 1y ago
I always leave work( for lunch, for home) at failing test . Try to anyways.
- martinpw 1y ago
  Maybe this is implied, but I like to leave with a failing test that I know how to fix. That way I am not brooding on it all evening. Leaving when things are broken and I don't know why is frustrating.
dogman1050 1y ago
I've always used "$$". It's probably a subliminal thing.
jenny91 1y ago
Another similar thing is to leave an easy sentence half-finished so when you come back to it, there's an obvious first thing to do and hop back in.
getlawgdon 1y ago
I like this. Good trick.
shortrounddev2 1y ago
#pragma warning
devrandoom 1y ago
I've done that too. Especially if I have to stop working, but I'm in the middle of something. There are no compilation errors or tests failing but the feature isn't completed. Introducing a syntax error is like a saved game, portal back in time. I'll come back to it tomorrow and it'll take me max one minute to reload the context into my brain.
dugmartin 1y ago
I do this also. My tweak is to make the syntax error just a sentence of what tiny step needs to be done next. Then the next day I turn that sentence into a comment, do what needs to be done next and then delete the comment. It me the dual endorphin hit of completing a task and deleting code.

by jraph 1y ago

euroderf 1y ago

Yes. It's funny how this kind of trick can instantly snap the entire working context back into your mind. Essentially leaving you free to forget about the context during your free time and overnight. Truly a useful "hack". It's also useful to jot down a quick list of (say) three items that are at the top of your mind when you leave work for the day, and they too will help with a context restore.

bravesoul2 1y ago
Also just chuck Todo comments in the code The magic of Git means you can immediately find them in the working index and get back on to it. Just remember to remove them before the commit.
- diggan 1y ago
  > The magic of Git means you can immediately find them in the working index How does git help you find certain texts in files? `grep` should do the trick just fine, unless I misunderstand what "chuck Todo comments in the code" mean, the code lives on your disk no?
  - cjbillington 1y ago
    They'll show up in the diff. Grep will find them too, but any in the diff you'll know for sure were added by you.
    - diggan 1y ago
      Parent mentioned specifically finding them from the index, so they've been added but not committed, so they're not even remote nor have an author associated with it, yet. And why it matters to get them from the diff if they're on disk already? Literally one command to find all of them, rather than going through git?
      - bravesoul2 1y ago
        One advantage of git is it shows you any uncommitted changes. Great way to get context the next day of where you were up to anyway even if you didn't use TODO to make it searchable.
  - bravesoul2 1y ago
    Grep works too. I just spend a lot of time in git or tools that wrap it. It's an unconscious habit to check the status and diffs when I open my editor.
    - diggan 1y ago
      Yeah I mean I use the git cli exclusively too, and use it switch contexts, but I'm not sure why'd I use it to find stuff that is already on disk. But, you do you, was just trying to understand if there was any benefits I didn't knew about :)
      - deleted 1y ago
        [deleted]
  - MaxBarraclough 1y ago
    To get your bearings regarding where you got to with your uncommitted work, you might do something like: git status && git diff HEAD That will tell you which files you've touched and will show you their diffs. If necessary you can search within the diff: press '/' to bring up the search feature (assuming you're using the default less pager). To search for all mentions of 'TODO' in the repo, ignoring untracked files: git grep TODO or, case insensitive variant: git grep -i TODO
    - gcarvalho 1y ago
      I have a very involved `gq` alias that helps me find and finish pending work. It works either in the current repository or a folder containing multiple repositories. Basically, my assumption is that `gq` should return empty, which means I have a clean slate, and can start taking on new work. Otherwise, there is ongoing work that needs attention. It just lists: * modified/untracked files * stashed changes * local-only branches (not tracking a remote branch) * branches out-of-sync with their upstream (either ahead or behind) * branches that aren't the main branch (even if tracking and in-sync with a remote upstream) Getting this command to return empty is a surprisingly effective way to stay productive, especially when losing focus due to too much work. It's basically inbox-zero for git. But it only works if you like working with a clean worktree.
    - diggan 1y ago
      I know how to use git :P The question is why use git for something when the TODOs still sits in your files on disk. You're not doing anything with those commands that `grep` by itself cannot do...
- rmwaite 1y ago
  If you do this often enough you can create a simple commit hook that searches for these markers and will fail to commit if it finds them.
Henchman21 1y ago
"focus division multiplexing"

apwell23 1y ago

I always leave work( for lunch, for home) at failing test . Try to anyways.

martinpw 1y ago
Maybe this is implied, but I like to leave with a failing test that I know how to fix. That way I am not brooding on it all evening. Leaving when things are broken and I don't know why is frustrating.

dogman1050 1y ago

I've always used "$$". It's probably a subliminal thing.

jenny91 1y ago

Another similar thing is to leave an easy sentence half-finished so when you come back to it, there's an obvious first thing to do and hop back in.

getlawgdon 1y ago

I like this. Good trick.

shortrounddev2 1y ago

#pragma warning

devrandoom 1y ago

I've done that too. Especially if I have to stop working, but I'm in the middle of something. There are no compilation errors or tests failing but the feature isn't completed. Introducing a syntax error is like a saved game, portal back in time. I'll come back to it tomorrow and it'll take me max one minute to reload the context into my brain.

dugmartin 1y ago

I do this also. My tweak is to make the syntax error just a sentence of what tiny step needs to be done next. Then the next day I turn that sentence into a comment, do what needs to be done next and then delete the comment. It me the dual endorphin hit of completing a task and deleting code.