Taking breaks and avoiding burnout

Why this matters

Learning to program is tiring in a particular way. You are not only moving your hands. You are holding new words, new rules and a half-built program in your head, and checking each one against what the computer says. After an hour of that, the work gets slower and sloppier even though you are still sitting at the desk.

Burnout is the state where you are worn out for long enough that the work stops moving forward. You may still open the file every day, but you dread it, you make the same mistakes again, and you feel that you are bad at programming. In most cases the problem is not talent. The problem is that the study went on past the point where the brain could still take in new things.

This lesson is about three habits. First, notice overload while it is still small. Second, plan breaks before you are tired, not after. Third, stop for the day at a point you chose, and leave a note so that tomorrow starts quickly. The rule for how long a study block should last is in the study routine lesson, 05-building-a-study-routine. This lesson does not repeat it.

What overload means

Overload means you have more new material in front of you than you can hold at one time. Think of working memory as a small desk. You can keep a few things on it at once: the goal, the input, the rule you are testing, and the error you are chasing. When a fifth thing arrives, something falls off. Usually it is the goal, and you start fixing whatever is on screen rather than what the program needs.

Overload is not a sign that you failed. Every beginner hits it. The skill is catching it while it is small. A session that is still productive at the first sign of trouble is worth far more than a session that goes on for three hours and ends with you unable to explain what you did.

Signs of overload

Overload shows up in three places: in the code, in your head, and in your body and mood. You do not need to notice all of them. Two or three together are a clear signal.

In the code:

• Your typing errors increase. You see a missing bracket or a misspelled word that you would have caught an hour earlier.
• You paste code you have not read, or you copy a fix from a search result without checking which part it changed.
• You change three or four lines at once, then run the program to see what happens.
• You stop predicting the output and only run the code to find out.
• The same error keeps coming back and you have no new information about it.

In your head:

• You reread the same paragraph and cannot say what it said.
• The words on the page stop meaning anything. A sentence about loops reads like noise.
• Every fix you make seems to create a new problem somewhere else.
• You cannot say what you were trying to do in the last ten minutes.

In your body and mood:

• You dread opening the file. You find a reason to check your messages first.
• You feel irritated at the error message, or at yourself, and the irritation takes up more of your attention than the bug does.
• You lose track of time. An hour passes and you think it was twenty minutes.
• Your sleep is worse than usual, or you are eating at odd times and not noticing.
• You think "I am bad at this" several times in one session.

The first list is the most useful, because it is the easiest to check. You can look at your last few edits and see whether you are changing more than one thing at a time or whether your typos have gone up.

Measuring it: a focus log

You do not have to trust your feelings alone. A focus log is a short note you write every fifteen minutes during a session. Each line has three parts: the time, a score from 1 to 5 for how clearly you are thinking (1 is "cannot think", 5 is "fully on the task"), and a few words about what you are doing.

Here is a log from a session on loops. Save it as focus.txt:

09:00 4 read the loop section
09:15 4 wrote the first loop
09:30 4 loop ran, fixed a typo
09:45 3 nested loop, unsure of the range
10:00 3 range was off by one
10:15 2 same error again
10:30 2 reread the same paragraph three times
10:45 1 cannot predict the output

The scores fall slowly. Nothing dramatic happens at any one line. That is typical. Overload builds up, so you need a rule that catches the trend rather than a single bad moment.

The rule in this example is simple: two low scores in a row means stop. A low score is a 2 or below. Here is a short Python program that reads the log and applies the rule. Save it as focus_log.py in the same folder:

import sys
 
LOW = 2  # a rating at or below this counts as low
 
rows = []
with open(sys.argv[1]) as f:
    for line in f:
        line = line.strip()
        if not line:
            continue
        time, score, note = line.split(" ", 2)
        rows.append((time, int(score), note))
 
streak = 0
for time, score, note in rows:
    if score <= LOW:
        streak += 1
    else:
        streak = 0
    if streak == 2:
        print(f"{time}: two low slots in a row ({note}). Take a break now.")
        break
else:
    print("No break needed by the rule.")
print(f"checked {len(rows)} slots")

sys.argv[1] is the file name you type after the program name. Below, that is focus.txt.

Run it from the folder where both files are saved:

python3 focus_log.py focus.txt

The output is:

10:30: two low slots in a row (reread the same paragraph three times). Take a break now.
checked 8 slots

Read the program in plain words. It keeps a count of how many low scores have come in a row, called streak. A score of 3 or more resets the count to zero. When the count reaches two, it prints a message and stops reading. The else part runs only if the loop finished without stopping, so the message "No break needed" appears only when the rule never fired.

Notice what the rule did. The 10:00 score of 3 reset the count, so the early wobble did not trigger it. The break was called at 10:30, when the second low score arrived. The program is not clever. It just applies a rule you chose in advance, so you do not have to decide in the middle of a bad moment whether you are "really" tired.

The rule and the cutoff are choices. You can make them stricter or looser. The point is to decide them before the session starts.

A log line that breaks the program

The log only works if every line has all three parts. Here is a file where the note is missing from the second line:

09:00 4 read the loop section
10:15 2

Run the program on it:

python3 focus_log.py focus_bad.txt

The output is:

Traceback (most recent call last):
  File "/home/you/study/focus_log.py", line 11, in <module>
    time, score, note = line.split(" ", 2)
    ^^^^^^^^^^^^^^^^^
ValueError: not enough values to unpack (expected 3, got 2)

Your path and the exact layout can differ with your Python version.

The message says the line split into two parts when three were expected. Count the parts in 10:15 2: the time and the score, but no note. The fix is to write the note, even if it is only one word. Tired people often skip the note, which is exactly the entry that matters most when you read the log later. A short note such as "stuck" is enough.

Planned breaks, not rescue breaks

There are two kinds of break. A rescue break happens when you are already stuck and you stop because you cannot go on. A planned break is decided before the session starts, and it happens at a point you chose. Rescue breaks are often late. By then the overload has already cost you time and some of your confidence.

A planned break needs three things written down before you begin:

1. When it happens. For example, after each finished section, or when the focus log says so.
2. How long it lasts. A short break is enough for most sessions. A longer break belongs after two or three sections, or after a meal.
3. What you do in it. Stand up, walk to the kitchen, look at something far away, drink water. Keep the break away from new input.

The third point is where most people go wrong. Scrolling a feed, opening a chat with a new problem in it, or watching a video about the same topic is not a break. It keeps the same desk full. Your eyes move, but your head is still doing the work. A useful test: when you come back, do you feel more able to read the code, or less? If less, the break was not a break.

Worked example: a Saturday afternoon

Sam has two hours on Saturday afternoon to work through the loops lesson and fix a small program. Sam writes this plan in a text file before starting:

Saturday, 14:00 to 16:00
14:00  read the loop section, write three lines in the learning log
14:30  break: stand up, water, look out of the window (5 minutes)
14:35  write the first loop program, run it, fix errors
15:05  break: walk to the door and back (5 minutes)
15:10  change the loop to count only even numbers, predict output first
15:40  break: snack and away from the screen (15 minutes)
15:55  parking note (see below)

Sam does not decide during the session when to take a break. The plan says so. When the timer goes at 14:30, Sam stands up even though the program is nearly working. That feels wrong at first, and that feeling is the reason the plan exists: the decision was already made when Sam was fresh.

The plan also keeps the session short enough to end well. Sam finishes at 16:00 with the program working and with a note for the next time. The plan does not try to fill every minute with study.

Stopping for the day

Most people stop study in one of two ways. Either they quit when they run out of energy, which usually happens in the middle of a bug, or they keep going until something forces a stop, such as a meal or a phone call. Both leave a mess for the next session. The mess has a cost: the first twenty minutes of the next session go to remembering where you were.

Stop on purpose. Pick a time or a point in the work that you can finish, then write a parking note. A parking note is three short lines that tell you, tomorrow, where to start:

Stopped: wordcount.py, the top-3 words part.
Next: change the pattern so it also drops digits, then run it on notes.txt.
Unknown: should "don't" count as one word or two?

The first line says where you are. The second line says the next action, as specific as you can make it. The third line says what you do not know yet, so you do not have to rediscover the question. Writing the unknown down also means you can answer it tomorrow instead of worrying about it tonight.

A good parking note takes one minute to write. It saves you ten or twenty minutes the next day. Put it at the top of the file or in your learning log, wherever you will look first.

Two ways to end the same session

Here are two endings for the same afternoon, side by side:

The second ending does not take much longer. The difference is the decision to stop at a point that is safe to return to.

Stuck or tired

People who are overloaded often say "I am stuck" when they mean "I am tired." The two feel alike but need different responses.

A test you can use: try to say the next step in one sentence. If you can say it and still cannot make yourself do it, you are tired. Take a break, then come back and do that one step. If you cannot say the next step at all, you are stuck. Stuck means you lack a piece of knowledge or a clear question. The method for that is in 01-how-to-learn-programming, which covers shrinking a stuck problem. A break alone will not solve it.

Tired is fixed by rest and a small step. Stuck is fixed by a smaller question. Doing the wrong one wastes time: resting when you are stuck can feel like giving up, and pushing on when you are tired produces the sloppy edits described above.

Worked example 2: a weekend that went too far

Sam had a plan for a week of short sessions, and then a free weekend. On Saturday Sam decided to "catch up" and studied for six hours with no planned breaks. The results are worth looking at closely, because each one is a sign from the list above.

At the start of the afternoon, the programs ran and the predictions were correct. By the fourth hour, Sam was changing three lines at once and running the program after each change. The output looked almost right each time, so Sam did not check the first failing line.

On Sunday, Sam opened the same file and found a missing colon at the end of an if line. Sam had typed it at the end of the Saturday session without looking. The program would not start. Sam spent more than an hour on that one line, even though the error message named it. The message was accurate. Sam was reading it without enough attention.

The better version of Saturday would have had the same six hours spread over three sessions with breaks, a focus log, and a parking note at the end of each. The total time would have been similar. The second version would have left Sam with working code and a clear next step on Sunday, instead of a broken file and a confused start.

Worked example 3: reading the log for a week

A focus log helps most when you look at several sessions together. Suppose you kept a log for five days. The scores might look like this in summary:

• Monday: stopped at the planned time, average score 3.8.
• Tuesday: stopped by the rule at 10:30, average score 3.1.
• Wednesday: no break taken, two low streaks, average score 2.4.
• Thursday: planned breaks taken, average score 3.6.
• Friday: stopped at the planned time, average score 3.9.

The number that matters most is not the average. It is the pattern: on the day the planned breaks were skipped, the low streaks came early and lasted longer. That is useful information. It suggests the schedule was too heavy for that day, or that the breaks were the first thing to go when you felt you were making progress.

The response is not to study more. It is to make the next week's plan shorter, or to start with the planned breaks in place before the first block begins. Treat the log as a tool for adjusting the plan, not as a grade on yourself.

Common mistakes

Waiting until you are exhausted. By the time you are exhausted, the overload has already done its damage. Take the break at the planned point. If you find yourself deciding to skip it because you are "in the zone", that feeling is one of the signs in the list above.

Calling a screen a break. A break that adds new input keeps the desk full. Keep phones and laptops out of the break, or at least away from anything about programming.

Pushing on one bug for an hour. A bug that has taken an hour without new information is usually a sign of overload, not of a hard bug. Write the question down, stop, and return with a parking note. The next look is often faster.

Skipping the note. The note is the part that makes tomorrow easy. Tired people skip it because it feels like a chore. The log example above shows the cost: a line with no note breaks the program. The same thing happens to the next session if the note is missing.

Reading a low score as proof you are bad at this. The log records how you feel during a session. It does not say what you are capable of. A week of low scores usually means the plan was too heavy, not that the person is not suited to programming.

Making up for a missed day with one long session. A long session on a weekend to catch up is the example in Worked example 2. It tends to produce the errors it was meant to fix. Spread the work across more sessions instead, and accept that the schedule will move.

Variations and edge cases

A day with poor sleep. If you slept badly, use the same plan with less new material. Replace one new-topic block with a review of notes you already wrote, or a short reading you have done before. You still study, but you give the desk fewer things to hold. The focus log will show whether that helped.

A hard week at work or at home. Study less, but do not drop everything at once. Keep one short session a day with a parking note. A short session that ends cleanly protects the habit better than a long session that ends in frustration. The advice on protecting the habit is in the study routine lesson.

Several low weeks in a row. If low scores and dread last for weeks, reduce the load for a while and tell someone you trust. If the low mood spreads into sleep, eating or the rest of your life, talk to a doctor. Study can wait. This lesson is about the work, and it cannot replace care for your health.

Group study or a class with deadlines. The same signs apply. A deadline can make it hard to stop, but the planned breaks and parking note still work. Agree the break times with the group if you study together.

How this appears in interviews and real work

Working engineers take breaks too. Teams that ship steadily usually have a normal working day and a clear end. Long stretches of late work often show up later as more bugs, slower reviews and missed handoffs. A developer who can say "I stopped at a clean point and left a note for the next person" is easier to work with than one who works until they drop.

In an interview, you may be asked how you handle being stuck. A plain answer uses the same ideas: you describe the problem in one sentence, decide whether you are stuck or tired, take the step that fits, and write a note if you have to stop. You do not need to claim you never get tired.

Practice

Exercise 1: find the stop point

Here is a focus log with a different pattern:

13:00 5 read the function section
13:15 3 wrote the function
13:30 2 wrong output, no idea why
13:45 3 found the bug, fixed it
14:00 2 next test fails
14:15 2 same failing test, rereading the code
14:30 1 cannot predict anything

With the same rule from this lesson (stop at two low scores in a row), at what time does the program say to take a break? Answer the question before you check.

Show the answer

The 13:30 score of 2 is low, but the 13:45 score of 3 resets the count. The next low streak starts at 14:00 with a score of 2, and the 14:15 score of 2 makes two low scores in a row. The program would say to take a break at 14:15. Remember that the rule only fires at the second low score, so the break comes at the point where the second low score is recorded, not when the session started to feel bad.

Exercise 2: write a parking note

You stopped partway through a small program that reads a list of names from a file and prints them in alphabetical order. The program runs but prints the names in the wrong case, so anna appears after Zed. You have not yet decided whether the program should ignore case. Write a three-line parking note.

Show the answer

Stopped: names.py, the sorting line.
Next: call .lower() on each name before sorting, and run it on names.txt.
Unknown: should the printed names keep their original capitals, or should they all be lowercase?

The first line names the file and the part. The second line is a single action you can start in one minute. The third line is the open question, so you can answer it tomorrow without rediscovering it.

Exercise 3: sort the symptoms

For each item, write whether it is a sign of overload in the code (C), in your head (H), in your body or mood (B), or none of these (N):

1. You reread a sentence and cannot repeat it.
2. You copy a fix from a search result without checking it.
3. You feel the lesson is "too hard for someone like me".
4. You want a snack every ten minutes.
5. You are enjoying the problem and want to try a new idea.

Show the answer

1. H. Rereading without understanding is a head sign.
2. C. Copying code you have not read is a code sign.
3. B. A low opinion of yourself during a session is a mood sign.
4. B. This could be a body sign, but it is also just hunger. Watch for other signs before deciding.
5. N. Interest and a new idea are a good sign, not overload.

Exercise 4: change the rule

Make a copy of focus_log.py and change the value of LOW from 2 to 1. Predict whether the program will print a break message for focus.txt. Then run it.

Show the answer

It will not print a break message. Only one score in the log is 1 (the last line, at 10:45), and a streak needs two low scores in a row. The output is:

No break needed by the rule.
checked 8 slots

This shows why the cutoff matters. With a cutoff of 1, the rule only fires when you are almost unable to think, which is later than most people want. A cutoff set in advance lets you choose how early to stop.

Exercise 5: plan a two-hour session

Write a plan for a two-hour session with three planned breaks. Each break needs a time, a length and an activity. You may choose the study topic. Include a parking note at the end.

Show the answer

A sample plan:

Tuesday, 18:00 to 20:00
18:00  review last week's notes, five minutes
18:05  write one small program on the topic, run it
18:30  break: stand up, walk for five minutes
18:35  fix the program, predict the output of one change first
19:00  break: water and a snack, away from the screen, ten minutes
19:10  add one feature to the program
19:35  break: look out of the window, five minutes
19:40  parking note: the file, the next step, the open question

The plan puts breaks after natural points in the work and keeps the screen out of the break. The last block is a note, not new work, so the session ends cleanly.

Summary

• Overload means more new material than you can hold at one time. It shows up in the code, in your head and in your body or mood.
• A focus log, a score from 1 to 5 every fifteen minutes, shows the trend. Set the stop rule before the session starts.
• Plan breaks before you are tired. Decide when they happen, how long they last and what you will do in them, and keep screens out of them.
• Stop at a point you chose and write a parking note with the place you are, the next step and the open question.
• If you cannot name the next step in one sentence, you are stuck, and a smaller question helps more than rest.
• Spread heavy work over several sessions rather than making up for a missed day with one long one.