The Calendar, the Feedback Window, and the Next Step
A deadline in computing education is not only a date on a syllabus. Its day, hour, feedback rule, and connection to the next task determine what kind of signal reaches a student and when it arrives. This chapter focuses on that temporal infrastructure: how calendar placement concentrates work, why scheduled feedback can move a first attempt earlier than more generous on-demand access, and why a reminder changes behavior only when it is attached to the task's actual process. The practical goal is to distinguish an early signal that creates room to recover from a cutoff that merely produces a sharper final surge.
A date has a calendar geometry
A deadline sits inside a week, not outside it. A Monday afternoon cutoff leaves the weekend behind the student; a Friday midnight cutoff leaves a different set of days and support conditions in front of them. The time of day also determines whether the final work happens while instructors and teaching assistants are available, during a predictable evening period, or at night when fatigue and limited support make recovery more difficult.
The systematic review reports a study that varied both the day and time of weekly deadlines across programming, software-development, and statistics courses. Students tended to work closer to earlier-week deadlines than to later-week deadlines. Submissions were closest to a Monday 4 p.m. deadline and farthest in advance for a Friday midnight deadline. Midnight deadlines produced smoother submission patterns with fewer last-minute spikes, while 4 p.m. and 6 p.m. deadlines produced sharp surges immediately before the cutoff. In that study, work completed close to a deadline and work completed at night also had lower correctness than work completed earlier or during the day. [1]
These results do not make Friday at midnight a universal recommendation. They show that “the deadline is one week away” is an incomplete description of the work environment. A date changes the number of evenings available, the likelihood that a student can ask for help before submitting, and the probability that many students will reach the same boundary at once. The reported correctness differences are observational within submission timing, so they do not isolate the effect of the clock from the kinds of students or tasks that end up at that clock. Still, the calendar pattern is decision-relevant: schedule placement can change concentration even when the assignment itself is unchanged.
This also explains why a technically clear deadline can be behaviorally weak. A course may publish an exact time, but if the only meaningful cue is the final cutoff, students receive no reason to convert a distant task into a first step. Conversely, a sequence of early signals can create visible points at which work becomes discussable. The distinction is not between a date and no date. It is between a terminal boundary that arrives after silence and a temporal design that tells students when a useful next state should appear.
An early signal is different from a sharp cutoff
Automated feedback makes this distinction especially visible in computing courses. An autograder can report whether code compiles, whether selected tests pass, or how much of a task appears complete. But the time at which that information becomes available—and the conditions for receiving it—can shape behavior as much as the information itself.
In one reviewed programming project, scheduled feedback created two early submission windows before the final deadline. Forty-nine percent of students submitted before the first early deadline and 70% before the second. In another project, overnight feedback increased the share of submissions made at least one day early from 14% to 42% and reduced late submissions from 30% to 5%. These policies did not simply offer a test result whenever a student happened to ask. They attached useful information to a known point in time, giving students a reason to make an attempt before the final boundary. [1]
The comparison with immediate feedback is important. A different policy allowed on-demand automated feedback during the final days but imposed grade penalties after the first two attempts. It offered more immediate access in one sense, yet it did not reliably reduce delayed starts. The evidence therefore does not support the simplistic conclusion that less feedback is better, or that automated feedback is harmful. It suggests that a clear and supportive temporal cue can matter more for early engagement than the amount of feedback access considered in isolation.
The timing signal also changes the shape of activity. Scheduled feedback can produce bursts around its early deadlines: students respond to the signal in clusters. Immediate feedback can produce more evenly spaced submissions, while still failing to move the first attempt very far forward. Both patterns may be preferable to a single final-night rush, but they represent different kinds of pacing. A course that wants students to make an early, testable attempt may prefer a scheduled window. A course that wants repeated, self-directed iteration may prefer accessible feedback without forcing everyone into the same moment. The available studies do not establish one best arrangement for all projects.
There is another caution in the relationship between timing and performance. Delayed first submission was strongly associated with project failure under both scheduled and immediate-feedback schemes in the reviewed comparison. That is consistent with earlier engagement being important, but it does not show that the feedback policy alone caused the difference. Students who submit early may also be more prepared, more confident, or more able to interpret the feedback. The strongest claim is narrower: policies that create an early opportunity and clear reason to submit can change engagement timing, and that timing is a plausible pathway to better results.
The sequence is intentionally conditional. A schedule can offer an early signal without a student using it, and a reminder can name a next step without making the step feasible. Feedback belongs to the course's temporal design only when it arrives early enough to change what the student can still do.
Reminders work when they are attached to a process
A generic reminder says that a deadline exists. A process-aware reminder says what state the work is in and what action would make the next state possible. The difference matters most when an assignment lasts long enough for students to lose track of intermediate decisions.
The review describes several reminders embedded in longer computing tasks. For month-long programming assignments, emails analyzed the latest submission and reported progress relative to course expectations and peers. Those alerts were associated with earlier first submissions, earlier completion, fewer late submissions, and higher grades among students who engaged earlier. A GitHub bot checked a repository against a checklist aligned with the software-development cycle and updated the student about which items passed. That task-aware support led to earlier starts, more iterative code development, and higher project scores. In a three-month software-engineering capstone, a chatbot monitored progress against a student's plan, sent reminders as deadlines approached, and allowed rescheduling; the study reported fewer overdue days relative to planned timelines. [1]
These interventions do more than repeat “start early.” They reduce the distance between a reminder and a decision. A student can see that testing has not begun, that a planned task is incomplete, or that the current schedule is unrealistic. The message becomes a small piece of process information. It can prompt a next action while there is still time to learn from the result.
The pattern changes for short, routine work. In large introductory courses, generic email reminders for weekly exercises increased the proportion of students who attempted the work but did not significantly change start time, finish time, completion rates, or homework scores in one study. Another reminder experiment increased completion rates without changing when students started or finished. Those findings do not mean that reminders had no value. They indicate that the reminders primarily changed participation, not the temporal structure or performance of work that was already short and highly specified.
A useful diagnostic follows: if students know what to do but are failing to notice that a small task exists, a generic prompt may be enough. If they know the task exists but cannot coordinate design, coding, testing, and revision, the reminder must expose the process. Sending more messages without supplying more actionable information can increase notification volume while leaving the underlying bottleneck untouched.
Helpful, annoying, and effective are different judgments
Student perceptions are necessary evidence, but they are not a substitute for behavioral measurement. In one month-long programming-assignment study, email alerts improved submission timeliness even though 55% of students said the messages were a waste of time and only 24% said the alerts caused them to start earlier. For short weekly exercises, the reverse pattern appeared: 56% of students described reminders as helpful or motivating even though the measured effects did not include meaningful changes in start time, finish time, completion, or performance. In the capstone chatbot study, students rated email alerts and automatic rescheduling as helpful and those features coincided with fewer overdue days, while motivational messages were rated less favorably and showed no measured behavioral effect. [1]
The divergence is not a reason to disregard either side. A reminder can be effective without being liked, which matters if repeated annoyance eventually reduces attention or trust. A reminder can be liked without changing the outcome a course cares about, which matters if the intervention is being justified as a pacing tool. The evaluation question should specify the intended function: participation, earlier start, distributed work, quality, or recovery from an unrealistic plan. Perception then helps explain adoption and fairness, rather than serving as an all-purpose verdict.
This is also where supportive design matters. Overnight feedback was viewed very positively, and scheduled feedback was viewed more positively than immediate feedback with penalties in the reviewed studies, even when the penalty-based policy made more feedback available on demand. A structure that gives students information at a useful time can align the experience of being helped with the measured behavior. A structure that turns feedback into a scarce or punishable resource may create compliance while weakening the sense that the course is helping students learn.
The design question that remains
Calendar placement, feedback timing, and reminders all alter the signal around an assignment, but none operates independently of the task. A Friday midnight deadline may smooth submissions in one setting while creating inaccessible support hours in another. A scheduled feedback window may produce an early attempt but also a burst of activity. A task-aware bot may help a capstone while being excessive for a ten-minute exercise. The evidence supports examining the fit, not choosing a technology by label.
The practical test is to ask what the next signal makes possible. Does it give students a reason to begin before the final rush? Does it expose a state of the work that can still be repaired? Does it connect them to feedback or support while those resources are available? And can the course measure whether the change affected timing, quality, and experience rather than merely increasing messages or submissions?
The next question is why these signals have stronger effects on some tasks than others. A long project has hidden transitions that can benefit from milestones and process reminders; a short routine exercise may need only a participation cue. The difference between those tasks determines whether temporal structure becomes a scaffold or just another layer of scheduling.