You should finalize your day with a building project. At least I like to do that. Often you need more than a day to finish some larger task. Also, if you are getting headaches, it’s totally fine to stop coding for the day (and you probably really should). Still, it would be nice to know the next day where you left.
Quick Tip
Here is the quick tip: If you want to continue working on some problem you were not able to solve the day before, just add something that won’t compile near that place. Next day trying to build the project will just fail at this point!
This saves you from having post-its, notes etc. You see right in the code where you left.
I’m doing that all the time when I get headaches in the evening and I feel it’s better to do something else and come back the next day.
Also: Micro commits
Besides that, (it’s a slightly different topic but still really important) always consider doing micro commits instead of having a dangling-in-the-air working copy for a long time.
What are micro commits? You can read about it here in more detail: https://world.hey.com/niko.heikkila/a-practical-guide-to-micro-commits-a37151eb or https://www.industriallogic.com/blog/whats-this-about-micro-commits/.
Basically, you should just commit any small step on your branch that builds. Some advantages of it:
- You can easily roll back stuff and see when stuff started to break.
- Your coworkers can help you out / take over if you are not able to work on it (e.g. because of sickness, quitting, whatever)
- If your machine or setup suddenly breaks you still have all your changes on remote
Conclusion
Instead of wasting post-its, sprinkle around // TODO comments regarding stuff you want to refactor / fix or whatever the next day, just add some plain text inside your code that won’t compile. The next day your build will just stop there!
Do commit as often as possible whenever you changed something that builds. I sometimes see people trying to cram everything in one large commit. Some people like to git commit --amend all the time to have one or a handful of huge commits in the end. (see here if you did never hear of the command: https://www.atlassian.com/git/tutorials/rewriting-history). This is fine as long as you still do often commit. Still, you loose your separate checkpoints each commits represents by doing that. Therefore, personally I try to never do that for completely different commits.
However, the most dangerous behavior is to just not commit anything until everything is finished (having only a local working copy). It’s not healthy for you and also it’s really bad practice in a team setup. For example, nobody can quickly jump on your feature branch and try to help you if help is needed at some point. In general, it’s really easy to f’ up and loose days of work by continuously working on never committed local working copies.
