> Action leads to motivation, not the other way around.
I've found this to be very true. A trick I found that made this easier for me is to leave a trivial task to start tomorrow with, often with notes to remind myself what to do. Ideally the trivial task is on the way to something bigger, not finishing something. That gets me into my editor, gets me running the code / tests / etc., and gives me a trivially easy way to get moving. Then the motivation kicks in and I can start moving for real.
The same approach helps me with tasks outside of software development, and even outside of work.
That's Hemingway’s trick: “You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again.”
there are so many different names for this. and time blocking. but it really works. small reminder. it works even when, like me, someone has serious case of ADHD. but its slightly different and there are extremes on both end. where it does not work or it works to well. but it always work. what I am trying to say if you feel its not efficient you still have to feel it out until you find how it works for you in whatever form it works.
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.
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.
> 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?
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:
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.
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.
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 :)
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?
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.
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.
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.
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.
I remember being on a session with the pragmatic programmers (ie the people from the book) and they recommended making a compile error on purpose as the last thing one did before leaving work. The next day you compiled the code and get an error, fix this and they continue working. You are already doing work. This sets your mind on the right track from they day before. I gave used this a bit and it works pretty well.
Same, it's so much easier to quit just when you hit your limit and keep a 2 min window to bookmark your solution search and leave some potential follow ups. Makes restarting your job a lot easier.
It most definitely does work the other way around. The problem of course is that you can’t just wait for motivation to appear. But you can start an action.
I’m just stating the obvious, but I find it odd that the author states the opposite isn’t true.
While directing actors on the film set one of the questions to ponder is whether you first need to put people into an emotional reality so they can produce gestures matching that reality or whether you tell them how to move and then they find their emotional reality within the movements.
In my experience both works and some actors prefer one and some the other. But you can try it yourself, think of a sad thing, slumb together make a sad gesture and listen (emotionally) what happens on the inside.
It doesn't matter what I need to do, I start every day by building my code. It gets me typing commands in the terminal and more often than not there's a build error or warning I need to address
I've found this to be very true. A trick I found that made this easier for me is to leave a trivial task to start tomorrow with, often with notes to remind myself what to do. Ideally the trivial task is on the way to something bigger, not finishing something. That gets me into my editor, gets me running the code / tests / etc., and gives me a trivially easy way to get moving. Then the motivation kicks in and I can start moving for real.
The same approach helps me with tasks outside of software development, and even outside of work.