A side project can become difficult to reopen long before you decide to abandon it. The last session ended with a half-working form. You remember there was an error, but not which request caused it. Now opening the editor means reconstructing the problem before you can do useful work. It is easier to start another project with a clean first step.
The 72-hour rule is a reminder to inspect that cost of returning. If a project has gone quiet for three days, spend a short session making the next step explicit. Three days is a practical interval, not a scientific deadline. A planned break does not kill a project, and a daily commit does not prove it is healthy. The useful question is whether you can return without rebuilding the entire context in your head.
Diagnose the gap before changing the target
Open the project and write down why it went quiet. Be specific. “I was inconsistent” gives you nothing to change. “The database connection failed, and I did not save the error” suggests a reproducible setup task. “The remaining feature is too large for an evening” suggests a scope problem. “Exams are this week” suggests that the project needs a planned pause.
Choose the explanation supported by the situation instead of treating every gap as a discipline failure. A longer streak will not fix an unclear requirement. A smaller requirement will not create time during a busy week. You need the response to match the blocker.
For example, suppose you are building a reading-list app. “Finish authentication” contains registration, sign-in, session handling, validation, error messages and recovery. A usable next step might be “show an explicit error when the sign-in request returns 401.” That is a change you can inspect without finishing every authentication path first.
Leave a restart note while context is fresh
At the end of a session, leave three short lines in an issue, your own task list or a local note. Record what works, what is blocked and the first action for the next session. The note is useful even if you return tomorrow. It is especially useful after a gap when the last thing you remember is a vague impression that the feature was nearly done.
Works: a valid sign-in opens the reading list.
Blocked: an invalid password leaves the button spinning.
Next: reproduce the 401 response and reset loading in finally.The note should name an action rather than a topic. “Authentication” is a topic. “Reset loading after a rejected sign-in request” tells you where to begin. Add the reproduction steps if the problem is hard to trigger. Do not include a password, token or private customer data in the note.
This is also a cheap handoff to your future self. It does not require a new planning application or an elaborate board. Put the note somewhere you will see it when you reopen the repository.
Make the next change small enough to verify
The next session should produce one observable improvement. It might fix an error, add a missing validation rule or make a setup command work. Describe the result before changing the code. “The button becomes available again after a failed request” is easier to verify than “clean up the form.”
For the reading-list example, the fix might use a structure like this. It is an illustration of the loading-state boundary; adapt the request and error handling to your application.
async function signIn() {
setLoading(true)
setError(null)
try {
await submitCredentials()
openReadingList()
} catch {
setError("Sign-in failed. Check your details and try again.")
} finally {
setLoading(false)
}
}Verify both the successful and failed paths. If you only test the path that already worked, you have not checked the reason for the change. When the behavior is correct, save a meaningful commit describing it. The commit preserves a checkpoint; it is not the goal of the session by itself.
Use a short return session
When you have been away, try a bounded session before promising a large evening of work. Start the application, read the restart note and reproduce the issue. If setup fails, repairing setup is the session’s useful result. If setup works, make the small change you described and check it.
Stop with another restart note. The purpose is to lower the next entry cost, not to repay three days of absence with an exhausting sprint. A project that requires a four-hour session every time you touch it is hard to sustain alongside classes, a job or other commitments.
A short session may also show that you no longer want the project. That is useful information. You can archive it deliberately, explain what you learned and move on. Keeping every idea alive forever is not a measure of good development practice.
Read the activity record honestly
GitHub can help you notice a quiet period, but activity alone does not explain it. You may have been designing on paper, reviewing someone else’s work or working in a private repository. Conversely, a full contribution graph can coexist with a feature that nobody can use.
Pair the activity signal with an artifact. Ask what changed for a user, which bug was reproduced or which assumption was tested. A commit called “update” is less useful to your future self than one that names the behavior it changes. Avoid splitting an ordinary change into many commits merely to make the count look better.
The free GitHub check-up offers a view of recent public activity. Treat it as a prompt for questions about your routine. It cannot tell you whether a quiet day was wasted or whether a busy day moved the right project forward.
Decide whether a daily commitment fits
If you have reliable time most days, a small daily target can make returning easier. Pick one repository and choose a target you can keep on an ordinary busy day. Review the daily boundary and your time zone before starting. Do not use the most productive weekend as the baseline for the next month.
Vigilante connects a selected GitHub repository to a daily commitment and a settlement-building game. Qualifying work creates verified days. The game provides a visible place to return to, but it cannot choose useful tasks for you. Payments and opening the app cannot turn an empty session into verified work.
If your schedule genuinely supports only a few sessions a week, use that schedule in your own planning. A rest day is a valid choice. This restart checklist works with a weekly routine too: leave context, name the next action and return at the time you chose.
A checklist for the next quiet gap
- Identify the real blocker: context, scope, setup, time or interest.
- Write one observable result for the next session.
- Start the project and reproduce the current behavior.
- Make the smallest useful change and check the affected paths.
- Leave a restart note before you stop.
The project does not need a dramatic comeback. It needs a next step that you understand and enough room in your schedule to take it. Use the three-day reminder when it helps you notice rising friction; change the interval when your life requires a different rhythm.