There is a mass of research on when software developers do their best work. The answer, depending on which study you read, is: the morning, the afternoon, the late evening, or 2am. The research contradicts itself because developers contradict each other. Some ship features before sunrise. Others don't open their laptops until the sun goes down. The only thing everyone agrees on is that the middle of the day - the hours between 11am and 3pm, the hours most companies consider "core working hours" - is when the least meaningful code gets written.
This is the story of the hours that matter, the ones the calendar doesn't protect, and what your contribution graph reveals about where you do your real work.
The Maker's Schedule
In 2009, Paul Graham published a short essay called "Maker's Schedule, Manager's Schedule" that became one of the most referenced pieces of writing in software culture. The core idea is simple: people who make things - programmers, writers, designers - need time in units of half a day or longer. People who manage things - executives, coordinators, project managers - work in units of an hour.
The problem is that managers set the calendar. Meetings get booked in one-hour slots because that is how the manager's day is structured. But for a developer, a single one-hour meeting at 2pm doesn't cost one hour. It costs the entire afternoon. The morning is spent knowing the meeting is coming. The time after the meeting is too short to start anything substantial. Two halves of a day, each too small to do anything hard in.
Graham was describing something every developer already felt but couldn't articulate. The essay gave it a name, and the name spread. Seventeen years later, "maker time" is standard vocabulary in engineering culture. Companies like Shopify and Basecamp have experimented with meeting-free days. Some teams batch all meetings into Tuesday and Thursday afternoons, leaving the rest of the week clear.
But the essay also explained something else: why so many developers work at night. If the daytime calendar is full of interruptions, the night is the only remaining territory. Nobody schedules a meeting at 11pm. Nobody pings you on Slack at 1am. The night is maker time by default - not because developers prefer it, but because the day has been colonised by managers.
The Triple Peak Day
In 2024, Microsoft Research published a study on hybrid work patterns among software developers that identified something unexpected: a "triple peak day." Traditional office workers had two productivity peaks - morning and afternoon, separated by a lunch dip. Remote and hybrid developers had three.
The first peak was the expected morning burst, roughly 9am to 12pm. The second was the expected afternoon session, 2pm to 5pm. The third was a late evening peak between 9pm and midnight - a significant block of focused coding that didn't exist in pre-remote data.
The researchers found that this third peak wasn't overtime in the traditional sense. Developers were not working longer hours overall. They were redistributing their hours - taking longer breaks during the day (school runs, exercise, errands) and making up the time in the evening when the house was quiet and the Slack channels were silent.
The triple peak day is not a pathology. It is an adaptation. Developers discovered that the evening hours were more productive per minute than the afternoon hours, and they adjusted. The quiet of 10pm is worth more than the chaos of 2pm.
What the Data Actually Shows
A 2018 study by Claes, Mäntylä, Kuutila, and Adams analysed commit timestamps across 86 open source projects - hundreds of thousands of commits. Their findings were more nuanced than the "developers are night owls" narrative suggests.
Two-thirds of developers followed a standard work schedule and rarely worked nights or weekends. The remaining third showed significant after-hours activity. Tuesday was the most active day across most projects. Monday and Friday were the least active. Weekend commits were rare but not absent - about 10-15% of total activity.
The circadian pattern of commits followed a predictable curve: activity began rising around 8am, peaked between 10am and noon, dipped slightly after lunch, rose again in the early afternoon, then declined through the evening. But the long tail was notable - there was a persistent trickle of commits between 10pm and 2am that didn't appear in comparable studies of other professions.
A more recent study published in late 2025 in the journal Empirical Software Engineering confirmed the broad pattern but found a subtle shift: nighttime and weekend commits have increased, particularly during early morning hours. The researchers attributed this to the normalisation of flexible and asynchronous work habits since the pandemic.
The data tells a more honest story than either "developers are night owls" or "developers work 9 to 5." The truth is that developers work on a spectrum, and the spectrum has been stretching at both ends.
The Circadian Reality
Circadian rhythms - the body's internal clock that governs when you feel alert and when you feel sleepy - vary by age, genetics, and habit. Research in chronobiology has consistently shown that the circadian cycle shifts toward later hours during adolescence and early adulthood, peaking around age 21, then gradually shifts back toward earlier hours as people age.
This maps neatly onto the demographics of the developer population. A 22-year-old junior developer is biologically primed to be most alert at 10pm. A 45-year-old engineering director is biologically primed to be most alert at 8am. They both think the other is doing it wrong.
There is also the screen problem. The blue light emitted by monitors suppresses melatonin production - the hormone that signals your body to prepare for sleep. Developers spend 8 to 12 hours a day staring at high-contrast screens. The cumulative effect is that their circadian rhythm gets pushed later and later, regardless of their natural chronotype. The screens are literally reprogramming their internal clock.
This creates a feedback loop. Late-night coding leads to later sleep, which leads to later waking, which leads to less morning productivity, which leads to more evening work. The cycle reinforces itself until the developer is fully nocturnal - not by choice, but by drift.
The Sleepy Brain Advantage
Here is the counterintuitive finding from creativity research: tired brains are sometimes better at creative problem-solving than alert ones.
A 2011 study by Mareike Wieth and Rose Zacks found that people performed better on insight problems - problems that require a creative leap rather than systematic analysis - during their non-optimal time of day. Morning people were more creative in the evening. Evening people were more creative in the morning.
The explanation is that a tired brain has weaker inhibitory control. It is worse at filtering out irrelevant information. But "irrelevant" information is exactly where creative solutions hide. When your prefrontal cortex is too tired to enforce strict logical thinking, your mind wanders, makes unexpected connections, and stumbles onto solutions that brute-force analysis would never find.
For programming, this means that different times of day are better for different types of work. Morning alertness is good for systematic tasks - writing tests, code reviews, implementing well-defined features. Late-night looseness is better for architectural thinking, debugging hard problems, and the kind of creative flow state where you lose track of time and emerge at 3am with something beautiful.
Developers who work at night are not being unproductive. They are matching the task to the brain state.
What Your Atlas Reveals
When we render a developer's contribution graph as a star atlas, the time dimension collapses. You see days, not hours. But the rhythm is still there.
The Steady Orbit - even stars, day after day - belongs to the morning coder. The person who opens their laptop at 8am, commits steadily through the day, and closes it at 6pm. Their atlas is a band of consistent light.
The Supernova - dark gaps punctuated by explosive bursts - belongs to the night coder. The person who does nothing visible for days, then disappears into a 72-hour tunnel and emerges with a thousand lines of code. Their atlas is dramatic: bright clusters surrounded by void.
The Seasons pattern - active in winter, quiet in summer - often reflects the triple peak day in action. Winter evenings are long and dark, perfect for that third productivity peak. Summer evenings pull people outside. The rhythm of the year mirrors the rhythm of the day.
Your atlas doesn't judge which pattern is better. There is no "correct" distribution of stars. A sky full of steady, even light is not superior to one with bright bursts and dark gaps. They are different rhythms, different stories, different ways of building.
The only thing they have in common is that the work happened. And that deserves to be visible.
Protecting the Dark Hours
If you are a developer reading this at 11pm, with your screen dimmed and the house quiet and something finally clicking in the code - you do not need science to tell you this is your time. You already know.
The research just confirms what you feel. The maker's schedule is real. The third peak is real. The creative advantage of the tired brain is real. The circadian drift caused by screens is real.
The only question is whether you protect it. Whether your team respects it. Whether your calendar reflects it. Whether you have the self-awareness to notice your own patterns and design your day around them instead of against them.
Paul Graham ended his essay with a request: "All we ask from those on the manager's schedule is that they understand the cost." Seventeen years later, the request still stands. The best code is written in the hours the calendar doesn't protect. Sometimes those hours are early morning. Sometimes they are late at night. Almost never are they between 11am and 3pm on a Tuesday.
The dark hours are where the real work happens. Your atlas knows it, even if your standup doesn't.
Curious about your own rhythm? Enter your GitHub username at codexstellarum.com and see the shape of your coding life - free to preview, prints from £25.