# Codex Stellarum > Codex Stellarum turns a GitHub contribution history into a vintage astronomical star atlas: a personalised fine art print in which every day of code is a star, sized by activity, arranged on a celestial chart. Free to preview from any GitHub username, repository or organisation. Digital download £10, archival giclée prints from £25, framed prints from £69. ## Facts - What it is: a personalised star atlas print generated from public GitHub contribution data. Each contribution day becomes a star; busy days are large and bright, quiet days small and faint. - How to get one: enter a GitHub username, repository (owner/repo) or organisation at https://codexstellarum.com. The preview is free and needs no account. - Layouts: Chronicle (vertical timeline), Planisphere (circular year, months like a clock face), Helix (spiral, one revolution per year) and Rosette (concentric rings of 52 weekly segments) for commit history; Horizon for a repository's GitHub stars. - Themes: Observatory (gold stars on navy), Parchment (ink on aged paper), Blueprint (cyanotype), Minimal. - Prices: digital download £10; unframed archival prints from £25; framed prints from £69; team pricing from £19 per print for engineering teams (https://codexstellarum.com/business). - Sizes: squares of 30, 45, 70 and 90 cm; A3, A2 and A1 (ISO sizes) in portrait or landscape. Every size except the 90 cm square can be framed in black, white or natural solid wood with acrylic glazing, delivered assembled and ready to hang. - Paper: 200gsm enhanced matte art paper, giclée printed, made to last decades. Prints ship worldwide in 5 to 14 days; digital downloads arrive by email in minutes. - Data: the site reads public GitHub data only. Private contributions appear only if the GitHub user has enabled them on their profile, and then anonymised. - Made by: Keope Labs, United Kingdom. Support: support@codexstellarum.com. ## Journal, full text (33 posts) # Codex Stellarum or CodePrints? URL: https://codexstellarum.com/blog/codex-stellarum-or-codeprints Published: 2026-09-21 · Updated: 2026-09-24 Author: Codex Stellarum Two products will take a GitHub contribution graph and turn it into something you can hang on a wall. One of them is ours. This is an honest comparison, written knowing that anyone reading it can see which side we are on, so we have kept to facts you can check on both sites and said plainly where the other product is the better choice. ## THE SHORT VERSION CodePrints prints your GitHub contribution graph as the graph: the familiar grid of green squares, faithfully reproduced, on a poster, a framed poster, a canvas or a mug. If you want the thing you see on your profile, recognisable at a glance to any developer, that is what they make, and they have been making it well for years. Codex Stellarum takes the same data and redraws it as a vintage star atlas: every day a star, sized by how much you did, arranged on a planisphere or a spiral in the style of a seventeenth-century celestial chart, printed as archival giclée. A developer sees their commits. Everyone else sees a star map. Same data. Two different objects, for two different walls. ## WHO MAKES THEM CodePrints is made by a small team of engineers at a remote agency called dyve. Their own account of the origin is the one most people in this niche would recognise: they wanted geeky art for their home offices, found everything lacking personality, and decided to bring open source contributions into the physical world. Their customers include David Heinemeier Hansson, who thanked them publicly for a print of five years of Rails contributions. They have the head start, and they earned it. Codex Stellarum started as a gift for a friend who had just landed her first developer job after teaching herself to code. We ordered a contribution print, liked it, and still wanted something that a non-developer would hang in a living room without needing the grid explained. So we drew her two years of commits as a sky. Her partner walked in and asked where it was going on the wall. That reaction is the product. ## WHAT YOU GET CodePrints offers a poster from 21 by 30 centimetres up to 70 by 100, a framed poster in black, natural or white wood, a canvas, and a mug. Each size is matched to a number of years of history, roughly four to ten, and the result is the grid you already know, printed cleanly. Codex Stellarum offers an archival print from 30 centimetres square up to 90 centimetres, and A3, A2 and A1 in portrait or landscape, on 200gsm matte paper, plus a £10 digital download if you want to print it yourself or send it the same day. There are four layouts for a commit history and a fifth for a repository's stars, four themes, a choice of year range from one year to your whole history, and the option to chart a repository or an organisation instead of a person. Every size except the 90 centimetre square also comes framed, in black, white or natural wood, ready to hang. There is no canvas and no mug; if you want a mug, CodePrints is the answer. ## THE DATA Both read the public GitHub contribution graph. Both are limited by what GitHub exposes: private work appears only if the account has enabled private contributions, and then without detail. CodePrints lists support for private repositories, GitLab and Bitbucket as coming soon at the time of writing; check their site, since that may have changed. Codex Stellarum reads GitHub only, and shows the full history rather than a fixed number of years. ## PRICES At the time of writing, CodePrints posters run from 25 to 45 euros by size, framed posters and canvases from 49 to 99 euros, and the mug is 19 euros. Codex Stellarum prints start at £25 unframed and £69 framed, the digital download is £10, and team orders start at £19 per print. Neither is expensive for a made-to-order print. The price difference between the two at a given size is small enough that it should not be the reason you choose. ## DELIVERY AND RETURNS Both are printed to order. CodePrints, like most personalised-print sellers, does not accept returns on personalised items but will put right anything that arrives damaged or wrong. Codex Stellarum ships prints in five to fourteen days, sends digital downloads within minutes, and publishes its refund terms on the site. ## CHOOSE CODEPRINTS IF You want the contribution graph itself on the wall, recognisable to any developer who walks in. You want it on canvas or on a mug. You want to pay in euros from a European shop with a long track record. Or you are buying for a developer from a developer, where the green squares are a shared language and half the point. ## CHOOSE CODEX STELLARUM IF You want the print to work outside the home office: a living room, a hallway, an office corridor where most people will never have seen a contribution graph. You want the whole history, not a fixed number of years. You want a repository or an organisation charted rather than a person. You are buying for someone whose work you do not fully understand, and you want a gift that says so without needing a glossary. Or you need it today, in which case the digital download exists for exactly that. ## WHAT WE THINK We are glad CodePrints exists. They proved that developers want their work on a wall, and a category with two good answers is better for the developer buying than a category with one. If you have read this far and are still unsure, the test is simple: picture the wall. If it is the wall everyone sees, and the people who see it do not know what GitHub is, come and see your sky. If it is the wall above the desk, and the grid is the point, buy the grid. See your own history as a star atlas. Enter your GitHub username at codexstellarum.com and preview it free - digital £10, prints from £25. --- # The Telescope Problem URL: https://codexstellarum.com/blog/the-telescope-problem Published: 2026-09-17 · Updated: 2026-09-17 Author: Codex Stellarum In the winter of 1609, Galileo Galilei pointed a telescope of his own grinding at the Pleiades and counted. Six stars were visible to the naked eye, seven on a good night. Through the glass he found thirty-six more. He turned to the Milky Way and found that the pale band across the sky was made of individual stars, thousands upon thousands of them, too faint to have been seen by anyone in the whole of human history. He published the drawings in 1610 in a short book called Sidereus Nuncius, the starry messenger, and the sky was never the same size again. For the next two centuries the atlas-makers kept up. Bayer in 1603 had drawn some twelve hundred stars, each one placed inside a constellation figure engraved with the care of a Renaissance portrait. Hevelius in 1687 added new constellations of his own and kept the figures. Flamsteed in 1729 added precision and kept the figures. Bode in 1801 drew more than seventeen thousand stars, many of them telescopic, invisible to the eye that was meant to look at the chart, and he still kept the figures. Orion still had his club. Cassiopeia still had her chair. Then the atlases stopped. ## THE LAST FIGURE The reason was arithmetic. Between 1852 and 1859 Friedrich Argelander at the Bonn Observatory catalogued 324,198 stars in the northern sky, one at a time, by eye, through a small telescope. The Bonner Durchmusterung was published as a set of charts, and the charts had no figures on them. The engravers were as skilled as ever. There was no longer room. You can draw a hunter around forty stars. You cannot draw one around a hundred thousand. The figure that had given the sky its meaning became a decoration in the way, and the decoration was removed. Elijah Burritt's atlas of 1835 was the last major one to keep the constellation pictures. After that, star charts became what they are today: precise, exhaustive, and unreadable to anyone who has not been trained. The data won. The art that had made the data legible for two hundred years was the price. Astronomers did not choose this. The telescope chose it for them. Every improvement in the instrument produced more stars than the previous generation had known existed, and at some point the number crossed a line past which the old way of seeing could not follow. ## THE NEW INSTRUMENT A contribution graph was designed for a particular density of work. A developer commits a few times a day on a good day. A very productive one, on a very good day, might commit twenty. The colour scale on GitHub runs to four shades of green, which was enough to cover the range of human output. That range is changing. In February 2026 Andrej Karpathy declared that the new default for a developer was to write no code at all: to orchestrate agents that write it, and to act as oversight. We called this [the seventh age of the developer](https://codexstellarum.com/blog/seven-ages-of-the-developer), in a profession that has been declared finished six times before. Stripe's agent system produces more than a thousand merged pull requests a week. A single developer running a swarm of coding agents can generate in an afternoon the commit volume that used to take a quarter. The graphs are getting brighter. We see it on the atlases we render. The star fields of 2026 are denser than the star fields of 2023 in a way that has nothing to do with people working harder. This is the telescope problem, arriving in a different sky. The instrument now finds more stars than the old figures can hold. [The archetypes we wrote about](https://codexstellarum.com/blog/the-shape-of-your-code), the Steady Orbit, the Supernova, the Fade, were drawn around a human density of work. When every day is a supernova, the Supernova stops meaning anything. When an agent commits through the weekend, the weekend voids that made a graph look like a person's life fill in. The figures dissolve, the way Orion dissolved under Argelander's hundred thousand points. ## WHAT A STAR WAS COUNTING The question underneath this is what a star on the atlas was ever measuring. The GitHub graph counts commits, pull requests, reviews, issues. It always has. But nobody who ever framed a contribution graph was framing a commit count. A commit is a unit of bookkeeping. What the graph recorded, accidentally, was attendance: the days a person sat down and decided that something should exist that did not exist yet. The count on any given day was a proxy for that decision, and a rough one. Agents break the proxy. They do not break the thing it was standing in for. An agent that merges four hundred pull requests overnight has decided nothing. Somewhere, a human read the ticket, judged the approach, set the quality gate, looked at the output and said yes or no. That day of judgement is one day. It is one star. Codex Stellarum already scales brightness relative to your own most productive period rather than to a fixed count, which means inflation cancels itself out. A day with four thousand agent commits and a day with forty are both bright if they are both the brightest you had. What the atlas cannot yet do, and what we will [say plainly rather than fake](https://codexstellarum.com/blog/how-we-built-codex-stellarum), is tell a human commit from an agent's. The API does not distinguish. Neither can we. ## THE MAGNITUDE OF SHOWING UP Argelander's catalogue made the old way of drawing the sky impossible. The sky itself lost nothing. Within a generation, astronomers had found another way: photographic plates, then spectra, then the classification of stars by their light rather than their position, work done largely by women at Harvard whom history called computers. The figures were gone, and a deeper structure appeared in their place. Something similar is available here. The commit count was always the crudest signal on the graph. The rhythm underneath it, the days on and the days off, the seasons, the gaps, the return after a long silence, was the thing worth keeping, and none of that is produced by an agent. An agent does not take August off. An agent does not go dark for six weeks after a burnout and come back lighter. An agent does not stop for a new baby. The pattern of a human life around the work is exactly what the agents cannot generate, and it is exactly what an atlas is drawn from. The tools will keep finding more stars. The question for anyone making charts is whether the human shape can still be read through them. We think it can, if the chart is honest about what it is counting. After Bode, the art drained out of astronomy. It does not have to happen twice. See what your sky looks like this year. Enter your GitHub username at codexstellarum.com and preview your atlas - free to try, prints from £25. --- # Light from Dead Stars URL: https://codexstellarum.com/blog/light-from-dead-stars Published: 2026-08-12 · Updated: 2026-08-12 Author: Codex Stellarum Find Orion on a winter night and look at the red star at the hunter's shoulder. That is Betelgeuse, roughly five hundred and fifty light years away, which means the light entering your eye left the star somewhere in the fifteenth century, before Columbus sailed. What you see tonight is a report, sent five centuries ago, arriving now. Now find the faint smudge in Andromeda, the one object outside our galaxy visible to the naked eye. Its light is two and a half million years old. It left before there were humans to see it. Every photon that lands on your retina from that galaxy set out before anyone on Earth had lit a fire. Astronomers call this lookback time. The further away a thing is, the older the picture of it you receive. The night sky is a collage of thousands of different pasts, some minutes old, some older than our species, arranged on one dome so that they look simultaneous. ## THE STAR THAT IS ALREADY GONE Betelgeuse is a red supergiant near the end of its life. At some point in the next hundred thousand years it will collapse and explode, and for a few weeks it will be bright enough to see in daylight. In late 2019 it dimmed to about a third of its usual brightness and, for a few months, people who knew what that could mean checked the sky every evening. It turned out to be a cloud of dust. The star is still there. Probably. Nobody can be sure. If Betelgeuse exploded four hundred years ago, the news is still in transit, and Orion's shoulder will look exactly as it does tonight until the day the light of the explosion arrives. A star can be dead and still on the chart. The chart shows the light that reached it, which is all any chart has ever shown. This is true of every star on every atlas ever drawn. Bayer's Uranometria of 1603 is a map of where light was in 1603, sent from places and times that had nothing to do with each other. Hipparchus' catalogue, [recovered from under the prayers of a medieval monk](https://codexstellarum.com/blog/the-palimpsest), records positions of light that left its sources centuries before he was born. Every star chart in history is a record of arrivals. ## THE FUNCTION YOU DELETED IN 2021 Open a contribution graph from a developer with ten years on it and pick a bright week in 2019. The function written that week was deleted in 2021, in a refactor that made it unnecessary. The service that took the whole spring was replaced by a vendor in a single afternoon in 2023. The startup was acquired and its repository archived, read-only, a tombstone with the code still inside. The migration script ran once and was never needed again. The feature was built, shipped, used by a hundred thousand people, and removed when the product changed direction. The person who wrote those commits used a language you have since abandoned and a framework you now recommend against. They named things badly. They did not know what you know. They had not yet had the argument that changed how you structure a service, had not yet been through the outage that taught you to distrust the cache, had not yet read the book. They were, in every way that matters to the work, someone else. And the star is still there. On the graph, and on any atlas drawn from it, the bright week in 2019 is exactly as bright as it was the day it happened. Its light left a source that no longer exists, from a person who no longer exists in that form, and it is still arriving. ## A THOUSAND PASTS AT ONCE Most people, seeing their graph rendered as a sky for the first time, read it as a picture of their career. It is more precise to say it is a picture of arrivals. Each star is light from a different moment, sent by a slightly different person, out of a codebase that has since changed or vanished, all landing on one sheet so that they look like a single continuous thing. That is what a career is, seen from outside. A collage of pasts that never coexisted. The self who wrote the 2016 commits never met the self who wrote the 2024 ones. They share a username and little else: the tools have changed, the opinions have changed, and most of the code the earlier self wrote, the later self has since removed. The graph holds them together the way the sky holds Betelgeuse and Andromeda together. Different distances, different ages, one dome. ## WHAT THE CHART CANNOT KEEP One honest limit. If you delete a repository, GitHub removes its contributions from your graph. The star goes out at once, with no delay in transit. Archived repositories keep their stars. Renamed and transferred ones keep them. Code deleted from inside a living repository, which is the fate of nearly all code, keeps every star it ever earned, because the commit happened and the graph records that it happened. The only way to lose the light is to destroy the source and the record together. The full rules for [what the graph counts and what it drops](https://codexstellarum.com/blog/what-is-the-github-contribution-graph) are in our explainer. We mention this because a print made from a graph is only as complete as the graph, and we would rather say so than let anyone believe the atlas can see light that has been put out at both ends. ## FIXING THE LIGHT A photograph of the night sky is a way of stopping the arrivals. The light has been travelling for a thousand years and lands, finally, on a plate, and stays there. Astronomers before the photographic era had no such thing. They drew what they saw, by hand, and the drawing outlasted the seeing. A print is the same act. The graph will keep changing. The years will roll off the default view. Code will keep being deleted, repositories archived, the person who made the commits keep turning into someone else. A print fixes the light where it is on the day it is made: every star that has arrived so far, from every past that sent one, held still on a sheet of archival paper that does not know or care whether the source still exists. It does not make the code come back. Nothing does. What it keeps is the fact that the light was sent, and the shape it made when it landed. The code is gone. The light is still arriving. Fix the light where it is. Enter your GitHub username at codexstellarum.com and preview your atlas - free to try, prints from £25. --- # Messier's Mistakes URL: https://codexstellarum.com/blog/messiers-mistakes Published: 2026-07-07 · Updated: 2026-07-07 Author: Codex Stellarum On the night of 28 August 1758, at the Hôtel de Cluny in Paris, a twenty-eight-year-old clerk named Charles Messier was tracking a comet through the horns of Taurus when he found something in the way. It was a faint, cloudy patch of light, a little elongated, with no tail and no definite edge. It looked like a comet. Messier had been hired by the astronomer Joseph-Nicolas Delisle for one purpose, to be the first person in France to recover Halley's comet on its predicted return, and he had spent months sweeping the sky for exactly this kind of smudge. So he watched it. He came back the next night, and the night after. It had not moved. Comets move. This thing sat in Taurus like a stain on the glass. He wrote down its position so he would not be fooled by it again, and went back to looking for comets. ## A LIST OF THINGS TO IGNORE That entry became the first line of a list. Over the next twenty-three years Messier, and later his colleague Pierre Méchain, kept adding to it: every fuzzy, stationary, comet-shaped object that a comet hunter might waste a night on. He published forty-five of them in 1774, and a final version of 103 in 1781. Later historians, going through his notes, brought the count to 110. The purpose of the list was purely negative. It was a catalogue of false alarms. Messier had no interest in what the objects were, only in where, so he could skip them. He was very good at his actual job. He found thirteen comets. Louis XV called him the ferret of comets. He was elected to the Académie des Sciences and the Royal Society. By the standards of his own century he was a success, and the success was the comets. Nobody remembers the comets. Not one of the thirteen has a name anyone uses. They came, they were bright for a season, they left, and the sky closed over them. Everybody remembers the list. The first entry, the stain in Taurus, is the Crab Nebula, the wreckage of a star that Chinese astronomers watched explode in 1054. M31 is the Andromeda galaxy. M42 is the Orion Nebula. M45 is the Pleiades. M13 is the great cluster in Hercules, hundreds of thousands of stars packed into a ball. M57 is the Ring Nebula, a dying sun's last breath drawn in glowing gas. Every March, amateur astronomers across the northern hemisphere stay up all night attempting a Messier marathon, trying to see all 110 objects between dusk and dawn. The catalogue of distractions became the most beloved catalogue in astronomy. Messier died in 1817 believing he had spent his life on comets. ## THE REPOSITORY WITH FOUR COMMITS Every developer has a Messier list, and almost nobody looks at it. It is the repository with four commits and a README that says work in progress. The command-line tool written at eleven at night to fix an annoyance that nobody else had. The parser started on a train. The framework abandoned the moment it made the real problem clear. The game engine that never rendered a second frame. The Advent of Code folder that stops on day nine every year. The thing built specifically to avoid the thing that was due. We touched on [the side project bloom](https://codexstellarum.com/blog/the-dark-spaces) once before, as one kind of gap in a graph. It deserves its own catalogue. These were the smudges on the way to the comet. The comet was the job: the product, the release, the codebase with a company's name on it. The comet was what you were being paid to find. The side project was the stationary blur that got in the way, noted down and skipped over so you could get back to sweeping. Look at the graph of anyone who has been writing code for ten years and the comets are easy to spot. They are the dense bands, the sustained months of daily work, the bright clusters around a launch. They are also, in nearly every case, gone. The company was acquired. The product was sunset. The codebase was rewritten by people who never read the original. What was bright for a season has left, and the sky has closed over it. The smudges are still there. The four-commit repository is still there. Sometimes someone found it. Sometimes it got a star from a stranger in another country who needed exactly that annoyance fixed. Sometimes it grew, in a corner, over years, into the thing the developer is now known for. The library that a whole ecosystem depends on was almost always somebody's Messier object first: noted, ignored, returned to on a slow Tuesday, and never meant to be the point. ## CATALOGUING THE SMUDGES On an atlas, the side projects have a look. On [the Chronicle](https://codexstellarum.com/blog/the-chronicle-layout), they appear as scattered bright points that never consolidated into a band: a flare in one week, silence, another flare two months later, the signature of something worked on when there was time and put down when there was not. On [the Helix](https://codexstellarum.com/blog/the-helix-layout) they show up as a change in texture within a single loop of the spiral, a patch of irregular light against the steady rhythm of the job around it. On [the Planisphere](https://codexstellarum.com/blog/the-planisphere-layout) they tend to sit in the same months every year, the holiday weeks and the dead fortnight in December, the only times the sweeping stops long enough to look at the stain in Taurus. The atlas does not know which stars were the comet and which were the smudge. A commit is a commit. A day is a day. The four-commit repository and the ten-thousand-commit monolith are rendered in the same ink, sized by the same rule, and placed in the same sky. We think this is the right way to draw a life, because a life does not know either, at the time. Messier did not know. He thought the list was the mistake. ## WHAT SURVIVES THE COMET There is a version of a developer's story that only counts the comets. It is the CV. Company, title, dates, the product that shipped. It is true and it is thin, and it leaves out the objects that turn out, decades on, to be the ones worth seeing. The other version keeps the whole list. The things that were built while looking for something else. The false alarms that stayed in the sky after the real thing had gone. Messier died in 1817 having found thirteen comets. We kept the other list. Your side projects are on the chart too. Enter your GitHub username at codexstellarum.com and preview your atlas - free to try, prints from £25. --- # How We Built Codex Stellarum URL: https://codexstellarum.com/blog/how-we-built-codex-stellarum Published: 2026-06-07 · Updated: 2026-06-07 Author: Codex Stellarum Most of what follows is the version we would tell another developer over a beer. Not the marketing version. The product is a vintage astronomical print made from someone's GitHub history, but the interesting bits are mostly behind the canvas. This is what they were. ## It started as a joke The whole thing started as a throwaway idea: a contribution graph looks a bit like a sky. Make it actually look like a sky. Print it. That was easy for a hundred commits. It was a different problem entirely once we tried it on Linus Torvalds, who has twenty years of history and more activity in a quiet month than most accounts have in a year. The renderer fell over. The fetch timed out. The page hung. The thing that had worked beautifully on our test profile turned out to be a toy. Most of the work since has been about making the toy survive contact with real GitHub accounts. ## The GitHub API is two APIs in a trench coat You cannot build anything serious on top of GitHub without learning this the hard way. There is REST, which is comprehensive and old and paginated everywhere. There is GraphQL, which is newer, faster for shaped queries, and the only sane way to get a contribution calendar without burning a thousand requests. The two are rate-limited differently. They disagree about timezones. They occasionally disagree about counts. We use both. GraphQL for the calendar itself, because that is the one place where it is dramatically better. REST for repositories, stargazer events, and the metadata that GraphQL either does not expose or makes worse to query. The hybrid is uglier than picking a side, but it is the only thing that actually works. The other thing you learn quickly is that the contribution calendar is not quite what it appears to be. It is a per-day count, normalised to a viewer's timezone, with a maximum window of about a year. To assemble a multi-year history, you walk it year by year. Some years come back instantly. Some years, on some accounts, do not. We retry. We back off. We log the ones that misbehave. ## Sampling stargazers without lying The contribution graph is bounded. Stargazers are not. A repository with four hundred thousand stars has four hundred thousand timestamped events, paginated a hundred at a time, with a media-type header you have to opt into to get the dates at all. Pulling all of it for every repo is not realistic. Pulling none of it makes the stars mode useless. So we sample. Adaptively, based on star count: the threshold and stride scale so that a small repo gets every star and a viral repo gets a representative slice across its lifetime. The slice is large enough that the shape of the curve is right. It is not large enough to claim a count. This is where the honesty rule comes in. The stats panel only shows numbers we can defend. If we sampled, we do not pretend we did not. We report what we actually measured and we leave the rest alone. No invented quantiles, no fake confidence intervals, no extrapolated totals. If we cannot stand behind the number, the number is not on the page. ## Caching, and the day we learned about race conditions GitHub's rate limits are not generous when you are doing this for every visitor to a marketing site. So we cache aggressively, in two layers. The first layer is permanent. Once we have fetched the expensive parts of a profile or repository, we keep them. They do not change retroactively. Yesterday's stars are still yesterday's stars. The second layer is a seven-day incremental refresh. When someone visits a cached profile, we serve the cache immediately and, in the background, fetch only what is new since the last refresh. The fresh data gets merged on top. This worked beautifully for about a week, and then we discovered that two tabs opening the same profile at the same time would both kick off a background refresh, both write their merged result, and occasionally race each other in ways that produced a flickering `partial=true` flag and a banner that would not go away. The fix was small and slightly embarrassing: a thirty-second debounce on background refreshes per cache key. If we refreshed it in the last half minute, do not refresh it again. The flicker stopped that day. The metadata for all of this lives in a single JSONB column on the cache row, called `cache_metadata`. It tracks last-fetched timestamps, the shape of what we have, and which stages of the fetch are complete. Most of the cleverness of the cache is in what that column stores. Everything else is bookkeeping. ## Six layouts, one renderer There are six layout formats: Chronicle, Planisphere, Helix, Rosette, Horizon, Astrolabe. Each one is a different way of projecting a year (or a slice of years) onto a flat surface. Chronicle is a column. Planisphere is a circular star chart in the tradition of a five-thousand-year-old instrument. Helix spirals. Rosette aggregates into weekly petals. Horizon stretches the timeline into a landscape band. Astrolabe is radial. The first attempt had a different React component for each layout. By the third, we knew that was a mistake. They were drifting. A fix to one was not a fix to the others. The colour temperatures were slightly different. The star sizes were slightly different. It was untenable. So we collapsed them. There is one canvas renderer. Each layout is, in effect, a projection function that maps a date and a count to an `(x, y, radius, opacity)`. Everything else (the multi-layer glows in dark themes, the ink-on-paper texture in light themes, the magnitude legend, the density scaling) is shared. The renderer is large and somewhat dense, but it is one file we trust, not six files we keep in nervous sync. ## Stars mode and the flatline problem When you switch from commits to stars, you are no longer drawing daily counts. You are drawing a cumulative curve of events that arrive at irregular times. The naive plot is a step function with long flat stretches between bursts, which looks like nothing, and it looks especially like nothing on a landscape layout. We interpolate. Linearly between known points on most layouts, with a monotone cubic Hermite spline on Horizon, where the curve is the entire visual. The spline is monotone deliberately: stars only go up, and a non-monotone interpolation will invent dips that did not happen. That would be lying with curves. We do not do that. ## Themes are not just colours There are four themes: Observatory, Parchment, Blueprint, Minimal. Two are dark. Two are light. Switching themes does more than change the palette. Dark themes get multi-layer radial glows around each star, with additive blending so dense regions bloom. Light themes get an ink-on-paper aesthetic with no glow at all, and the stars become small dense marks rather than soft points. Themes also reach into the wall preview, because a dark print on a wall sits inside a dark mat with less padding, and a light print sits inside a cream mat with more. The ratios live in a shared file called `wallComposite.ts`. The live HTML preview and the exported PNG composite both read from the same constants, so a frame in the browser and a frame in the email look like the same object. That sounds obvious until you spend a week chasing a four-pixel difference between them. ## The wall preview cannot fudge the scale The wall preview is a render of the framed print hanging on a wall, in a room, in a particular lighting condition. It is a marketing image, not a physics simulation. But people use it to imagine the print on their own wall, and the moment it gets scale or proportion wrong, the trust goes. So we auto-select the scene based on theme, format, and print size. A blueprint A1 lands in a different room from a parchment A3. The framed composite is horizontally centred on the chosen wall. The frame gradient is shared between the in-browser CSS and the canvas export, so the wood grain in the preview is the same wood grain in the downloadable mockup. There is a `room` URL parameter that overrides the auto-selection, mostly for when we are choosing scenes for the landing page and need to pin one deliberately. ## Headless rendering for fulfilment When someone buys a print, we need a real file. Not a screenshot. Not the on-screen canvas. A print-ready PNG at the resolution the printer expects, deterministically, every time, regardless of who triggered the render or what device they were on. The way this works is mildly ridiculous and we are very proud of it. We have a route called `/render-print` that, when given a fully serialised set of parameters, renders the exact same canvas the customer saw, but at the printer's native resolution. A headless browser hits that route, waits for the canvas to finish drawing, screenshots it, and ships the PNG back. The print pipeline then uploads that PNG to fulfilment. The route has one hard requirement: it must work in cold contexts where the database might be slow or unreachable, because a printer is waiting on the other end. So it depends on as little as possible. The resolution presets are baked in as a synchronous constant called `FALLBACK_RESOLUTIONS`, which means the render never blocks on a network read for something we already know. The postcard generator is a smaller cousin of the same idea: an HTML page rendered to PNG by the same headless setup, with a different template. Once you have the pattern, you reuse it. ## Stripe, webhooks, and the basket that became a fan-out The basket started simple: one print, one checkout. Then people wanted to buy two of different sizes, or a print and a digital download together, or the same print for three friends with three different gift messages. The basket became a list of line items, and the line items had to fan out into separate orders, because fulfilment partners think in single shipments and gift messages do not merge. So a checkout session is one Stripe object, but the webhook on the other end creates one `orders` row per line, kicks off one `process-order` invocation per row, and lets the Prodigi side think about each one independently. If one line is a digital download, it skips Prodigi entirely and goes to the signed-URL email flow. The `orders` table is locked down hard. Row level security is on, there are no policies that grant the client any access, and every read and write goes through edge functions running with the service role. The client has no path to it at all. This is the kind of decision that feels paranoid right up until the moment someone asks "wait, can a logged-in user see other people's orders?" and the answer is a flat "no, there is no path". ## Edge function gotchas we paid for in production A few small things that cost us evenings. Heavy dependencies in edge functions must be imported with the `npm:` prefix, not as bare URL imports. The wrong import shape will silently inflate the bundle and the function will time out during deployment with a message that does not obviously point at the cause. Public functions that do not need auth (`fetch-github`, `resolve-org`, the sitemap, the webhook handlers) need `verify_jwt = false` in `config.toml`. Forgetting that turns a one-line bug into a half-day mystery. The render route especially must not depend on any async setup it does not absolutely need. The headless browser has a timeout. The printer has a queue. If the function takes too long to first paint, the render can die before the order moves forward. That is the failure mode the whole render path is built to avoid, which is why the synchronous fallback for resolution presets matters: in the render path, do less. ## Dates are not a solved problem We have a single helper file for date arithmetic. Every parse goes through `parseLocalDate`. Every format goes through `formatLocalDate`. They are both local-timezone aware, on purpose. If you let dates drift through `new Date(string)` and `toISOString()` and the various Date constructors, you will, eventually, draw a contribution from Sunday on Saturday because someone in Auckland visited the site at midnight UTC. We have made this mistake. We will not make it again. ## The small details that nobody asked for The structural labels on the atlases (Mensis for the months, Hebdomas for the weeks, Catalogus for the legend) are hardcoded Latin. They do not translate. They are a design decision, not an internationalisation bug. The body text uses single hyphens, never em dashes. Em dashes feel modern in a way that does not belong on something pretending to be a sixteenth-century chart. There are triple-rule borders around almost every section, because a single rule looks like a div and three rules look like an engraving. ## What we would do differently The cache layer should have been a Postgres function from day one. Doing it in TypeScript across an edge function meant we re-implemented locking and debouncing badly before we got it right. The renderer should have been canvas from the start. We tried SVG first. It was beautiful for a thousand stars and unusable for a hundred thousand. The stats panel went through three iterations before we accepted that the only honest answer was to show fewer numbers. There is a version of the product where we faked the missing ones. We are glad we did not ship it. But on the whole, we are happy. The thing prints. The thing arrives. The thing looks like a star map of someone's working life, which is what we said it would be when we started, slightly as a joke. --- # Every GitHub Achievement Badge, Explained URL: https://codexstellarum.com/blog/github-achievements-explained Published: 2026-06-05 · Updated: 2026-06-05 Author: Codex Stellarum GitHub achievements are the platform's attempt to gamify a craft that does not gamify well. They appear as small enamel-pin shaped badges on the right side of a developer's profile, awarded for behaviours that GitHub has decided are worth marking. Most developers have a few. Almost nobody has them all. The community alternates between rolling their eyes at the whole system and quietly checking the page after every merged pull request. What follows is a guide to every active badge. Each entry covers what the badge requires, how to unlock it, and the slightly more interesting question of what it actually says about the developer who has it. ## The standard badges These are the ones available to every account. They are tiered, which means each one can be earned multiple times, with the colour of the badge changing as the count rises. The tiers run default, then bronze, silver, and gold. Gold is the top; there is no rank above it. ### Pull Shark Awarded for opening pull requests that get merged. Two merged pull requests unlock the default badge, sixteen unlock bronze, one hundred and twenty-eight unlock silver, and one thousand and twenty-four unlock gold. The numbers double each time, which is a small joke at the expense of anyone counting. The badge says less than it appears to. Two merged pull requests is a single decent week's work; one thousand is a multi-year accumulation. A gold Pull Shark is a reasonable signal that someone has been writing code consistently for at least a few years. ### Pair Extraordinaire Awarded for co-authoring commits using Git's `Co-authored-by:` trailer. One co-authored commit unlocks the default badge, ten unlock bronze, twenty-four unlock silver, and forty-eight unlock gold. This one is more interesting than it looks. Pair Extraordinaire requires a specific Git workflow - genuine pair programming with the trailer correctly applied - which most teams do not practise. Seeing it on a profile usually means the developer either works at one of the small number of companies that practises real pairing or has gone out of their way to credit collaborators on solo commits, which is its own kind of signal. ### Quickdraw Awarded for closing an issue or pull request within five minutes of it being opened. A single occurrence unlocks it. The badge is harder to read than the others because the speed can mean opposite things. A maintainer who closes spam issues quickly will collect it within days. So will a developer who triages well. So will someone who opens and immediately closes their own pull requests by mistake. ### Galaxy Brain Awarded for having answers accepted in GitHub Discussions. Two accepted answers unlock the default badge, eight unlock bronze, sixteen unlock silver, and thirty-two unlock gold. Galaxy Brain is the badge most likely to be missing from senior engineers' profiles, because senior engineers tend to answer questions on Slack and Discord rather than in public Discussions. When you see it, especially at gold or above, the developer is almost certainly an active open source maintainer or a deliberate community contributor. ### YOLO Awarded for merging a pull request without review. A single occurrence unlocks it. It is the only badge whose name openly acknowledges that the behaviour it rewards is, in most circumstances, a mild mistake. Most developers earn YOLO once, on their own repository, by accident. Seeing it on a profile means little. Not seeing it on a profile that otherwise has a lot of activity is, oddly, more telling - it usually means the developer either works exclusively in environments where merges require review, or has gone out of their way never to merge their own work alone. ### Public Sponsor Awarded for sponsoring an open source developer or project through GitHub Sponsors. A single sponsorship unlocks it. This is the only badge that costs money. It is also, quietly, the most reliable signal on a profile. A developer with the Public Sponsor badge has actually moved real currency in support of someone else's work, which is rarer than the discourse around open source suggests. ### Starstruck Awarded for accumulating stars on your own repositories. Sixteen stars unlock the default badge, one hundred and twenty-eight unlock bronze, five hundred and twelve unlock silver, and four thousand and ninety-six unlock gold. Starstruck is the badge that most cleanly tracks a single, hard-to-fake thing: other people finding your work and choosing to mark it. A bronze Starstruck means a project that found a real audience. Silver and above usually means a developer whose name is recognised in their corner of the ecosystem, whether they planned for that or not. ## Experimental and not yet released Two badges in the achievements system are part of an unreleased experimental rollout, cannot currently be earned, and have appeared on profiles only by mistake when GitHub briefly enabled them in error. The most recent confirmed removal was in March 2026. Heart On Your Sleeve is rumoured, based on the criteria GitHub has tested, to be awarded for reacting to something with a heart emoji. Open Sourcerer is rumoured, based on the same tested criteria, to be awarded for having pull requests merged across multiple public repositories. Neither is currently obtainable. Profiles displaying them collected them during one of the brief windows in which the badges were live by accident. ## The retired and the rare GitHub has quietly retired several badges over the years, and the ones that survive on profiles from before the retirement date have become something close to collector's items. The most famous of these is Mars 2020 Contributor, awarded to developers whose code shipped in repositories used by NASA's Perseverance rover. The badge was a one-time award; no new ones are being issued. A profile carrying it belongs to someone whose code is, in the most literal sense, on another planet. Arctic Code Vault Contributor was awarded for contributions to repositories that were archived in the GitHub Arctic Code Vault snapshot taken in February 2020. The vault itself still exists, in a decommissioned coal mine on Svalbard, but the badge was a one-off and has been retired. Holders sometimes describe themselves on Twitter as "frozen in the ice with React 16." ## What the badges quietly say The honest reading of the achievements system is that it tracks a specific, narrow set of behaviours and rewards them in a way that flatters anyone who happens to do them naturally. It misses everything that matters about a developer's work. It does not see code review depth, design judgement, mentorship, debugging instinct, or the long quiet hours of figuring out what to build. What it does capture, taken as a set, is the rhythm of a developer's public life. A profile with a gold Pull Shark, a silver Galaxy Brain, and a Public Sponsor belongs to someone who ships, helps, and gives. A profile with a single bronze Pull Shark and nothing else belongs to someone whose real work happens elsewhere, which is most developers. The badges decorate the profile. The contribution history is the real record. [The graph itself](https://codexstellarum.com/blog/what-is-the-github-contribution-graph), and the years of small daily work it represents, will outlast the achievements system, whose colours and rules will keep shifting as GitHub experiments with what to gamify next. If you want to keep a version of the real record, rather than the decorations, that is what [we make](https://codexstellarum.com/). Your contribution history rendered as a vintage star atlas, every commit a star, every quiet week a dark space. The digital download is £10 and the smallest physical print is £25. The badges stay on the profile. The atlas goes on a wall. --- # What the GitHub Contribution Graph Actually Is URL: https://codexstellarum.com/blog/what-is-the-github-contribution-graph Published: 2026-06-05 · Updated: 2026-06-05 Author: Codex Stellarum Open any developer's GitHub profile and the first thing you see, below their name and bio, is a grid of small coloured squares. Seven rows tall, fifty-three columns wide, the colours stepping from pale grey through four shades of green. It is called the contribution graph, and almost every working developer on Earth has one. Most of us look at it every week. Very few of us could explain, in plain language, what it is actually counting. This is that explanation. ## What the squares are Each square is one day. The grid covers the last full year of activity, ending today, so the column on the far right is this week and the column on the far left is roughly fifty-two weeks ago. Within a column, the top row is Sunday and the bottom row is Saturday, which is one of the small things that annoys developers from countries where the week starts on Monday. The colour of each square reflects the number of "contributions" GitHub counted on that day. A grey square is zero. The four greens, from pale to dark, are scaled relative to the developer's own busiest day in the period, not to some global benchmark. A first-year developer with one or two daily commits will see dark green at the same activity level a staff engineer would barely register. ## What counts as a contribution This is the part most people get wrong. Two actions always count: creating a new repository, and forking a repository. Several more count only when they happen in a standalone, non-fork repository: opening an issue, proposing a pull request, submitting a pull request review, opening a discussion, answering a discussion, and committing to the default branch or the `gh-pages` branch. There are several things people assume count, but do not. Pushing a branch does not count by itself. Only commits on the default branch are tallied, so a feature branch with thirty commits contributes nothing until it is merged. Comments on issues do not count. Reactions, stars, and follows do not count. Wiki edits do not count. Force-pushing rewritten history does not retroactively change the graph either, which is why developers who rebase aggressively sometimes appear less productive than they are. ## What does not appear, even though it happened The graph famously hides private work. By default, only public-repository activity is shown, and private contributions do not appear at all. A developer can opt in to surface them, in which case they appear as anonymized squares with no repository or commit detail. A consultant who spent the entire year shipping production code for a private client can have a graph that looks like a six-month sabbatical. It also hides anything that did not happen on github.com. Commits to a self-hosted GitLab, to Bitbucket, to a corporate Gerrit instance, or to a personal Sourcehut all leave no mark. The graph is not a record of work. It is a record of a specific subset of work, made on a specific platform, attributed to a specific email address that GitHub recognises as belonging to that account. That last detail trips up more developers than any other. If your local Git client is configured with an email address that is not on your GitHub account, your commits will land in the repository correctly but will not be attributed to you on the graph. There is a small army of developers who have lost a year of squares this way and only discovered it during an annual review. ## A brief history The contribution graph was introduced in 2013. It was a simple visualisation borrowed from a then-fashionable corner of data design called the calendar heatmap, where each day of the year was rendered as a coloured cell in a calendar-shaped grid. The original was a one-year view, the same as today. It has been redesigned twice since, mostly to improve the colour palette for colour-blind users, and once to add support for the dark theme. The graph was not designed as a productivity tracker. It was designed as a way to visualise the rhythm of open source work, which tends to come in bursts: a free weekend, a holiday week with too much time, the slow accumulation of small fixes. Within a year of launch, recruiters had started using it as a proxy for hireability, which is not what its designers intended and has caused a measurable amount of harm to developers who do their best work in private repositories or in non-Git workflows. ## What the shape reveals For all its blind spots, the graph reveals more than it should. A long horizontal stripe of dark green, sustained across many months, is almost always either a bot, a streak-maintenance script, or someone who is heading for burnout. A graph that brightens slowly across the year and dims toward the end is often a junior developer growing into the work. A grid that is uniformly bright Monday through Friday and grey on weekends belongs to someone with healthy boundaries, which is rarer than it should be. The most interesting graphs, though, are the ones with [the dark spaces](https://codexstellarum.com/blog/the-dark-spaces). The two-month gap that was a sabbatical. The half-year quiet that was a new baby. The clean line where someone changed jobs. The graph hides the work but accidentally records the life around it. ## What you can do with it You can look at it. You can also pin specific repositories beneath it. You can show or hide private contributions. You can change the default branch detection. You can connect it to other services through the GitHub API. And you can take it off the screen. The graph fades the moment you scroll past it. It updates within a day, and the top view is a rolling twelve-month window, so the exact composition you saw last December has already moved on as this year advanced. GitHub keeps the underlying per-year data, reachable through the year selector on the side of the profile, but it gives you no fixed, framable artifact of a particular year. The data persists. The keepsake does not. If you want a record of a particular year of your work, the only reliable way to get one is to take a snapshot yourself. This is the part of the explainer where we mention that we do this. [Codex Stellarum](https://codexstellarum.com/) turns the same data the graph is built on into a vintage astronomical chart. Every commit is a star, every quiet week is a dark space, and the whole year of work is rendered as something that looks like it was printed in 1640. The digital download is £10. Physical prints start at £25. You enter a GitHub username and the rest assembles itself. The graph is a remarkable piece of small design. It has, almost by accident, become the most-seen visualisation of personal work in modern software. It is also, on its own, a passing view. The squares dim, the year rolls forward, and the particular shape you knew gives way to a new one. Whether you want to keep yours is, in the end, a question about what you think the work was for. --- # Dark Matter URL: https://codexstellarum.com/blog/dark-matter Published: 2026-05-28 · Updated: 2026-05-28 Author: Codex Stellarum In 1970, at the Carnegie Institution's Department of Terrestrial Magnetism in Washington, an astronomer named Vera Rubin sat down with a set of spectra from the Andromeda galaxy and found a problem she could not make go away. Her colleague Kent Ford had built a spectrograph sensitive enough to measure the speed of stars in the galaxy's outer regions, far from the bright central bulge. The physics of what they should find was two centuries old. Stars orbit a galaxy's centre the way planets orbit the sun: the further out you go, the slower the orbit. Mercury circles the sun at forty-seven kilometres a second. Neptune manages five. The outer stars of Andromeda, sitting far from most of the visible mass, should have been crawling. They were not. They were moving as fast as the stars near the centre. Plotted on a graph, the rotation curve should have fallen away like the tail of a comet. Instead it ran flat, all the way out to the edge of the light and beyond. There were two possibilities. Either Newton was wrong, or Andromeda contained five or six times more matter than anyone could see. ## THE MASS THAT DOES NOT SHINE Rubin was not the first to notice. In 1933 a Swiss astronomer at Caltech named Fritz Zwicky had measured the speeds of galaxies in the Coma cluster and found them moving so fast that the cluster should have flown apart long ago. To hold together, it needed far more mass than its galaxies contained. Zwicky called the missing quantity dunkle Materie, dark matter, and published in a German-language journal that almost nobody read. He was famously abrasive. Colleagues found it easy to ignore him. The idea sat untouched for nearly forty years. Rubin's curves were harder to ignore. Through the 1970s she and Ford measured galaxy after galaxy and found the same flat line in every one. By 1980 the evidence was overwhelming. Every spiral galaxy in the sky was embedded in a vast halo of something that had mass, that exerted gravity, and that gave off no light at all. The current estimate is that roughly eighty-five percent of the matter in the universe is dark. Everything you can see through any telescope ever built, every star, every nebula, every planet, every galaxy, is the remaining fifteen. Astronomers have never detected a particle of dark matter directly. They know it exists because of what it does to the things they can see. Rubin died in 2016. She never received the Nobel Prize, which is its own kind of invisible mass. ## THE PRIVATE REPOSITORY A GitHub contribution graph shows public work. By default, commits to private repositories do not appear on it at all. A developer can opt in to have them counted, in which case they show up as anonymised squares: a number with no repository name, no commit message, no detail of any kind. GitHub calls these private contributions. We have written before about [what the graph counts and what it hides](https://codexstellarum.com/blog/what-is-the-github-contribution-graph). Private work is the largest thing it hides. Most professional software is private. The banking system, the logistics platform, the defence contract, the internal tooling at a company with twelve thousand engineers, the stealth startup that has not launched, the client work under NDA. A developer can spend the most intense five years of their career on code that will never appear on their public profile in any form. Their graph, viewed by a recruiter or a stranger, looks like a long sabbatical. The public graph has a rotation curve problem. The visible stars do not account for the mass. ## READING THE CURVE Rubin's insight was that you do not need to see the dark matter to measure it. You look at the visible stars and ask what would have to be true for them to move the way they move. The same reading works on a graph. Look at a developer's public contributions through a period when their private work got heavy. The side projects thin out first. Then the weekend commits stop. Then [the open-source flares](https://codexstellarum.com/blog/the-commons), the pull request to a library they use, the fix to someone else's documentation, go dark. The public sky dims in a particular way, and the way it dims tells you something. We have written about [the dark spaces](https://codexstellarum.com/blog/the-dark-spaces) on a graph before. This one has a cause you can name. That bending is the gravity of work you cannot see. A public graph that goes quiet after dense early years usually belongs to someone whose mass has moved somewhere the instrument cannot point. There are other signatures. A developer whose public contributions are all reviews and no commits is often someone whose commits go elsewhere. A public graph that switches on every August and December, and only then, belongs to someone who codes in public only on holiday, because the rest of the year the code belongs to an employer. The private work never reaches the graph. The hole it leaves does. ## WHAT THE ATLAS CAN DRAW Codex Stellarum draws what the GitHub API returns. If private contributions are switched off, the atlas shows only the public light. If they are switched on, the anonymised counts join the sky as stars like any other, unnamed, which on a star chart is how most stars are anyway. We could pretend otherwise. We could estimate, extrapolate, fill the halo with invented stars so the sky looks fuller. We do not, for the same reason [the stats panel on every atlas](https://codexstellarum.com/blog/how-we-built-codex-stellarum) shows fewer numbers than it could: a number we cannot defend does not belong on the page. But a sky drawn from visible light alone is still a true instrument. Rubin's rotation curve was drawn from visible stars and it measured the invisible ones. An atlas of your public work does the same. Anyone who knows how to read it will see the dense early years, the point where the public light dimmed, the particular shape of the dimming, and will understand that the mass did not disappear. It went dark. ## THE HALO Every developer carries a halo of work that does not shine. The years at the company whose name is on the CV and whose code is in a vault. The product that reached a million people and was never open. The system that runs a hospital, an airline, a payment rail, and that no public profile will ever mention. Zwicky's cluster held together because of mass nobody could see. So does a career. Most of what you have built is invisible. The sky still bends around it. See the visible part. Enter your GitHub username at codexstellarum.com and preview your atlas - free to try, prints from £25. --- # Data Visualization as Art: A Short History of Beautiful Information URL: https://codexstellarum.com/blog/data-visualization-as-art Published: 2026-05-14 · Updated: 2026-05-14 Author: Codex Stellarum In the spring of 1858, a thirty-eight-year-old woman in London sat down with a stack of military death registers and a set of coloured inks. She had spent the previous two years in Scutari, watching soldiers die not from Russian bullets but from cholera, typhus, and dysentery in the British army's own hospitals. The numbers were damning. Nobody in Westminster wanted to read them. So Florence Nightingale drew a rose. What we now call her *coxcomb diagram* is a circle of twelve wedges, one for each month of the war, each wedge fanned into coloured layers showing the relative scale of preventable deaths, wounds, and other causes. It is a piece of statistics. It is also a piece of design. The blue petals - deaths from infection - balloon out of the page like a slow, accusing bloom. You cannot look at it and not understand. That was the point. Nightingale sent copies to Queen Victoria, to the War Office, to every member of Parliament she could reach. Sanitary reform followed. The first great work of data visualisation art was a weapon. ## The lineage We tend to talk about data visualisation as if it were invented in the 1990s by a Tufte disciple with a copy of Adobe Illustrator. It was not. The instinct to turn numbers into shapes - to make information legible by making it beautiful - is one of the oldest moves in the human repertoire. The Babylonian star catalogues were data visualisation. The medieval *zonal maps*, dividing the world into climatic bands, were data visualisation. The Mercator projection of 1569 was an act of statistical compression that distorted the planet into something a sailor could use. But the modern lineage - the line that runs from Nightingale to your GitHub contribution graph - really begins about thirty years earlier than her rose, in the offices of a French civil engineer named Charles Joseph Minard. ## Minard's march In 1869, the year before he died, Minard published a single sheet of paper now considered by many statisticians to be the most beautiful information graphic ever made. Edward Tufte called it "the best statistical graphic ever drawn." It is one image, drawn in two colours, depicting Napoleon's 1812 march on Moscow. A thick beige band leaves Poland carrying 422,000 men. As it advances east, the band narrows. Each man lost is a sliver of width subtracted from the line. The band reaches Moscow shrunken to 100,000. Then the army turns back. The return march is drawn in black, narrowing further at every river crossing - the Berezina, the Dnieper - until what staggers home is a black thread of 10,000 men. Beneath the route, Minard drew a temperature scale. The black band of the retreat is annotated, in neat engineer's script, with the falling temperatures: minus twenty, minus thirty Reaumur. You watch an army die from cold and starvation in a single image. Six variables - longitude, latitude, army size, direction, temperature, time - resolved into a shape so legible that a child can read it. This is data visualisation as elegy. It is also data visualisation as art. The sheet has been reproduced and hung in galleries for a century and a half. People who do not know what a statistic is have stood in front of it and wept. ## Tufte and the discipline of less A hundred and fifty years later, in 1983, a Yale political scientist named Edward Tufte self-published a book called *The Visual Display of Quantitative Information*. He had to mortgage his house to print it. Within a decade it was the bible of the field. Tufte's central argument was a moral one disguised as a design one. He coined the term *chartjunk* for the gratuitous decoration that infested the business graphics of the 1970s - the 3D pie charts, the cartoon men holding bars, the glossy fades. Each piece of decoration, he argued, was theft. It stole attention from the data. The job of the visualiser was to maximise what he called the *data-ink ratio*: the proportion of the ink on the page that actually carries information. From this discipline came one of the most quietly influential ideas in twentieth-century design: the *small multiple*. A grid of identical small charts, varying only by one dimension, that lets the eye compare across many series at once. Weather data by city. Stock prices by company. Bird populations by year. The small multiple is what makes the GitHub contribution grid legible. Fifty-two columns, seven rows, one variable per cell. Tufte would have approved. ## From public data to personal data For most of its history, the data being visualised was public. Census records. Mortality tables. Trade flows. The viewer was a civil servant or a scientist, and the goal was policy or knowledge. Around the year 2010, something shifted. Aaron Koblin, a young artist working with the Aaron Draplin school of restraint, took the FAA's flight tracking data for a single day - around 140,000 flights criss-crossing North America - and rendered it as a still and a video. The image is unforgettable. The continent is dark. The flight paths are thin lines of light. They braid themselves into hubs at Atlanta and Chicago and Dallas, then unravel into the dark. You are looking at a system - air travel - drawn, for the first time, by itself. Koblin's *Flight Patterns* hangs in the permanent collection of MoMA. A few years later, Giorgia Lupi and Stefanie Posavec began a year-long correspondence they called *Dear Data*. Each week they would pick a theme - mirrors looked into, doors held open, smiles received from strangers - track it for seven days, and visualise it on the back of a postcard. The postcards were posted across the Atlantic and back. The result, eventually published as a book, is data visualisation in its most intimate possible form. A week of one woman's anxieties, drawn as a constellation of coloured dots. A week of another's library habits, drawn as a forest of branching lines. The data was nobody's but theirs. The art was for everyone. ## The quantified self as portraiture By the late 2010s, the move from public data to personal data had escaped the art world entirely. Spotify Wrapped arrived in 2016. Strava heatmaps. Apple's activity rings. The Oura ring. The Whoop strap. Suddenly every consumer technology product had a visualisation layer, and every visualisation layer had the same implicit promise: *here is a portrait of you, drawn from what you actually did*. This is a deeper thing than it first appears. For most of human history, a portrait was made by a painter who looked at you. Then, briefly, by a photographer. Now it is made by a sensor that watched you while you were not looking - your phone counting steps in your pocket, your laptop logging keystrokes, your music app remembering every late-night song. The portrait that emerges is more honest than any painted one, because you did not pose for it. You did not even know it was being drawn. When Spotify Wrapped lands in your inbox in early December, you do not really need it to tell you what you listened to. You were there. You played the songs. What it gives you is the shape of the year - the genres, the hours, the unlikely repeat of a track you'd forgotten you loved in March. It is your year, drawn from outside. People share their Wrapped not because they need to brag about taste, but because the shape itself feels like a likeness. The contribution graph belongs in this lineage. So does the running heatmap. So does the sleep chart. They are all small, honest portraits drawn by sensors that were already paying attention. ## The atlas Which brings us, eventually, to why we built [Codex Stellarum](https://codexstellarum.com/about). There is a particular variety of data visualisation that resists the screen. The Minard map was meant for paper. Nightingale's rose was meant for paper. The medieval star atlases - the *Uranometria*, the *Atlas Coelestis* - were meant for paper, bound in vellum, opened on a desk under a candle. Some information wants to be held still. Some wants to be hung. The GitHub contribution grid, in its native habitat, is a small green rectangle behind a username. It is honest data. It is also designed for a tab you close in thirty seconds. We started Codex Stellarum because we believed there was a richer object hiding inside it - the same data, treated with the dignity of a four-hundred-year-old star atlas. Our [contribution charts](https://codexstellarum.com/) are not screenshots of the green grid. They are redrawings of the same underlying data in the visual language of celestial cartography: stars sized by activity, constellations by week, the year's rhythm laid out the way Bayer laid out Orion in 1603. We are, we hope, doing something Nightingale and Minard would have recognised. Taking a record that already existed. Rendering it in a form that asks to be looked at slowly. Letting the shape do the arguing. ## Coda Data visualisation is older than the computer, older than the printing press, older than the alphabet. It is one of the things humans do when they want to be understood. The best of it - the rose, the march, the *Dear Data* postcards, the small green grid that quietly logged the years of your working life - is also art, in the only sense of the word that matters: it makes you stop, it makes you see, and it does not let you forget. If you would like to see your own data given that treatment, [point us at your GitHub](https://codexstellarum.com/) and we will draw your sky. --- # What Archaeologists Will Think URL: https://codexstellarum.com/blog/what-archaeologists-will-think Published: 2026-05-08 · Updated: 2026-05-10 Author: Codex Stellarum Somewhere in the year 3026, a researcher sits down with a dataset. The dataset is old. Not old the way a government report from last decade is old. Old the way a manuscript is old. The data was created by people who have been dead for centuries, working in languages that no longer execute on any living machine, building systems that stopped running before anyone alive was born. The researcher is a digital archaeologist. She studies the labour patterns of early computational civilisations. Her particular speciality is the period between roughly 2008 and 2040 - the three decades during which a single platform called GitHub served as the primary repository for a profession that no longer exists in any recognisable form. She does not understand the code. Nobody does. The programming languages of the early 21st century are as dead as Sumerian. There are translation tools, but they are approximate, the way our translations of Linear B are approximate. The syntax can be parsed. The intent is often opaque. Why did this person write this function? What problem were they solving? The comments, where they exist, are in natural languages that have since merged and shifted beyond easy comprehension. The variable names are abbreviations of abbreviations of words that meant something once. But she does not need the code. She has the [contribution graphs](https://codexstellarum.com/blog/the-shape-of-your-code). --- ## THE TABLETS In 1929, a German archaeologist named Julius Jordan unearthed a collection of clay tablets in the ruins of Uruk, in what was once Mesopotamia. The tablets were roughly 5,000 years old. They were covered in small, wedge-shaped marks - cuneiform - and for years, nobody could read them. When they were finally deciphered, the tablets turned out to be neither poetry nor prayer. They were accounting records. Grain deliveries. Labour allocations. Lists of workers and the tasks they performed on specific days. The most ancient surviving documents in human history are, essentially, a contribution graph. Who worked. When. How much. The archaeologists who studied those tablets did not need to understand the Sumerian economy to learn from them. The patterns told the story. The seasonal rhythms of agricultural labour. The administrative hierarchy implied by who assigned the work and who performed it. The scale of the operation - hundreds of workers, coordinated across weeks, producing surpluses that allowed a civilisation to build temples and invent writing in the first place. The clay tablets of Uruk are the oldest records of human work. The [contribution graphs](https://codexstellarum.com/blog/the-shape-of-your-code) of GitHub may be the most comprehensive. --- ## THE ARCHIVE Our researcher in 3026 has access to a dataset that no previous generation of archaeologists could have imagined. Not a few hundred tablets from a single city. Hundreds of millions of individual work records, spanning every inhabited continent, covering three decades, documenting a labour force that operated simultaneously across every timezone on the planet. Each record is sparse. A username. A date. A count. How many times this person contributed to a shared project on this day. No wages, no job titles, no performance reviews. Just the bare fact of work performed, day by day, for years. It is, she reflects, almost comically minimal. The Sumerian tablets recorded what was produced - thirty bushels of barley, six jugs of beer. These records say only that something happened. A contribution was made. The content of the contribution is stored elsewhere in the archive, in the code itself, but the graph strips it down to the simplest possible signal. This person worked today. This person did not. And yet the patterns are extraordinarily rich. --- ## THE RHYTHMS The first thing she notices is the weekly cycle. Across the entire dataset, contributions drop sharply on two consecutive days out of every seven. The pattern is so consistent, across so many millions of users, that it can only be structural. Some kind of mandated rest period. She cross-references with the calendar systems of the era and confirms: Saturday and Sunday. A religious and cultural institution, originally rooted in monotheistic Sabbath traditions, that had become a universal labour norm by the 21st century. But not universal. A significant minority of users show no weekly cycle at all. They work every day, or they work on patterns that have no seven-day structure. Some of these are in geographic regions where the Saturday-Sunday convention did not apply. Some appear to be working on personal projects - the contribution patterns are different from those associated with organisational work. More erratic. More intense in short bursts. The kind of pattern you see when someone is building something because they want to, not because they are told to. She catalogues the weekly patterns and labels them. The Five-Day Worker. The Seven-Day Builder. The Weekend Warrior (sparse on weekdays, dense on the rest days). The Nocturnal (contributions clustered in the small hours of the local timezone). Each pattern tells her something about the structure of the person's life without knowing a single biographical fact about them. --- ## THE SEASONS Zooming out, she finds annual rhythms. A dip in late December across the Northern Hemisphere dataset, consistent with the major winter holiday period. A smaller dip in August, concentrated in European users, corresponding to summer leave. Spikes in January - new projects, new resolutions, the annual burst of ambition that follows a rest period. She finds fiscal rhythms too. Quarterly spikes in contributions, particularly among users associated with large organisations. The pattern is unmistakable: a surge of activity in the final weeks before a quarter ends, followed by a brief lull, then another build toward the next deadline. She recognises this pattern from other archaeological contexts. It is the same rhythm visible in construction records from Roman military camps - intense work before an inspection, followed by a pause. Bureaucratic time has always shaped labour. And then there is 2020. --- ## THE ANOMALY In March 2020, the dataset shows something she has never seen in any other period. A simultaneous, global disruption in contribution patterns. Not a dip - the opposite. An enormous, sustained surge in activity across virtually every geographic region and every type of user, beginning in the same week and lasting for months. She cross-references with the historical record and finds the pandemic. A respiratory virus that forced billions of people into their homes for extended periods. The contribution graphs tell the story from the workers' perspective: isolated, confined, many of them suddenly working without commutes or office interruptions, pouring that reclaimed time into code. But the graphs also show something the historical record emphasises less. Alongside the surge in professional contributions, there is an explosion of new users. People who had never contributed before suddenly appearing in the dataset. Tens of thousands of first-ever contributions in a single month. She hypothesises that the confinement drove people to learn new skills, and that programming - accessible from any home computer, requiring no physical materials, offering immediate feedback - was a natural choice. The pandemic, read through contribution graphs, is not primarily a story of illness and disruption. It is a story of a species that, when confined, began to build. --- ## THE ORGANISATIONS She identifies organisations by clustering users who contribute to the same repositories. The clusters reveal internal structures. A small number of users who contribute to almost everything - she labels these "architects" or "leads." A larger number who contribute intensely to one or two repositories - the specialists. A periphery of users who contribute rarely but whose contributions, when they come, touch many repositories simultaneously - the reviewers, the integrators. The birth and death of organisations is visible in the data. A cluster forms: two or three users, working on the same repositories, contributions increasing in frequency. More users join. The cluster grows. The contribution density peaks - the shipping period, she assumes. Then the pattern changes. Key users leave (their contributions to the cluster's repositories stop; contributions to other repositories begin). The remaining users' activity declines. Eventually the cluster goes dark. She has seen this pattern before. It is the lifecycle of a settlement. Foundation, growth, peak, decline, abandonment. The same arc visible in every Roman fort, every medieval village, every frontier town. The organisations of the early software era lived and died on the same curve, just faster. A settlement took generations to rise and fall. A software organisation could do it in three years. --- ## THE INDIVIDUAL She picks one user at random. A username that means nothing to her. She traces the contribution graph from beginning to end. The first contributions appear in 2014. They are sparse and irregular. A few contributions per month, scattered unevenly. The pattern of someone learning. Tentative. Experimental. Long gaps between bursts of activity, as if the person kept picking the thing up and putting it down again. In 2016, the pattern changes. The contributions become regular. Five days a week. Consistent density. The person has entered the workforce, or at least entered a routine. The learning phase is over. This is professional output. In 2018, there is an intensification. The density doubles. The weekend contributions begin. Something happened - a promotion, a product launch, a startup, an obsession. Whatever it was, this person was consumed by it for roughly nine months. Then a [gap](https://codexstellarum.com/blog/the-dark-spaces). Three weeks of nothing in early 2019. She has seen this pattern before in other users. It is either illness, a holiday, or a layoff. When the contributions resume, the density is lower than before. The intensity of 2018 did not return. Something ended. The next two years are steady. Professional pace. Weekly cycles. Annual rhythms. Then 2020, and like millions of others, this person's graph surges. The pandemic effect. The surge lasts longer than average - nearly a year of elevated output. She wonders if this person was alone during the confinement. The graph suggests someone who filled the hours with work. In 2022, the contributions begin to thin. Not a sudden stop. A gradual fading. Fewer days per week. Shorter bursts. The pattern of someone stepping back - into management, perhaps, or into a different kind of work that does not leave traces in the contribution graph. By 2024, the graph is sparse. A few contributions per month. By 2026, the last star. One final contribution, unremarkable, identical to thousands of others. Then nothing. She does not know this person's name (the username is not a name). She does not know what they built. She does not know whether they were happy. She knows only that they [learned, then laboured, then burned bright](https://codexstellarum.com/blog/moments-in-a-developers-career-worth-marking), then rested, then faded. It is, she thinks, a life. Compressed to its simplest signal. The archaeological minimum. And yet it is enough to see the shape of it. --- ## THE MEDIUM The Sumerian tablets survived 5,000 years because clay is durable and the desert is dry. The question of whether the GitHub dataset will survive 1,000 years is not trivial. Digital storage degrades. Formats become unreadable. Platforms shut down. Companies go bankrupt. The average lifespan of a website is roughly three years. The average lifespan of a digital storage medium is roughly ten. The entire digital infrastructure of the early 21st century is, from an archival perspective, built on sand. And yet the data persists. Not because the storage is durable, but because the data is copied so many times, across so many machines, in so many jurisdictions, that total loss becomes statistically improbable. The Sumerian tablets survived through material permanence. The GitHub data will survive, if it survives, through redundancy. A different preservation strategy, but possibly a more resilient one. Our researcher does not care about preservation theory. She has the data. That is enough. But she does note, in her research journal, that the people who created this data almost certainly did not imagine anyone looking at it a thousand years later. They were writing code, not making artefacts. They were solving problems, not leaving monuments. The Sumerians did not know they were creating the oldest documents in human history. They were counting grain. The developers of the early 21st century did not know they were creating the most comprehensive labour record in archaeological history. They were closing tickets. The most important archives are almost always accidental. --- ## WHAT SURVIVES She finishes her analysis and sits back. The dataset has told her things that no other source could. That a global civilisation coordinated intellectual labour across every timezone, continuously, for decades. That the labour force was self-organising - millions of people contributing to shared projects without central direction, in a pattern that resembles no previous economic structure. That the work was both professional and personal, often simultaneously, with no clear boundary between the two. That the workers experienced the same rhythms of ambition, exhaustion, recovery, and reinvention that every labouring population in history has experienced. That [the pandemic changed everything about how they worked](https://codexstellarum.com/blog/the-commons) but nothing about why. She does not know what any of the code does. She does not need to. The patterns are enough. In the end, what survives a thousand years is never the work itself. The Sumerian grain was eaten. The Roman forts crumbled. The medieval manuscripts rotted. What survives is the record of the work. The evidence that someone showed up, day after day, and did something they believed mattered. A contribution graph is that evidence. Every developer alive today is leaving one behind. A tiny, [accidental monument](https://codexstellarum.com/). A record that says nothing about what they built and everything about the fact that they built it. One day, someone will read these records the way we read cuneiform. They will not understand the code. But they will recognise the patterns. The dedication. The obsession. The rest. The return. They will see the shape of lives lived in labour, and they will know us by our rhythms. --- # Your GitHub Wrapped - But Permanent URL: https://codexstellarum.com/blog/github-wrapped-but-permanent Published: 2026-05-05 · Updated: 2026-09-24 Author: Codex Stellarum Every December, something strange happens. Half the internet posts the same thing. Not a meme. Not a trend. A data report. Spotify Wrapped lands, and within hours, 600 million people are sharing screenshots of their most-streamed songs, their total minutes listened, their "listening personality." People who have never voluntarily opened a spreadsheet are suddenly proud of their data. They are not sharing music recommendations. They are sharing proof of who they are. The formula is simple and devastating: take data someone generated passively, reflect it back to them in a beautiful wrapper, and watch them tell everyone about it. It works because it makes the invisible visible. You did not set out to listen to 47,000 minutes of music this year. But you did, and now that you can see it, you feel something. Pride, maybe. Surprise. Nostalgia for the playlist you played on repeat during that difficult month in March. Developers have their own version of this data. It is called a contribution graph. --- ## THE DEVELOPER'S DATA PORTRAIT Your GitHub [contribution graph](https://codexstellarum.com/blog/the-shape-of-your-code) is arguably more personal than your Spotify Wrapped. Your music taste is influenced by algorithms, playlists, moods, whatever was trending. Your contribution graph is pure. Nobody else pushed those commits. Nobody else reviewed that code at 2am on a Sunday. Nobody else took that [three-week break](https://codexstellarum.com/blog/the-dark-spaces) in August when the project was killing you. A contribution graph is a record of labour. Not curated, not algorithmic, not performative. Just the days you showed up and the days you did not. Every December and January, the developer community builds its own version of Wrapped. GitHub used to ship a "Year in Review." Third-party tools generate contribution summaries. People screenshot their graphs and post them. There is clearly an appetite for seeing the year reflected back. But here is what none of those versions do: they disappear. ## THE EPHEMERALITY PROBLEM Spotify Wrapped lasts 48 hours. By January 2nd, nobody is looking at it. The screenshots vanish into camera rolls. The Instagram Stories expire. The data was emotional for a moment and then it was gone. GitHub's own review features come and go. Third-party tools shut down or change their APIs. The screenshot you took of your 2021 contribution graph is buried somewhere in your photos between a picture of your lunch and a screenshot of a Wi-Fi password. This is the core tension: the data is deeply personal, the emotion is real, and the format is disposable. Spotify understood something important - that personal data, presented beautifully, becomes identity. But they built it for engagement, not for permanence. You are meant to share it, feel something, and come back next year. What if the developer version was built for permanence instead? ## WHAT WRAPPED GETS RIGHT Before we talk about what is missing, it is worth understanding why Wrapped works so well. Researchers at the intersection of psychology and data visualisation have identified three things that make personal data emotionally resonant. First, reflection. The data has to show you something you already did but did not consciously track. You knew you listened to a lot of jazz this year. You did not know it was 3,400 hours. The gap between vague awareness and specific data creates a small shock of recognition. Second, narrative. Raw numbers are not emotional. "You made 1,247 contributions" means nothing by itself. But "your longest streak was 34 days in October, right before the product launch" tells a story. The data needs to become a timeline you can walk through and remember. Third, aesthetics. This is the part most developer tools get wrong. The data has to look good enough that sharing it feels like showing off, not like filing a report. Spotify spends months on the visual design of Wrapped. The gradients, the animations, the typography - all of it exists to make the data feel worthy of a wall, or at least an Instagram story. Your contribution graph, as GitHub displays it, fails on the third point. The green squares are functional. They are not beautiful. They were designed to be a dashboard widget, not a data portrait. Nobody frames a dashboard widget. ## THE GAP BETWEEN DATA AND OBJECT This is the space [Codex Stellarum](https://codexstellarum.com/) occupies. Take the same data - every day you contributed to a repository, weighted by intensity - and apply the logic of Wrapped but with a different time horizon. Not one year. Every year. Not a digital card that expires. A physical object that stays. Instead of green squares, render the data as a star field. Each day becomes a star. Busy days are large and bright. Quiet days are small and faint. The whole pattern is mapped onto a layout drawn from 17th-century celestial cartography - the [Planisphere's](https://codexstellarum.com/blog/the-planisphere-layout) concentric rings, the [Chronicle's](https://codexstellarum.com/blog/the-chronicle-layout) vertical timeline, the [Helix's](https://codexstellarum.com/blog/the-helix-layout) spiral arm. The result looks nothing like a GitHub page. It looks like something from an observatory archive. Your partner sees it and thinks it is a star chart. Your parents see it and think it came from a museum. The developer who lives in your house knows better - those are not random stars. Those are commits. This is what Wrapped would look like if it was built by cartographers instead of growth marketers. The same emotional core - your data, reflected back to you, made visible and beautiful - but rendered as something you keep rather than something you share and forget. If you want the longer argument for why [personal data is emotional](https://codexstellarum.com/blog/your-data-your-mirror), we have written about that elsewhere. The short version is that we are wired to find ourselves in patterns, and a contribution graph is one of the most honest patterns a working life produces. ## WHY DECEMBER IS NOT THE ONLY MOMENT Wrapped trained us to think about personal data once a year. But your contribution graph is not seasonal. The story it tells does not reset in January. The most interesting patterns in a developer's history span years, not months. The slow ramp-up when you were learning to code. The intense burst when you co-founded a startup. The quiet year when you moved into management. The gap when you [burned out and the return](https://codexstellarum.com/blog/the-dark-spaces) when you recovered. A single year of data is a chapter. The full history is the book. This is why Codex Stellarum renders your [entire contribution history](https://codexstellarum.com/about) by default, not just the last twelve months. The Wrapped format is powerful, but it is artificially constrained. Your data does not stop being meaningful because the calendar turned over. A developer who has been coding for eight years has eight years of story compressed into a single atlas. The Helix layout spirals outward from the centre, year by year, like a galaxy arm. The quiet centre where you were just starting. The dense outer rings where you hit your stride. The whole arc of a career, visible at a glance. No screenshot does that. No year-in-review does that. No Wrapped does that. ## THE PERMANENCE QUESTION There is a reason Spotify Wrapped is digital and ephemeral. Spotify wants you to come back. The transience is a feature, not a bug. If your Wrapped lasted forever, you would not need next year's. A contribution graph is different. It is cumulative. It only gets richer with time. The atlas you generate today will look different in five years - more stars, more patterns, more story. But the one you print today captures a specific moment in your career, a snapshot of everything you have built up to this point. This is the argument for permanence. Not because digital is bad, but because some data deserves to outlast the platform it lives on. GitHub might redesign the profile page. They might change how contributions are counted. They might not exist in twenty years. Your career will. A giclée print on 200gsm archival matte paper is designed to last decades. The data it represents - your work, your rhythm, your years of showing up - deserves at least that. ## WHAT COMES AFTER WRAPPED Spotify proved that personal data is emotional. GitHub proved that contribution data is personal. The missing piece was always the format. A grid of green squares is a dashboard. A screenshot is disposable. A year-in-review is ephemeral. A star atlas printed on archival paper and hung on a wall is something else entirely. It is the version of Wrapped that does not expire. The version that your guests ask about. The version that still means something in ten years. Your code deserves better than a disappearing story. --- # The 10 Moments in a Developer's Career Worth Marking URL: https://codexstellarum.com/blog/moments-in-a-developers-career-worth-marking Published: 2026-05-05 · Updated: 2026-05-04 Author: Codex Stellarum Not every milestone comes with a ceremony. Lawyers get called to the bar. Doctors take an oath. Architects see buildings with their name on the plans. Developers ship code into production and the only evidence it happened is a green tick in CI and a Slack thread that scrolls off the screen by Tuesday. The profession has no tradition of marking things. No diploma on the wall when you close your first ticket. No framed certificate when your code handles its first million requests. The work is invisible, and so are the moments that define a career. Here are ten of them. Some you have already passed without noticing. Some are ahead of you. All of them deserve more than a merged pull request and a thumbs-up emoji. --- ## 1. THE FIRST COMMIT Not the first good commit. Not the first clean commit. The first one. The one with the terrible variable names and the code that technically works but would make your future self wince. It does not matter what it contained. It matters that you pressed the button and put something into the world that was not there before. Most developers cannot find their first commit anymore. The repository is archived, the account is deleted, the bootcamp project is long gone. The ones who can find it treat it like a baby photo - embarrassing and irreplaceable. ## 2. THE FIRST PRODUCTION DEPLOY There is a specific kind of fear that only comes from knowing real people are about to use something you built. The staging environment was fine. The tests passed. But production is different. Production has strangers in it. The first time you deploy to production and nothing breaks, you feel invincible. The first time you deploy and something does break, you learn more in four hours than you did in four months. Both versions of this moment are worth remembering. ## 3. THE CAREER SWITCH Not everyone starts as a developer. Some people arrive from finance, from teaching, from nursing, from kitchens, from the military. They spend evenings after work learning syntax. They spend weekends building projects nobody will see. They apply for jobs and get rejected and apply again. The day they land their first developer role is one of the most significant professional transitions a person can make. It rarely gets celebrated properly. A Slack welcome message and a laptop on a desk. That is usually it. This moment deserves [something on the wall](https://codexstellarum.com/). Not because the job is prestigious, but because the journey to get there was hard and private and mostly invisible to everyone except the person who did it. ## 4. SHIPPING 1.0 Every product has a moment where it stops being a project and starts being a thing. Version 1.0. The first time users who are not your friends or colleagues encounter what you built. The gap between 0.9 and 1.0 is not technical. It is emotional. It is the decision to stop adding features and start letting strangers judge your work. Most developers remember the week they shipped 1.0 more vividly than they remember the year of work that preceded it. ## 5. THE MASS DELETION At some point in every developer''s career, they delete more code than they write. Not because the code was bad - though sometimes it was - but because they finally understand that less is more. That the best pull request they ever opened removed 3,000 lines and added 200. This is a maturity marker. Junior developers measure progress in lines written. Senior developers measure progress in lines removed. The contribution graph gets quieter in the weeks of a mass deletion, but the codebase gets better. The quiet weeks on an atlas are often the most important ones. ## 6. THE OPEN SOURCE CONTRIBUTION The first time you submit a pull request to a project you did not create. A project maintained by strangers, used by thousands, governed by norms you do not fully understand yet. You read the contribution guide three times. You lint your code twice. You write a commit message that is longer than the change itself. When it gets merged, your code is running on machines you will never see, in countries you have never visited, solving problems for people you will never meet. There is no other profession where a single afternoon of work can scale like that. ## 7. THE DECADE MARK Ten years of contributions. Ten years of mass deletions and mass creations. Ten years of languages learned and abandoned, frameworks adopted and deprecated, companies joined and left. A decade of [contribution history](https://codexstellarum.com/blog/the-shape-of-your-code) contains entire chapters of a life - visible not in the code itself, but in the rhythm of the graph. The decade mark rarely arrives with fanfare. There is no notification. No badge. No ceremony. One day you look at your profile and realise the grid stretches back further than you thought possible. You have been doing this for a third of your adult life, and the only record of it is a pattern of coloured squares on a website. ## 8. THE LEADERSHIP TRANSITION The day your job stops being about writing code and starts being about enabling other people to write code. You go from maker to multiplier. Your own contribution graph gets sparser, but the graphs of the people around you get denser. Some developers mourn this transition. They miss the craft, the direct contact with the machine, the satisfaction of a passing test suite. Others discover that watching a team ship something extraordinary is its own kind of reward. Either way, the graph tells the story. The dense years of individual contribution give way to the quiet years of leadership, and both halves together are the [atlas](https://codexstellarum.com/about). ## 9. THE DEPARTURE Leaving a company where you built something significant. The last commit to a codebase you know better than anyone. The code will outlive your tenure - other people will maintain it, refactor it, eventually replace it. But for a period of time, it was yours. Developers rarely get leaving gifts that acknowledge what they actually did. A card, maybe. A voucher. Nothing that says "you built the authentication system that 200,000 people use every day and it has not gone down in three years." The departure is one of the most under-celebrated moments in a developer''s career. The work stays behind. The person walks out with nothing but experience. ## 10. THE RETURN Some developers leave the profession entirely. They burn out, they pivot, they take years away to raise children or travel or recover. And then they come back. They open the laptop, create a new repository, and write their first commit in months or years. The return is visible on the atlas as a gap followed by new light. A dark stretch - sometimes weeks, sometimes years - and then the stars begin again. It is one of the most human patterns in a contribution graph. Not the consistency of the steady coder or the intensity of the sprinter, but the resilience of someone who stopped and chose to start again. --- ## THE UNMARKED CAREER The problem with developer milestones is not that they do not exist. It is that nobody marks them. Other professions have rituals. Developers have Jira tickets. There is no tradition of saying "you have been writing code for ten years and here is something to show for it." No convention of celebrating a first production deploy the way you would celebrate a first published paper or a first courtroom appearance. The moments come and go, acknowledged with a Slack reaction and forgotten by the next sprint. This is partly a cultural problem and partly a visibility problem. The work is invisible. The milestones are invisible. And so they pass without ceremony, without evidence, without anything on the wall. [Codex Stellarum](https://codexstellarum.com/) exists, in part, because we believe these moments deserve more than that. An atlas of your contributions is not just a print. It is a record. The dense cluster from the month you shipped 1.0. The quiet stretch when you made the leadership transition. The gap and return. The very first star. Every [developer''s sky](https://codexstellarum.com/blog/nothing-to-hold) tells a different story. Most of them have never been told at all. *Marking a milestone with a gift? See our guide to [developer gifts that celebrate the work](https://codexstellarum.com/blog/gifts-for-developers-who-have-everything).* --- # The Best Home Office Decor for Developers Who Work Remotely URL: https://codexstellarum.com/blog/home-office-decor-for-developers Published: 2026-04-25 · Updated: 2026-04-29 Author: Codex Stellarum You have optimised your development environment. Your terminal is configured. Your IDE theme is perfect. Your keyboard switches are exactly right. You have spent real money and real time making the digital workspace feel like yours. Now look up from the screen. Look at the room. Bare walls. Overhead light. Maybe a cable tray you installed last year. A mug. The room where you spend eight to twelve hours a day looks like a holding cell with better Wi-Fi. This is normal for developers. We obsess over the tools and ignore the room. The argument is always the same: "I am looking at the screen, not the walls." But that is not entirely true. You look up when you think. You look around when you are stuck. You lean back when you are waiting for a build. The room is your peripheral vision for most of your waking life. It should be better than bare drywall. This is not a list of things to buy from a home decor catalogue. This is what actually works in a room where someone builds software all day. --- ## THE WALLS The walls are the biggest missed opportunity in most developer home offices. Here is what works. ### Something personal, not decorative Generic art does nothing for a room you spend this much time in. You stop seeing it within a week. What works is something with meaning - something you look at and it connects to who you are or what you have done. One option we are obviously biased about: your own coding history rendered as a star atlas. Every day you wrote code becomes a star on a vintage celestial chart. It looks like something from an observatory. Visitors see beautiful wall art. You see fifteen years of your career. That dual reading - beautiful to strangers, deeply personal to you - is what makes it work in a home office that doubles as a living space. But the principle applies beyond our product. Anything that is specific to you will outlast anything that is generic. A framed print of the first architecture diagram you ever drew. A photograph from a conference that changed how you think. A map of the city where you got your first job. Specificity is what makes wall art last in a room you never leave. Prints from £25. Digital downloads £10. codexstellarum.com ### Maps and technical drawings Developers tend to love maps. Not motivational posters, not abstract art - maps. Topographic maps, vintage city plans, nautical charts, transit diagrams, circuit schematics. The appeal is the same thing that draws us to code: systems, structure, information encoded in visual form. The Library of Congress has tens of thousands of high-resolution map scans available for free download. Find one that means something to you - your hometown in 1890, a nautical chart of somewhere you sailed, a Cold War era aviation map - and print it at a local shop. A large framed vintage map costs £30-60 to produce and gives the room more character than anything from IKEA. ### One large piece, not many small ones A common mistake is putting too many things on the walls. Six small frames, a clock, a whiteboard, some postcards. The room feels cluttered and none of the individual pieces have presence. One large piece on the main wall does more work than ten small ones scattered around. It gives the room a centre of gravity. It gives your eye somewhere to rest that is not the screen. Pick one thing, make it big, give it a good frame, and leave the other walls quiet. --- ## LIGHTING This is where most developer home offices fail hardest. The standard setup: an overhead ceiling light and the glow of the monitor. This is terrible. The overhead light creates glare on the screen. The monitor is the brightest thing in the room, which means your eyes are constantly adjusting between a bright rectangle and a dim room. After eight hours, your eyes are exhausted and you do not know why. The fix is not complicated. ### Bias lighting behind the monitor A strip of LED lights stuck to the back of your monitor. This sounds silly. It is transformative. The light fills the wall behind the screen and reduces the contrast between the bright display and the dark room. Eye strain drops noticeably within the first day. A basic LED strip costs £10-20. Stick it to the back of your monitor, plug it in, forget about it. Your eyes will thank you by 4pm. ### A desk lamp that is not overhead Replace the ceiling light with a good desk lamp. Ideally one with adjustable colour temperature - warm light (2700K) for evening work, neutral light (4000K) for daytime. The BenQ ScreenBar sits on top of your monitor and lights your desk without creating screen glare. Around £90 and worth every penny if you work long hours. ### Kill the overhead light Seriously. Turn it off. Use the bias lighting plus the desk lamp. The room immediately feels less like a fluorescent office and more like a space you chose to be in. --- ## THE DESK SURFACE Your desk probably has: a monitor, a keyboard, a mouse, a laptop, and too many cables. Maybe a coffee mug. It is functional and lifeless. Small things make a difference. ### A desk mat A large felt or leather desk mat defines the working zone and makes the surface feel intentional. It also protects the desk, dampens keyboard noise, and gives the mouse a consistent surface. A good wool felt mat costs £20-40 and lasts years. ### One plant A single plant on the desk changes the entire feeling of the space. Not because of any productivity study or air quality benefit - because it is alive. Everything else on the desk is a tool. The plant is just there, quietly existing, growing whether or not you shipped the feature. A pothos in a ceramic pot. A small snake plant. A ZZ plant. Anything that survives irregular watering. Cost: £10-20. Impact: disproportionate. ### A notebook and pen that deserve to be there Most developers have a cheap notebook somewhere near the desk. Replace it with one that is nice enough to leave out - a Leuchtturm1917 dot grid, a Midori MD, a Baron Fig Confidant. Pair it with a pen that writes well. The combination costs £25-35 and turns a hidden tool into a desk object. --- ## SOUND Remote developers rarely think about the sound of their room. But you sit in it all day. The acoustics matter. ### Soft surfaces absorb echo A room with hard walls, a hard floor, and a hard desk sounds echoey and cold. You notice it on video calls - that hollow, reverberant quality that makes you sound like you are in a bathroom. A rug on the floor, a fabric chair, a bookshelf full of books, curtains instead of blinds - these all absorb sound and make the room feel warmer, both acoustically and psychologically. You do not need acoustic panels unless you are recording a podcast. You just need soft things in the room. ### Music or silence, but choose deliberately Some developers work better with music. Some with silence. Most work with whatever happens to be playing, which is neither music nor silence but ambient noise that they have stopped noticing. If you use music, invest in the speaker or the headphones. A single good speaker (Sonos Era, HomePod, KEF LSX) fills a small room and makes music feel present rather than tinny. If you use silence, the noise-cancelling headphones are the investment. --- ## THE SHELF A bookshelf in a home office is not just storage. It is the room's personality. Fill it with things that are real. Technical books you actually read. Non-technical books that shaped how you think. Conference badges. A terrible trophy from a hackathon. The Raspberry Pi project you never finished. An old mechanical keyboard you cannot throw away. The shelf is the part of the room that tells a visitor who you are. It should not be curated like a showroom. It should look like a developer's shelf - a mix of precision and chaos. --- ## THE VIDEO CALL BACKGROUND Let us talk about the elephant in the room. A significant portion of your home office's visual impact is not experienced by you. It is experienced by your colleagues on video calls. Most developers use a virtual background or a blur filter because their real background is a mess. This is a shame, because a real background with real objects in it - a bookshelf, a framed print, a plant - creates warmth and presence that a blurred wall cannot. Think about what sits behind you on camera. A single framed atlas print, a shelf with books, good lighting - that is all it takes to go from "person in a room" to "person in a space they care about." Your colleagues notice. Your clients notice. You notice, even if you cannot see it yourself. --- ## WHAT NOT TO DO Do not buy LED strip lights around the ceiling perimeter that change colour. They look like a gaming setup, not a professional workspace. Fine if you are nineteen. Less fine if you are on a client call. Do not put up motivational posters. "Hustle" and "Grind" on the wall of the room where you already spend too many hours is not inspiring. It is depressing. Do not buy everything at once. The best home offices develop over time. One good piece of wall art now. Better lighting next month. A plant the month after. The room should accrete personality, not arrive fully decorated like a hotel. --- ## THE ROOM DESERVES ATTENTION You have spent hundreds of hours configuring your development environment. Your dotfiles are versioned. Your terminal prompt is perfect. Your window management is automatic. Spend ten percent of that energy on the room the screen sits in. The returns are not measurable in the way developers like to measure things. They are felt. The room is warmer. The light is better. The wall has something on it that means something. You look up from the screen and the space looks back at you like somewhere you chose to be. That matters. Especially when you never leave. --- Your home office wall deserves more than bare paint. See your coding history as a star atlas. Free to preview, prints from £25. codexstellarum.com Write about remote work or developer life? Join our affiliate programme - 25% revenue share, 10% off for your audience. *Shopping for a developer? See our list of [unconventional gifts for programmers](https://codexstellarum.com/blog/gifts-for-developers-who-have-everything).* --- # How to Turn Your GitHub Contributions into Art URL: https://codexstellarum.com/blog/how-to-turn-github-contributions-into-art Published: 2026-04-21 · Updated: 2026-09-21 Author: Codex Stellarum Somewhere in your GitHub profile is a grid of green squares that represents every day you wrote code. It is probably the most complete record of your working life that exists, and it lives on a webpage that you glance at occasionally and nobody else ever sees. Getting it off the screen and onto a wall is not a new idea. Developers have been printing contribution graphs for years. But the options range from free and rough to polished and expensive, and nobody has written a proper comparison of what is actually out there. This is that comparison. Every option, what it costs, what it looks like, and who it is for. --- ## OPTION 1: DO IT YOURSELF You are a developer. You could build this. The GitHub API gives you everything you need. Hit the GraphQL API or scrape your contribution calendar, extract the data, map it to colours, render it as an SVG or canvas image, and send it to a print shop. You have done harder things before lunch. In practice, it takes longer than you think. The contribution data is straightforward. The rendering is straightforward. But getting it to actually look good on paper - choosing the right resolution, the right colour mapping, the right paper stock, handling the DPI conversion, adding margins for framing, making it not look like a homework assignment - that is where the weekend goes. We know because we tried. The first version of Codex Stellarum was a manual job. Fetch the data, write a renderer, tweak the output, order a test print, realise the colours look different on paper than on screen, adjust, reprint. It took longer than expected. The result was worth it, but the process was not something we would recommend to someone who just wants a nice print on their wall by Friday. That said, if you enjoy the process - if building the renderer is part of the fun - then do it yourself. You will learn things about print design, colour spaces, and DPI that you did not know you did not know. And the result will be entirely yours. Cost: Free (plus printing, usually £10-30 at a local print shop). Time: A weekend if you are fast. Longer if you care about the details. Result: Whatever you make it. Could be terrible. Could be beautiful. Depends on you. --- ## OPTION 2: SCREENSHOT AND PRINT The simplest possible approach. Go to your GitHub profile, take a screenshot of your contribution graph, crop it, and upload it to a poster printing service like Photobox, Shutterfly, or your local print shop. This costs almost nothing and takes five minutes. The result is exactly what you would expect: a screenshot on a poster. It looks like a screenshot on a poster. The resolution is usually poor because the contribution graph on screen is not very large, so when you blow it up to poster size you get visible pixels. If you just want something on the wall and you do not care about quality, this works. If you are giving it as a gift, the recipient will see the effort you put in, which is to say: almost none. That might be fine. It might not. Cost: £5-15. Time: Five minutes. Result: A blurry screenshot on paper. --- ## OPTION 3: REDBUBBLE AND GENERIC PRINT-ON-DEMAND Redbubble, Etsy, and similar marketplaces have independent artists selling GitHub-themed prints. Some are generic - a stock contribution graph with no personalisation. Some are slightly customised. The quality varies wildly. Some sellers use thick, archival paper. Others use the cheapest stock available. The designs tend toward the playful and geeky - bright colours, comic-style layouts, "I code therefore I am" text overlays. The main limitation is personalisation. Most of these are not your contribution graph. They are a contribution graph. A generic pattern that represents the concept of coding, not your specific history. Some sellers will create a custom print from your data for an extra fee, but the turnaround time is usually a week or more and the quality is inconsistent. Cost: £10-40 depending on size and seller. Time: A few days to a couple of weeks. Result: Generic developer-themed wall art. Fun, but not personal. --- ## OPTION 4: CODEPRINTS CodePrints (codeprints.dev) is probably the best-known service for printing GitHub contribution graphs. You enter your username, they generate a poster of your green grid, and you order a print. They have been around since 2019 and have built a solid product. The prints are good quality. They offer framed and unframed options. The contribution graph is rendered clearly and accurately. GitLab and Bitbucket support is listed as coming soon on their site. The design is faithful to the original GitHub aesthetic: a grid of coloured squares on a dark or light background. If you want your actual GitHub graph on your wall, recognisable as a GitHub graph, this is the best way to get it. Their team prints feature is also solid - you can generate a poster from a shared repository. The trade-off is that it looks like what it is: a GitHub contribution graph. Developers recognise it instantly. Non-developers see a grid of coloured squares and ask what it is. It is wall art for the home office, not the living room. And there is nothing wrong with that - it just depends on where you want to hang it. Cost: From about €25 for a poster, from €49 framed or on canvas. Time: 1-2 weeks delivery. Result: A clean, well-made print of your GitHub grid. Recognisably GitHub. --- ## OPTION 5: COMMITGRAPH / BITTI GITTI CommitGraph takes a different approach. Instead of a poster, they laser-engrave your contribution graph onto wooden objects - phone amplifiers, desk blocks, acrylic prints. The wooden phone amplifier is their signature product: a handcrafted speaker that passively amplifies your phone''s sound, with your contribution graph engraved on the side. It is a genuinely interesting object. The craftsmanship is real. As a desk piece it works well - functional, personal, and a conversation starter. The limitation is the same as CodePrints: the visual language is the GitHub grid. Squares. Green. Recognisably a developer thing. For wall art specifically, their acrylic block prints are the relevant product. They look clean and modern but are relatively small. Cost: From about $75 for the wooden amplifier, $45-60 for acrylic blocks. Time: 1-3 weeks. Result: A physical object with your grid engraved. Unique. Desk-friendly. --- ## OPTION 6: CODEX STELLARUM This is us, so take this section with the appropriate grain of salt. Codex Stellarum takes your contribution data and renders it as a vintage star atlas. Every day you wrote code becomes a star. Bright days are large and luminous. Quiet days are small and faint. The pattern of your coding history appears as a celestial chart - the kind of thing you would see in a seventeenth-century observatory or a rare book collection. Three layouts: Chronicle (a vertical timeline of years), Planisphere (concentric rings), and Helix (a spiralling galaxy). Four themes: Observatory (gold on navy), Blueprint (white on deep blue), Parchment (dark on aged paper), and Minimalist (clean, modern). Your name is rendered in Latin small caps. A magnitude legend shows the star scale. Coordinate markings frame the border. The prints are produced on 200gsm enhanced matte art paper using Giclee technique - the same archival process used by galleries. We also offer digital downloads as high-resolution PNG files if you want to handle your own printing. The thing that makes this different from every other option on this list is that it does not look like a GitHub page. A developer will see their commit history in it. Everyone else will see a beautiful star chart. It works in a living room, an office, a hallway. It does not require an explanation. We also build organisation atlases - aggregating all public repository activity across a company into a single print. And we offer bulk pricing for teams. Cost: From £25 for prints, £10 for digital download. Time: Digital downloads delivered in minutes via email. Prints ship in 5-14 days. Result: Your contribution data rendered as astronomical art. Unrecognisable as a GitHub graph. --- ## SO WHICH ONE? It depends on what you want. If you want a fun project and you enjoy building things: do it yourself. The process is the point. If you want something quick and free and you do not care about quality: screenshot and print. If you want your GitHub grid on the wall, faithfully reproduced: CodePrints. If you want a unique desk object: CommitGraph. If you want something that looks like art first and data second - something a non-developer would hang in their home without knowing what it represents: Codex Stellarum. The real question is not which service to use. It is what you want people to see when they look at your wall. A grid of green squares that says "I am a developer." Or a sky full of stars that says "something beautiful happened here." --- See what your contributions look like as a star atlas. Free to preview. codexstellarum.com Write about developers or developer tools? Join our affiliate programme - 25% revenue share, 10% off for your audience. --- # Office Art for Engineering Teams That Is Not a Motivational Poster URL: https://codexstellarum.com/blog/office-art-for-engineering-teams Published: 2026-04-18 · Updated: 2026-04-29 Author: Codex Stellarum Walk through the engineering floor of most tech companies and you will see the same things. Whiteboards covered in half-erased architecture diagrams. Monitors. Cable management that started well and gave up somewhere around desk seven. And on the walls, if there is anything at all: a motivational poster. Maybe two. "Move Fast and Break Things." "Keep Calm and Deploy On." A framed company value that HR ordered in bulk. A poster of a mountain with the word PERSEVERANCE underneath it. Nobody looks at them. Nobody has looked at them in years. They are wallpaper in the most literal sense - they fill a space without adding anything to it. This is a guide for the person who has been asked to "make the office feel better" and does not want to order another batch of inspirational quotes from a catalogue. --- ## WHY ENGINEERING OFFICES LOOK THE WAY THEY DO There is a reason most engineering spaces are bare. Developers do not decorate. It is not that they do not care about their environment - they absolutely do. They will spend three weeks choosing the right keyboard. They will debate monitor arms with the intensity of medieval theologians. The physical tools of the work are obsessed over. But the walls? The walls are someone else's problem. Facilities. Office management. The person who orders the snacks. And that person, understandably, defaults to what is easy: motivational posters, branded prints, stock photography of diverse teams high-fiving in a conference room. The result is an office that feels like it was decorated by an algorithm. Functional. Inoffensive. Completely devoid of personality. --- ## WHAT ACTUALLY WORKS The best engineering offices we have seen share one thing: the art on the walls is specific to the people in the room. Not generic. Not inspirational. Specific. Here is what that looks like in practice. --- ## 1. DATA FROM YOUR OWN TEAM, RENDERED AS ART This is what we do at Codex Stellarum. Take your team's actual GitHub contribution data and render it as a vintage star atlas - each day of code becomes a star, bright days burn large, quiet days are faint, and the pattern of someone's working life becomes a celestial chart. Hang one for each engineer on the team. Every print is unique because every developer has a different pattern. The developer sees their own story in it. Everyone else sees beautiful wall art that looks like it belongs in an observatory. The effect in an office is striking. A row of framed atlases along a corridor, each one different, each one labelled with a name. Visitors ask about them. New hires see them on day one and immediately understand: this company pays attention to the people who build things here. For engineering teams we offer bulk pricing - 15% off for 10-24 prints, 25% off for 25 or more. Every atlas is unique to the individual. We handle the rendering, printing, and shipping. You just send us a list of GitHub usernames. We also build organisation atlases - a single print that aggregates the commit activity across all of a company's public repositories. Every star is a week someone on the team shipped code. It is the company's engineering heartbeat, visualised. One print that represents everyone. Prints from £25 per person. codexstellarum.com/business --- ## 2. YOUR OWN ARCHITECTURE, DRAWN PROPERLY Every engineering team has architecture diagrams. They live on whiteboards, in Miro boards, in forgotten Confluence pages. They are functional. They are ugly. Hire an illustrator to take your actual system architecture and render it beautifully. Not a simplified marketing version - the real thing. Services, databases, queues, caches, the works. But drawn with care. Clean lines, thoughtful layout, real typography. Printed large, framed, hung in the main engineering area. Developers will stand in front of it and argue about whether the arrows are right. That is the point. It is art that is also documentation. It starts conversations about the system. New engineers study it during their first week. Cost: £500-2000 depending on the illustrator and complexity. Worth it for the years of use you will get from it. --- ## 3. MAPS Not metaphorical maps. Actual maps. Engineers love maps. Topographic maps. Vintage city maps. Nautical charts. London Underground schematics. Circuit board layouts that happen to look like city plans. NASA mission trajectory diagrams. Maps work in engineering offices because they share a visual grammar with the work: systems, connections, nodes, paths, scale. A 1960s Apollo trajectory map on the wall of an engineering floor does not need a caption. Everyone in the room understands it intuitively. Search for vintage maps and technical diagrams on shops like Old Maps Online, the Library of Congress digital archive (free high-resolution downloads), or specialist print shops. A large framed vintage map of your city - the real one, from 1890, not a tourist poster - costs £50-150 and gives the space more character than any motivational quote. --- ## 4. THE TEAM TIMELINE Create a physical timeline on one wall. Start from the company's founding. Mark every major milestone: first commit, first customer, first outage, first million users, the migration that took six months, the rewrite everyone argued about, the feature that changed everything. Make it honest. Include the failures. Include the incidents. The deploy that took down production for four hours. The security scare. The feature that shipped and nobody used. These are the stories the team actually tells each other - they should be on the wall. This does not need to be expensive. A long strip of quality paper, good typography, printed at a local print shop. Or painted directly on the wall. Update it when something worth remembering happens. The timeline does something no poster can do: it tells the team its own story. New hires read it and understand the culture. Veterans see it and remember what they have built together. --- ## 5. PHOTOGRAPHY OF YOUR PRODUCT IN THE WILD If your product has physical manifestations - users, locations, devices, real-world impact - photograph them and put them on the wall. A fintech company could frame a photo of the first merchant using their payment terminal. A mapping company could print satellite imagery of areas their users have mapped. A health tech company could show the clinics using their software. Engineers rarely see the impact of their work. The code they write disappears into a deploy pipeline and becomes invisible. Photographs of the end result - real people using the thing they built - are powerful. Not stock photos. Real photos. Specific. Named. Dated. If your product is purely digital, screenshot the moments that matter. The first user signup. The Slack message when you hit a million requests. The pull request that fixed the bug that had been open for two years. Print them. Frame them. They are your history. --- ## 6. ACTUAL ART BY ACTUAL ARTISTS This sounds obvious but it almost never happens in tech offices. Instead of buying mass-produced prints from a corporate art catalogue, commission local artists. Give them a brief that connects to your work without being literal. A cybersecurity company could commission abstract pieces about boundaries and intrusion. A data company could commission visualisations of large datasets. An AI company could commission work about the relationship between human and machine perception. The art does not need to be expensive. Local art school graduates, printmakers, illustrators - many will create original pieces for a few hundred pounds. The result is something no other office has. Something with a story. Something real. --- ## WHAT NOT TO DO A short list of things to avoid. Do not buy "tech-themed" wall art from Amazon. Prints of binary code, circuit board patterns, or the word "INNOVATION" in a futuristic font. Your engineers see technology all day. They do not want to stare at a decorative version of it when they look up from their screens. Do not put the company logo on everything. One logo in the reception is fine. A logo on every wall of every floor is not branding - it is insecurity. Do not buy art by committee. If you ask twenty engineers what art they want on the walls, you will get twenty different answers and settle on something nobody loves. Give the task to one person with good taste and a budget. Let them make decisions. The worst office art is art chosen by consensus. --- ## THE REAL TEST Here is how you know if your office art is working: do people stop and look at it? Not on the first day, when everything is new. On the hundredth day. On a Tuesday afternoon when they are walking to the kitchen. Do they glance at the wall and see something that makes them pause, even for a second? Motivational posters fail this test immediately. They are invisible by week two. The best office art passes it for years. It rewards repeat viewing. It has detail. It has a story. It is specific to the people in the room. Your engineering team built something worth caring about. The walls should reflect that. --- Want personalised atlas prints for your engineering team? Bulk pricing from £19 per print. Get a quote Write about office culture or engineering teams? Join our affiliate programme - 25% revenue share, 10% off for your audience. *Buying for an engineer? See [gifts for software engineers who have everything](https://codexstellarum.com/blog/gifts-for-developers-who-have-everything).* --- # Why We Built Codex Stellarum URL: https://codexstellarum.com/blog/why-we-built-codex-stellarum Published: 2026-04-11 · Updated: 2026-04-29 Author: Codex Stellarum It started with a gift for a friend. She had spent the last two years teaching herself to code - evenings after work, weekends, online courses, side projects, the slow and unglamorous process of switching careers. She had just landed her first developer role after years in a completely different industry. We wanted to give her something that marked the moment. Something that said: the work you put in to get here was real, and it mattered. We searched. We found services that print your GitHub contribution graph. Green squares on a poster. Some offered different colour schemes. Some put it on a mug. We ordered one. It arrived. It was fine. The print quality was decent. The data was accurate. But when we held it up and imagined it on a wall - a living room wall, an office wall, a wall that guests would see - something felt off. It looked like a screenshot. A nicely printed screenshot, yes. But still recognisably a grid of coloured squares from a website. It belonged in a developer cave, next to the rubber ducks and the "there is no place like 127.0.0.1" poster. It did not belong in a living room. It did not belong in a frame next to actual art. So we built one ourselves. Manually. We took her contribution data and rendered it as a star atlas - every day a star, bright days large, quiet days faint, the whole pattern mapped onto a vintage celestial chart. We printed it on archival paper, framed it, and gave it to her. She liked it. But it was his reaction that stopped us. Her boyfriend - who had no idea what GitHub was, who had never seen a contribution graph, who could not tell Python from JavaScript - looked at it and said: "That is beautiful. That is going on the wall." Her parents said the same thing. They saw a star chart. They saw something that looked like it belonged in a museum. They had no idea it was made from code. That reaction made us think: if the people who do not understand the work respond like this, maybe we have built something worth sharing. So we built Codex Stellarum to make it available to everyone. Not because the existing products were bad - they are not - but because we wanted something different. Something that a non-developer would look at and say "that is stunning" before they understood what it represented. --- ## THE QUESTION THAT STARTED EVERYTHING The question was simple: what if contribution data was not displayed as a grid, but as a sky? Astronomers have been mapping stars for four hundred years. The star atlases of the seventeenth and eighteenth centuries - Bayer's Uranometria, Flamsteed's Atlas Coelestis, Cellarius's Harmonia Macrocosmica - are among the most beautiful documents ever printed. Copper-engraved, hand-lettered, precise and ornate. They hang in museums today not because the astronomical data is still useful, but because the craft of rendering that data was extraordinary. What if we applied that same philosophy to code? What if every day a developer wrote code became a star - bright days large and luminous, quiet days small and faint - and the whole pattern was rendered in the language of celestial cartography? Not a graph. Not a chart. An atlas. --- ## THE DIFFERENCE There are good products that print GitHub contribution data. CodePrints is probably the best known. They have been around for years, they have a loyal community, and they do what they do well. If you want your green grid printed on quality paper, they are a solid choice. But they are solving a different problem. They are making the contribution graph physical. We are making it invisible. When you look at a CodePrints poster, you know immediately what it is. The grid is recognisable. The squares are familiar. A developer sees it and thinks "that is a GitHub contribution graph." A non-developer sees it and thinks "that is something from a computer." When you look at a Codex Stellarum atlas, you see a star chart. You see constellations of light on a dark sky. You see something that looks like it belongs in an observatory or a cartography museum. A non-developer sees it and thinks "that is beautiful." A developer sees it and thinks "wait - those are my commits." That gap - between "that is from a computer" and "that is beautiful" - is the entire reason Codex Stellarum exists. --- ## WHAT WE CHANGED Everything about the rendering is different. The visual language. Contribution data is mapped onto three astronomical layouts. The Chronicle arranges time as a vertical celestial timeline. The Planisphere renders years as concentric rings on a circular star map. The Helix spirals through time like a galaxy arm. None of them look like a GitHub page. All of them look like something you would find in a rare book collection. The typography. Every atlas uses period-appropriate lettering. Latin inscriptions. Small capitals. The kind of typography you see on eighteenth-century engravings, not on a SaaS dashboard. The developer's name is rendered as if they were a celestial body being catalogued for the first time. The themes. Four palettes, each inspired by a different era of astronomical illustration. Observatory, with its warm gold stars on deep navy. Blueprint, recalling cyanotype technical drawings. Parchment, evoking hand-drawn manuscript charts. Minimalist, for those who prefer clean modern lines. None of them are green. The detail. A magnitude legend in Latin. Coordinate markings around the border. The developer's GitHub URL rendered in the style of a plate inscription. Every element is designed to reward close inspection - the kind of print where you notice something new the third time you look at it. The paper. Printed on 200gsm enhanced matte art paper using Giclee technique - the same archival process used by galleries and museums. These prints are designed to last decades, not years. --- ## WHO THIS IS FOR CodePrints is a great gift for a developer from a developer. You both know what the grid means. The green squares are a shared language. It is a fun, geeky piece of wall decor and there is nothing wrong with that. Codex Stellarum is for a different moment. It is for when you want the gift to transcend the profession. When you want it on the living room wall, not just the home office. When you want guests to ask "what is that?" and the answer to start a conversation rather than require a technical explanation. It is for the developer who has spent a decade building things and has nothing physical to show for it. It is for the partner who wants to say "I see how hard you work" in a language that does not require understanding what an API is. It is for the engineering leader who wants something on the office wall that represents the team's work without looking like a dashboard. It is, in the end, for the wall. Not the developer cave wall. The real wall. The one everyone sees. --- ## THE GIFT We gave our friend the atlas the week she started her new role. Helix layout, observatory theme, two years of contributions spiralling outward like a galaxy. Every evening she had spent learning, every weekend project, every tentative first commit - all of it rendered as stars. She did not say "cool print." She stared at it. She found the dense cluster from the month she built her first full-stack app. She found the quiet stretch from the winter she almost gave up. She found the burst of activity right before the job interviews started. But it was not her reaction that confirmed we had built the right thing. It was his. He walked in, saw it leaning against the wall, and said: "Where are we hanging that?" Not "what is that." Not "is that a computer thing." Just: where are we hanging that. That is what we wanted. That is why we built it. Not a better contribution print. A different kind of object entirely. Something worthy of the work. --- See your own sky. Free to preview, prints from £25. codexstellarum.com Write about developers or developer culture? Join our affiliate programme - 25% revenue share, 10% off for your audience. --- # The Dark Spaces URL: https://codexstellarum.com/blog/the-dark-spaces Published: 2026-04-07 · Updated: 2026-04-28 Author: Codex Stellarum Look at your GitHub contribution graph long enough and your eye does something strange. It stops seeing the green. It starts seeing the gaps. The two weeks in March with nothing. The entire month of August that is nearly blank. The quarter where the grid fades from dense to scattered to dark. Your eye finds these absences the way a tongue finds a missing tooth. You know what goes there. You know why it is empty. Other people just see a gap. You see a story. --- ## THE ANATOMY OF ABSENCE Software developers are not assembly-line workers. Their output is not constant. It is not supposed to be. The contribution graph implies otherwise - a grid demanding to be filled, a streak begging not to be broken, a colour scale that treats zero commits as failure and twelve as success. But zero is not failure. Zero is often the most important number on the graph. Zero is the week you quit your job. Zero is the month after your child was born. Zero is the burnout you did not see coming until you were already in it. Zero is the conference where you gave a talk instead of writing code. Zero is the vacation you almost did not take. Zero is grief. Every atlas has dark spaces. They are not errors. They are the record of a life being lived around the code. --- ## THE BURNOUT GAP There is a specific pattern that developers who have experienced burnout recognise instantly. The graph is dense - intensely, almost aggressively dense - for months. Seven days a week. Late-night commits. Weekend pushes. The green is so dark it is almost black. And then, abruptly, it stops. Not tapers. Stops. The gap that follows is usually two to six weeks. Sometimes longer. It is the crash after the sprint that never ended. The body and mind forcing a shutdown that the developer would never have chosen voluntarily. When the commits return, they come back differently. Lighter. More spread out. Weekends are blank again. The colour is pale green, not dark. Something has changed. The developer learned something that cannot be expressed in code. On a star atlas, this pattern is unmistakable. A cluster of bright, dense stars - an almost solid mass of light - followed by a void, followed by scattered, gentler stars. It looks like a stellar explosion and its aftermath. Which, in a way, it is. --- ## THE JOB CHANGE Another recognisable gap: the job change. The last two weeks at the old company are sparse - you are wrapping up, handing over, saying goodbye. Then a gap of one to three weeks. Admin. Onboarding paperwork. Setting up a new laptop. Learning where the coffee machine is. Then a burst. The first commits at the new job. New repositories. New patterns. Sometimes the entire visual language of the graph changes - different repos, different rhythms, different commit habits. The developer before the gap and the developer after it are working on different things, often in different ways. On a star atlas, job changes look like a shift in the sky. The constellations change. The brightness might increase or decrease. The spacing shifts. It is a new chapter that begins not with a word, but with silence. --- ## THE SIDE PROJECT BLOOM Some gaps are not absences at all. They are redirections. The developer stops committing to their main repositories. The green squares thin out. To a manager watching the graph, it might look like disengagement. But switch to the "all repositories" view and something else appears: a new repo, started three weeks ago, with intense daily commits. The gap in the professional graph is a bloom in the personal one. The developer is building something of their own. A tool they always wanted. A language they are learning. An idea that grabbed them at 11pm and will not let go. These are the most interesting patterns in a contribution history. Not the steady professional output - that is expected. The sudden, intense, self-directed bursts that appear from nowhere and sometimes change the developer's entire trajectory. Side projects do not ask permission. They just show up on the graph like unexpected stars. --- ## THE LONG SILENCE And then there is the long silence. Six months. A year. The graph is not just sparse - it is empty. No commits at all for a stretch that, in the rhythmic language of the contribution grid, feels enormous. Long silences have a thousand causes. Illness. Caregiving. A non-coding role. A company that uses Bitbucket. Depression. A deliberate break. The graph does not explain. It simply records the absence. What matters is what comes after. When the commits return after a long silence, they carry a weight that recent commits do not. Each green square is a small declaration: I am here again. I am building again. Whatever happened, I came back. On a star atlas, a long silence is a stretch of dark sky. And the stars that follow it glow with particular brightness. Not because they represent more commits, but because the eye has adjusted to the darkness. Contrast makes them radiant. --- ## WHAT THE ATLAS SEES A GitHub contribution graph treats every day equally. A green square is a green square. The grid is democratic and indifferent. A star atlas is different. It takes the same data and renders it in a medium that invites interpretation. Stars have magnitude. They have position. They have the space between them. A cluster of bright stars surrounded by darkness tells a different story than a uniform scattering of equal light. When someone generates their atlas and sees their own dark spaces rendered as voids between constellations, something shifts. The gaps stop feeling like failure. They start feeling like structure. Every sky needs darkness. Without it, you cannot see the stars. The most beautiful atlases we have generated are not the densest ones. They are the ones with contrast. Bright periods separated by intentional silence. Bursts followed by rest. Activity that breathes. A perfectly filled graph is a fluorescent ceiling. A graph with rhythm and space is a night sky. --- ## THE PERMISSION There is something to be said - and it is rarely said in developer culture - for the dark spaces. Contribution streaks are celebrated. GitHub itself gamifies consistency. The message is implicit but clear: more is better, unbroken is best, and a gap is a streak broken. But the developers whose atlases look most striking, most beautiful, most like something you would want on your wall - they are the ones who stopped sometimes. Who had seasons. Who built intensely, rested, built again. Whose graphs have the rhythm of actual creative work, not the rhythm of a machine. Your dark spaces are not blemishes on your record. They are part of the composition. They are what give the bright periods their meaning. They belong on the atlas. --- Every sky needs darkness. See yours → Write about developers? Join our affiliate programme - 25% revenue share, 10% off for your audience. --- # The Commons URL: https://codexstellarum.com/blog/the-commons Published: 2026-04-04 · Updated: 2026-04-28 Author: Codex Stellarum There is a mass of people alive right now who, on any given Tuesday evening, will open a laptop, navigate to a repository they do not own, and write code for free. No one asked them to. No one is paying them. The code they write will be used by strangers in countries they will never visit, in products they will never see, to solve problems they will never know existed. They will receive, in return, a green square on a grid that no one outside their profession understands. This is open source. It is the largest collaborative project in human history, and we talk about it as if it were normal. --- ## THE CATHEDRAL AND THE BAZAAR In 1997, Eric Raymond published an essay that described two models of software development. The cathedral: a small group of architects building in private, revealing the finished work when it is ready. The bazaar: a chaotic, public process where anyone can contribute, inspect, or argue. He was describing Linux. But he was also describing something older. The bazaar model is how science worked before journals locked it behind paywalls. It is how cities were built before urban planning. It is how language evolves - collectively, messily, without anyone in charge. Open source did not invent this. It rediscovered it. --- ## WHAT THE GRAPH SHOWS When you generate a Codex Stellarum atlas for a prolific open-source contributor, something specific happens. The graph is dense. Not dense in the way a startup founder's graph is dense - concentrated bursts of intense activity on a single project. Open-source contributors have a different pattern. It is broad. Consistent. Spread across months and years like a low, constant hum. This is the signature of maintenance. Of someone who shows up, week after week, to review pull requests, fix edge cases, update dependencies, respond to issues filed by strangers at 3am in a timezone twelve hours away. It is the least glamorous work in software. It is also the most important. --- ## THE GIFT ECONOMY Anthropologists have a term for economies where goods are given without explicit expectation of return: gift economies. Marcel Mauss wrote about them in 1925. Potlatch ceremonies of the Pacific Northwest. Kula ring exchanges in Melanesia. Systems where giving creates social bonds stronger than any contract. Open source is a gift economy operating at planetary scale. A developer in São Paulo fixes a bug in a library maintained by someone in Helsinki. A student in Lagos writes documentation for a framework built by a team in San Francisco. Nobody signs anything. Nobody invoices anyone. And yet the system works - not despite the absence of contracts, but because of it. The green squares on a contribution graph are the record of these gifts. Each one is a small act of generosity disguised as a commit. --- ## THE INVISIBLE INFRASTRUCTURE Every time you use a banking app, book a flight, send a message, or read the news, you are standing on open source. The web server is probably Nginx or Apache. The database is probably PostgreSQL or MySQL. The programming language is probably Python, JavaScript, or Go - all open source. The operating system running the server is almost certainly Linux. These are not side projects. They are the foundation of the digital economy. And they are maintained, in many cases, by a handful of people who do it because someone has to. The contribution graph of someone who maintains a critical open-source dependency does not look like a founder's graph. It does not have the dramatic peaks and valleys of a startup sprint. It looks like a steady heartbeat. Quiet, persistent, unbroken. The kind of pattern that is easy to take for granted until it stops. --- ## COMPANIES AND THE COMMONS Something interesting happens when you generate an org atlas on Codex Stellarum. You see not just the company's private output, but its public contribution - the code it has chosen to give away. Some companies treat open source strategically: release the framework, sell the hosting. Some treat it as recruitment marketing: look at our engineering culture. Some treat it as genuine contribution: we use these tools, we should help maintain them. You can see which is which. A company that open-sources one flagship project has a graph with a single bright cluster. A company that contributes broadly across the ecosystem has a graph that looks like the individual open-source contributor - wide, steady, distributed. The atlas does not judge which approach is better. But it makes the pattern visible. --- ## WHY PEOPLE DO IT Ask an open-source contributor why they do it and you will get a dozen different answers. For the craft. To learn. To give back. Because it is fun. Because the alternative - closed, proprietary, locked away - feels wrong. Because they used a library once when they were stuck at 2am on a deadline, and it saved them, and they never found out who wrote it, and now they want to be that person for someone else. The reasons are as varied as the people. But the pattern on the graph is consistent: sustained, voluntary, distributed effort over time. It is not the pattern of obligation. It is the pattern of care. --- ## THE RECORD Contribution graphs are imperfect records. They do not capture code review comments, issue triage, community moderation, documentation edits that do not touch code, or the countless hours spent in discussions that shape a project's direction without ever producing a commit. But they capture something. They capture the rhythm. The showing up. The Tuesday evenings and Saturday mornings and lunch breaks spent on code that belongs to everyone and no one. When you render that rhythm as a star atlas - when you see fifteen years of open-source contribution mapped onto a vintage celestial chart - you are looking at something remarkable. Not because the visualisation is clever, but because the underlying behaviour is extraordinary. Thousands of people, working for free, building the commons. And the only record most of them will ever have is a grid of green squares that resets every year. Unless someone charts it among the stars. --- Your open-source contributions deserve more than a green grid. See your sky → Write about developers? Join our affiliate programme - 25% revenue share, 10% off for your audience. --- # The Palimpsest URL: https://codexstellarum.com/blog/the-palimpsest Published: 2026-04-01 · Updated: 2026-03-30 Author: Codex Stellarum In a conservation lab in Washington DC, there is a small book made of goatskin. It measures roughly 18 by 21 centimetres - paperback sized, worn and brown with age. It is called the Codex Climaci Rescriptus, and it has been written on at least twice. The top layer is Syriac: monastic text, the devotional writings of John Climacus, Abbot of Saint Catherine's Monastery in Egypt's Sinai desert, transcribed by a medieval scribe sometime in the 9th or 10th century. Beneath that, nearly invisible, is something else entirely. ## THE ERASED WORLD A palimpsest is a document that has been scraped clean and written over again. The word comes from the Greek - *palin*, meaning again, and *psaō*, meaning to rub away. In the first millennium, parchment was scarce. Papyrus had been overfarmed in Egypt; paper from China had not yet reached the West. So monks scraped the old ink from goatskin and started again. The past was not destroyed so much as buried under the present, which in turn would be buried under whatever came next. The Codex Climaci Rescriptus held nine folios that scholars had suspected contained Greek writing. For decades, no one could read them. The traces were too faint, the erasure too thorough. In 2012, a Cambridge undergraduate named Jamie Klair was examining one of those folios when he noticed something: astronomical content. Not theological commentary, not scripture. Star material. He flagged it, and the slow work of identification began. Years passed. In 2021, Peter Williams first recognised the presence of actual astronomical measurements in the undertext. By 2022, a research team led by Victor Gysembergh at CNRS in Paris had confirmed what those measurements were: fragments from the lost star catalogue of Hipparchus of Nicaea, compiled around 150 BC - the oldest such catalogue in Western history. The text that had been scraped away to make room for a monk's prayers turned out to contain some of the foundational data of astronomy. ## THE ASTRONOMER WHO DISAPPEARED Hipparchus is a figure of peculiar historical tragedy. He is considered the founder of trigonometry and the first in the Western world to attempt a systematic catalogue of the night sky. By Roman accounts, he documented the positions of at least 850 stars. He discovered the precession of the equinoxes. He developed the magnitude scale used to classify stellar brightness that scientists still use today. He was, by any measure, one of the most accomplished observers who ever lived. Almost none of his work survived. What survived instead was the work of Claudius Ptolemy, who came four centuries later and who produced a star catalogue far larger and more famous. For years, scholars had suspected that Ptolemy's catalogue was not original - that it drew heavily, perhaps dishonestly, on Hipparchus. The palimpsest helped settle the debate. When Gysembergh's team compared the newly recovered Hipparchus coordinates with Ptolemy's, they found both agreement and genuine divergence. Ptolemy had used Hipparchus as a source, yes, but also drew on other scholars. "That's not plagiarism, that's science," Gysembergh said. "We still do that today, combining sources to get the best data possible." The deeper point: Hipparchus was not erased by fraud. He was erased by time, by scarcity, by the ordinary processes of knowledge being written over and consolidated. His coordinates survived in Ptolemy's synthesis, unnamed. His work lived on, but his authorship did not. ## HOW LIGHT READS THE PAST The 2022 discovery used multispectral imaging. The 2026 continuation at the Stanford Synchrotron Radiation Lightsource at SLAC went further. The X-ray beams used there are a million times stronger than those in a dentist's office. They do not read ink - they read elements. The scribe who wrote the Syriac overtext used iron-rich ink. The original Greek text beneath used a calcium-based ink. When the X-rays hit the parchment, the calcium signals from the older layer were actually more prominent than the newer writing above it. The erased text was, in a sense, louder than the text that replaced it. The distinction matters: this is physics, not metaphor. The right kind of attention, applied with sufficient precision, can recover what was deliberately removed. The manuscript is now yielding descriptions of constellations, star coordinates, the word for Aquarius. Researchers believe more remains hidden in the folios not yet scanned. The catalogue of Hipparchus - absent from scholarship for two millennia - is being reconstructed, star by star, from the calcium ghosts of a text someone thought they had erased. ## THE DEVELOPER'S PALIMPSEST Every codebase is a palimpsest. New code is written over old code. Refactors bury the original architecture. Libraries replace libraries. The file you are editing today has been rewritten by a dozen hands before yours, and the logic that existed two years ago - the decisions that shaped what you are now changing - is gone from view unless you know where to look. Git preserves commits, yes. But the contribution graph on GitHub shows only the last year by default. Everything before it is buried. The developer who spent three years on the foundation of a system may show up as a thin line in the history, or may not show up at all after the code was migrated, the repo was recreated, the organisation was renamed. Most developers have years of work that has been scraped away and overwritten, invisible unless someone shines the right light on it. The cognitive effect of this is real. When new engineers join a team, they read the current code as if it always existed in this form. They do not see the calcium signature of the original architecture. They do not see the three rewrites, the abandoned patterns, the decisions that were made and reversed. The code they inherit is a surface. The history beneath it is the thing that would actually tell them what they are working with. There is also something more personal in this. A career is not the sum of what is currently deployed. It is the sum of everything ever built - including the things that were replaced, deprecated, migrated away from, or simply forgotten when the company was acquired and the old repos were archived. The palimpsest of a developer's working life is rarely visible to anyone, including the developer. ## WHAT THE X-RAYS DO This is what Codex Stellarum does. Not X-rays - but the same essential act. It takes the full contribution history, not just the last year, and renders it as a permanent record. A star atlas, built from the complete signal of the work, not just the surface that happens to be visible today. The irony is not lost on us that the product shares its name with the artefact. The Codex Climaci Rescriptus is, literally, a codex - a bound manuscript. Codex Stellarum is named for the same idea: a book of stars, a catalogue, a record that survives. What the researchers at SLAC are doing for Hipparchus - recovering authorship from beneath layers of institutional and historical erasure - is precisely the problem that any serious record of a developer's work has to solve. Hipparchus spent decades making careful observations. He was accurate to within a degree, using no instruments more sophisticated than his own eyes and the geometry he had partly invented. He wrote it all down. Then it was scraped away. The light still carries the signal. It just needed someone willing to look. *If you have years of work buried beneath the default view, [Codex Stellarum](https://codexstellarum.com) renders the full record - every contribution, every layer, as a permanent star atlas.* --- # The Commit Graph Is a Self-Portrait URL: https://codexstellarum.com/blog/the-commit-graph-is-a-self-portrait Published: 2026-04-01 · Updated: 2026-03-30 Author: Codex Stellarum In 2015, a group of researchers at Drexel University published a paper with an unsettling claim: they could identify individual programmers by their coding style alone, with over 90% accuracy. Not by what the code did - by how it was written. Variable naming conventions, bracket placement, whitespace habits, comment density. The unconscious fingerprint of the person behind the keyboard. The study analysed code from Google Code Jam, where thousands of developers solve the same problems. Same inputs, same outputs, same constraints. And yet each solution carried a signature as distinctive as handwriting. The researchers called it "code stylometry" - the computational equivalent of identifying an author by their prose. Your commit graph is the same idea, extended through time. --- ## The Temporal Fingerprint A commit graph records when you worked, how intensely, and for how long. It does not record what you built or why. It strips away content and leaves only rhythm - the temporal pattern of a person engaging with their craft over months and years. That pattern is unique. Not approximately unique, not mostly unique - genuinely, statistically unique. The combination of your work hours, your seasonal rhythms, your response to deadlines, your recovery patterns after intense periods, your weekday-to-weekend ratio, your holiday habits - these variables combine into a signature that belongs to you alone. Think about what your graph encodes without your permission. The week you couldn't sleep and committed code at 3am every night. The three-month gap when you changed jobs. The explosive burst when you discovered a new language and rebuilt everything. The slow fade when a project lost funding and the team dissolved. The quiet December when you visited family and didn't touch a keyboard. None of this was deliberate. You were not journalling. You were working. But the graph was watching. ## Behavioural Biometrics The field of behavioural biometrics has been studying this kind of unconscious signature for decades. Keystroke dynamics - the timing pattern of how you type - can identify individuals with remarkable accuracy. Not what you type. How you type. The intervals between keystrokes, the duration of key presses, the rhythm of common letter combinations. Your fingers have a temporal signature that is as stable and individual as your fingerprint. Mouse dynamics work the same way. The speed of your cursor movements, the shape of your curves, your click patterns - all carry identity information you cannot consciously control. What makes these signatures powerful is precisely that they are unconscious. You can change your password. You can disguise your handwriting. But you cannot change the micro-timing of your keystroke patterns any more than you can change your heartbeat. These rhythms emerge from the deep structure of your nervous system. A commit graph is behavioural biometrics at a larger timescale. Instead of milliseconds between keystrokes, it records days between commits. Instead of key press duration, it records work intensity. But the principle is the same - an unconscious, stable, individual pattern that emerges from the act of doing the work, not from any intention to leave a record. ## The Gaps Tell the Story The most revealing parts of a commit graph are not the peaks. They are the gaps. A two-week gap in January is probably a holiday. A six-week gap after years of steady activity is probably a job change. A sudden drop from daily commits to nothing, followed by a slow ramp back up, is probably burnout. A nine-month gap is probably parenthood. These interpretations are not certain - they are probabilistic. But they are surprisingly reliable, because the events that stop someone coding are the same events that reshape their life. Illness, grief, relocation, career change, family. The graph does not know what happened. It knows that something did. For the person whose graph it is, reading these gaps is like flipping through an old photograph album. Each blank stretch triggers a memory. "That was when we moved to Berlin." "That was the month Dad was in hospital." "That was when I quit and spent the summer hiking." The code is forgotten. The gaps remember. ## The Pathology of Streaks In 2016, GitHub quietly removed the streak counter from user profiles. For years, the platform had prominently displayed each user's current streak - the number of consecutive days with at least one contribution. The feature was designed to encourage consistency. It encouraged obsession instead. Developers reported maintaining streaks of 300, 500, even 1,000+ days. They committed code while on holiday. They pushed trivial changes from hospital beds. They wrote meaningless one-line fixes at 11:58pm to keep the counter alive. The streak became the point. The code became the excuse. GitHub's decision to remove the counter was quietly celebrated by developers who had felt enslaved by it. But the removal did not erase the pattern. If you look at a contribution graph from the streak era - roughly 2013 to 2016 - you can spot the streak-maintainers immediately. Their graphs are unnaturally uniform. Every single day is green. No gaps, no weekends, no holidays. It looks less like a developer's work pattern and more like a machine's uptime log. The interesting thing is what happened after the counter disappeared. Most streak-maintainers stopped. Their graphs developed natural gaps - weekends, holidays, quiet periods. The pattern relaxed into something human. The contrast between the streak era and the post-streak era, visible in a single graph, tells a story about motivation, compulsion, and release that the developer might never have articulated in words. The graph saw it. The graph recorded it. The graph remembers. ## Nobody Else's Graph Looks Like Yours There are over 100 million developers on GitHub. Among all of them, the probability that any two share the same temporal pattern across multiple years is vanishingly small. This is not a guess - it follows from the combinatorics. Consider a single year: 365 days, each with a contribution count ranging from 0 to some maximum. Even if you reduce the resolution to just "active or not active" for each day, you get 2^365 possible patterns - a number larger than the estimated number of atoms in the observable universe. In practice, developers' graphs are shaped by timezone, work culture, personal habits, project cadence, and life events. No two combinations of these factors are identical. Your graph is yours the way your face is yours - built from common components, arranged in a combination that belongs to no one else. This is why Codex Stellarum works. We do not add anything to your data. We do not embellish or invent. We take the pattern that already exists - the pattern you created unconsciously over years of work - and render it in a medium that makes its structure visible. ## Reading the Portrait A portrait painter does not invent the subject's face. They observe it, understand its structure, and render it in a medium that reveals what a casual glance might miss. The angle of the jaw, the asymmetry of the eyes, the tension in the mouth. A good portrait shows you something about a face you have seen a thousand times but never truly looked at. The Codex Stellarum layouts do something similar with your commit graph. The Chronicle lays your contributions along a timeline - a narrative reading, left to right, of your working life. The Planisphere wraps them into a circle, revealing seasonal patterns. The Helix spirals through years. The Rosette compresses everything into a mandala. The Horizon and Astrolabe treat each star earned as a point of light. Each layout is a different way of looking at the same face. The data does not change. The angle does. And like a portrait, the result is simultaneously public and private. Other people see a beautiful print on a wall. They see the aesthetic of a star atlas, the vintage typography, the careful composition. They might notice that some areas are brighter than others, some regions dense and some sparse. But the developer sees their life. They see the sprint that nearly broke them and the quiet month that saved them. They see the project that lit them up and the one that burned them out. They see the shape of their working self, rendered in a way they have never seen it before. You did not mean to paint this portrait. You were just doing your job. But every commit was a brushstroke, and the canvas was always watching. --- *See your portrait. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and preview your atlas for free.* --- # Gifts for Developers: The 2026 Guide URL: https://codexstellarum.com/blog/gifts-for-developers-who-have-everything Published: 2026-03-31 · Updated: 2026-09-30 Author: Codex Stellarum Most gift guides for developers are written by people who have never watched a developer open a gift. The ritual is short. The recipient smiles, says thank you, asks where it came from, and then it goes into the corner of the home office where the previous novelty mugs already live. The problem is not ingratitude. Developers, more than most people, have already bought the thing. The keyboard is chosen. The monitor is chosen. The chair, if they cared about the chair, is chosen. What they almost never buy is anything that marks the years of work itself, because years of code leave nothing behind that you can put on a shelf. This guide replaces the four separate lists we used to keep. It is sorted by budget, it says plainly which items are ours, and it ends with what to avoid and the four questions people ask us every December. Every item is something a working developer would keep. ## HOW TO USE THIS GUIDE If you are a developer buying for another developer, start with the under £50 section: switch testers, sponsorships, notebooks, the things you would never buy yourself. If you are a partner or parent who does not fully understand the job, skip to the section written for you further down. If you have a budget and a deadline, the quick picks are next. ## QUICK PICKS Under £30: a mechanical switch tester, a year of a small open-source sponsorship in their name, a hardback that is not about software. Under £100: a Leuchtturm1917 notebook with a Lamy 2000, a YubiKey, a digital download of their GitHub history as a star atlas. Under £300: an archival print of that atlas, a conference ticket, noise-cancelling headphones if they lack them. The big one: a chair. Nothing else on the list changes eight hours a day. ## UNDER £50 ### 1. A mechanical keyboard switch tester A small block holding eight to twelve switches, blue, brown, red, silent red, the increasingly strange boutique ones, so they can press each in turn and feel the difference. Switches are hard to judge from a description and impossible to try without buying a whole keyboard, which is why the developer who already owns a mechanical keyboard has had the "what if I tried different switches" thought and never acted on it. You are giving them permission to fall down a rabbit hole. Keychron and Drop both make decent testers, £15 to £40. ### 2. A sponsorship of a project they depend on Almost every working developer has a list of open-source projects they could not do their job without, and almost none of them have ever sent the maintainers money. A year of a small sponsorship through GitHub Sponsors or Open Collective, in their name, says you understand what their work rests on. Find the project in their starred or pinned repositories. Most starting tiers are £5 to £25 a month. The card is a screenshot of the sponsorship and a line about why you picked it. ### 3. A domain name for the side project they have not started Every developer has a side project, and most have not bought the domain. A domain costs £10 to £30 for a year and is the closest thing on this list to a spell: it turns a vague idea into something with an address. If you do not know the idea, a one-year credit at Namecheap or Porkbun in an envelope marked "for the project" works just as well. ### 4. Their first commit, framed Every developer has a first commit. It usually says "initial commit" or "fix" or, in one famous case from April 2005, Linus Torvalds describing Git as "the information manager from hell". GitHub keeps the whole history: go to their profile, sort repositories by oldest, open the first one, find the first commit. Print the message, the date, the repository name and the hash on good paper and frame it. It is a birth certificate. Around £20 for the print and frame. ### 5. Oblique Strategies A deck of a hundred cards made by Brian Eno and Peter Schmidt in 1975, each with a prompt for breaking a creative block. "Use an old idea." "What would your closest friend do?" Developers get stuck the way musicians do, and tend to push through with force. Pulling a card when an architecture decision will not resolve is a different kind of move. The official deck is matte black, sits well on a desk, and costs £30 to £40. ### 6. A YubiKey Every working developer should have hardware two-factor authentication. Most are still using codes on a phone they have nearly dropped in a coffee. A YubiKey 5 or 5C NFC costs £45 to £55 and sits in the mental folder next to "make a will": something they know they should buy and have not. You are buying it slightly earlier, with the relief of not having to choose a model. ### 7. A book that is not about software The most over-given category for developers is technical books. The most under-given is everything else. The Soul of a New Machine by Tracy Kidder is still the best account of what building something feels like from the inside. Working in Public by Nadia Eghbal explains why the maintainers of the libraries they use are exhausted. The Idea Factory by Jon Gertner is the history of Bell Labs, which is the answer to "how did Unix happen". Hardback, with a card inside. £15 to £25. ### 8. A digital download of their GitHub history as a star atlas This one is ours, so read it knowing that. Codex Stellarum turns a developer's GitHub contribution history into a vintage astronomical chart: every day they wrote code becomes a star, sized by how much they did, arranged on a planisphere like a seventeenth-century atlas. The digital download is £10, arrives by email as a full-resolution file within minutes, and needs only their GitHub username. It is the last-minute gift that does not look last-minute, and the print version below is the same picture on paper. ## UNDER £100 ### 9. A really good notebook and a really good pen Developers turn out to be the most enthusiastic paper users you know. Code is digital, but the thinking that precedes it, the box-and-arrow sketches, the half sentences from a one-to-one, the diagram that finally explains the bug, happens on paper, and most of them do it in whatever notebook was lying around. A Leuchtturm1917 dot grid in A5, or a Midori MD if they are particular about paper, with a Lamy 2000 or a TWSBI Eco fountain pen. £40 to £100 together, and used every day for a year. ### 10. A standing desk mat, not a standing desk If they already have a standing desk they almost certainly do not have a good mat, and standing on a hard floor for hours is bad for knees and backs. The Topo by Ergodriven, about £100, has ridges and contours that keep the feet moving. It is boring. It is the kind of boring-practical thing they will use daily for years and never buy themselves. If they do not have a standing desk, skip it. ### 11. A subscription to something they would feel guilty buying Developers pay for work tools without blinking and feel indulgent about anything else. A year of the London Review of Books or Wired in print, a MUBI subscription, a membership to the gallery they walk past, or a year of one of the small, well-made paid apps: Kagi, Things, iA Writer. £50 to £150, and it arrives gently all year. ### 12. A class in something that is not coding A photography workshop, a pottery class, a knife-sharpening course. Something with their hands, away from a screen, that they would feel self-conscious booking alone. Developers often notice around thirty that every hobby they have involves a laptop. A gifted class is an externally imposed reason to try something physical. Obby and Eventbrite list local ones; £80 to £200 for a half day. ## UNDER £300 ### 13. Their GitHub history as an archival print The same atlas as the download, printed. Museum-grade giclée on 200gsm matte paper, from £25 unframed or £69 framed and ready to hang, in sizes up to 90cm. It is the rare gift the recipient cannot make and would not think to commission, and what makes it personal is not the number of stars but the shape: the gap where they took a holiday, the dense cluster when they shipped the thing, the quiet winter before they changed jobs. Other people see a star chart. The developer sees their life. Preview it free at codexstellarum.com with just their username. If you do not know it, a gift card from codexstellarum.com/gift lets them chart their own sky and choose the print themselves. ### 14. A conference ticket Not a virtual one. A real room full of people who care about the same things, which is rarer than it used to be in a profession that mostly works alone at home. Match it to what they do: RustConf, PyCon, GopherCon, KubeCon, React Summit, LeadDev. Community events can be free; the big ones run £200 to £600. They come back with three ideas and one friend. ### 15. Noise-cancelling headphones, if they do not have them The most-used object in a developer's day after the keyboard. If theirs are more than a few years old or lack noise cancelling, the Sony WH-1000XM6 or Bose QuietComfort Ultra, £300 to £450, change their working life. Check first: if they already own a pair they love, do not replace it. ### 16. A coffee upgrade The cliché is accurate. A Sage or Breville Bambino with a decent grinder gets closer to a café than any pod, and fits a normal kitchen counter, around £300 to £600 for the pair. If they already have an espresso machine, a pour-over kit, a Hario V60 with a good scale and kettle, is about £150 and a different ritual entirely. ## THE BIG ONE ### 17. A chair The single object that affects a developer's quality of life more than any other, and most of them are sitting in something that came with the flat. A Herman Miller Aeron or Steelcase Leap runs £600 to £1,300 new. Refurbished Aerons from corporate liquidators are the same chair at roughly a third of the price and are perfectly fine. This is a once-a-decade gift and the one they will tell friends about for years. If you can, sneak a look at their current chair before deciding. ## FOR THE PARTNER WHO DOES NOT UNDERSTAND THE JOB You have tried. They have explained it three times, something about containers or APIs or "the backend", and you nodded and it did not make sense. You are proud of them anyway. Three gifts work especially well from you, precisely because they are not technical. ### 18. Their work, made visible There is something you may not know about the job: it leaves nothing behind. A carpenter builds a table. A developer writes code for five years and the only visible record is a grid of small green squares on a website called GitHub. The star atlas above exists for exactly this reason, and you do not need to understand any of the code to give it. You need their username, which is on their GitHub profile, and ten seconds. If you cannot find it, send a gift card instead and let them choose. ### 19. A day with no screens Their eyes hurt. Their neck hurts. They know they should take breaks and do not, because the problem is almost solved and they need ten more minutes, which is never ten minutes. Give them a day away, and make it concrete: a booked table in the countryside, a hike with a packed lunch, a cooking class. "We should do something this weekend" will end back at the laptop. "I booked the place on Saturday, we leave at ten" will not. The value is that someone else made the decision. ### 20. A message that is not a gift Developers, especially the ones working from home, can go weeks without anyone acknowledging their work in a personal way. A pull request gets approved. A feature ships. The effort behind it goes unwitnessed by the people closest to them. Tell them you are proud of them, not for a launch or a promotion, just for the work you do not fully understand. You do not need to understand it. You need to see that they do it. ## WHAT TO AVOID A short list of things that reliably disappoint. The coding mug. They have seen every variation of "I turn coffee into code" and they are tired. A coding course. Unless they asked for a specific one, it reads as "I think you need to improve" rather than "I think you are great". Hardware you have not checked. Developers are particular about keyboards, mice and cables. The wrong one is thanked and never used. If you want to buy hardware, ask. Anything with binary on it, novelty language merchandise, USB-shaped objects, and anything described as "smart" that does not need to be. Their job is troubleshooting things like that. A single-board computer they did not ask for. A Raspberry Pi is a wonderful gift when there is a project waiting for it; projects in search of hardware almost never happen. An Amazon gift card. They have Amazon. A gift card to an independent bookshop or a local restaurant is the same money with ten times the warmth. ## FREQUENTLY ASKED QUESTIONS ### What is a unique gift for a programmer? The best unique gifts for programmers honour the work rather than optimise it. A star atlas made from their own GitHub history, their first commit framed, or a sponsorship in their name of a project they depend on all land harder than another mug or hoodie. ### What do software engineers actually want as gifts? Software engineers usually already own the keyboards, monitors and tools they want. What they do not have is anything that marks the years of work itself. Personal artefacts, their first commit framed, their coding history visualised, a notebook that deserves to be left out, tend to mean more than another piece of technology. ### What is a good gift for a developer under £50? A mechanical switch tester, a year of a small open-source sponsorship in their name, a YubiKey, or a digital download of their GitHub history as a star atlas. All four are things they would not buy themselves and will use. ### What is a good last-minute gift for a developer? The digital star atlas. It costs £10, arrives by email within minutes as a full-resolution file, and needs only their GitHub username. It is the rare last-minute gift that does not look like one. If you do not know their username, a gift card arrives by email on the day you choose, even on Christmas morning. ## THE THING ALL OF THESE SHARE Look back at the list. The pattern is not "expensive" or "technical" or "useful". Every gift on it acknowledges that the recipient has a relationship with a screen, hours a day for years, and that the relationship deserves to be honoured rather than optimised. You do not need to understand what they do. You need to notice that they do it, that it costs them time, and that something exists in the world because they sat at that desk. A chair, a notebook, a star atlas, a quiet Saturday: all of them say the same thing in different vocabularies. I see you working. I think it is worth marking. Which is what gifts have always been for. See their sky. Enter their GitHub username at codexstellarum.com and preview the atlas - free to try, digital £10, prints from £25. Or give them a gift card from codexstellarum.com/gift and let them chart it themselves. --- # Four Centuries of Mapping the Sky URL: https://codexstellarum.com/blog/four-centuries-of-mapping-the-sky Published: 2026-03-30 · Updated: 2026-03-24 Author: Codex Stellarum There is a mammoth tusk in a German museum that is 32,500 years old. Carved into the ivory is a pattern of dots that archaeologists believe represents the constellation Orion. If they are right, it is the oldest star map ever found. Humans have been looking up and recording what they see for as long as we have been human. The impulse is always the same: take something vast and incomprehensible, and turn it into something you can hold in your hands. Codex Stellarum exists in that tradition. We are not astronomers. We do not chart the heavens. But we map a different kind of sky - one made of commits and contributions, bright days and dark gaps, scattered across time. The tools are different. The impulse is the same. This is the story of the people who came before us. --- ## The First Star Atlases For most of human history, star maps were functional. Sailors needed them to navigate. Farmers needed them to track the seasons. Priests needed them to predict eclipses and appease their gods. The earliest known accurately dated star chart comes from ancient Egypt, around 1534 BC. The Babylonians compiled star catalogues in the second millennium BC. The Chinese astronomer Shi Shen created detailed star maps during the Warring States period, around 400 BC. These maps were tools. They were not beautiful on purpose. Beauty was a side effect of precision. That changed in 964 AD, when the Persian astronomer Abd al-Rahman al-Sufi published his Book of Fixed Stars. Al-Sufi updated Ptolemy's ancient Almagest catalogue but did something no one had done before - he drew the constellations as illustrations, with the brighter stars rendered as dots of varying sizes. For the first time, a star map was designed to be looked at, not just consulted. The original manuscript has been lost, but a copy from 1009 survives at Oxford University. A thousand years later, it is still stunning. ## The Golden Age: 1603 to 1801 The period that art historians call the "Golden Age of star maps" lasted exactly 198 years, from Johann Bayer's Uranometria in 1603 to Johann Elert Bode's Uranographia in 1801. In those two centuries, four atlases were created that changed how humans see the sky. Bayer was not a professional astronomer. He was a German lawyer in Augsburg who taught himself to observe the stars. In 1603 he published Uranometria - 51 copper-engraved star charts, one for each of the 48 Ptolemaic constellations, plus a chart of newly discovered southern stars and two planispheres covering the entire sky. It was the first atlas to map the complete celestial sphere. The engravings were by Alexander Mair, and the constellation illustrations by the Dutch painter Jacob de Gheyn II. Each star was positioned with unprecedented accuracy, using data from Tycho Brahe's observations. And critically, Bayer introduced a system of naming stars with Greek letters - alpha for the brightest, beta for the second brightest, and so on. That system is still used today, four centuries later. But what made Uranometria extraordinary was not the science. It was the beauty. The constellation figures - Orion with his club, Cassiopeia on her throne, Hercules with his lion skin - were rendered with the skill of Renaissance portraiture. The combination of precise star positions and artistic elegance set a standard that endured for two centuries. As one astronomical cartographer put it: "This work was to uranography what the Gutenberg Bible was to printing." The second great atlas came from Johannes Hevelius in 1687. His Firmamentum Sobiescianum (also known as Uranographia) was nearly as beautiful as Bayer's, with one peculiarity - the maps showed the sky mirror-reversed. This strange convention came from celestial globes, which show the sky from the outside looking in. On Hevelius's flat maps, left became right and right became left, and the constellation figures had to be turned around to avoid confusion. You see the backs of Andromeda and Orion. It is disorienting and oddly charming. The third was John Flamsteed's Atlas Coelestis in 1729 - the first major atlas to use equatorial coordinates instead of ecliptic ones, and the source of the "Flamsteed numbers" still used to identify stars today. Flamsteed was the first Astronomer Royal of England, appointed by Charles II, and his atlas was a monument of institutional precision. The fourth and final great atlas was Bode's Uranographia in 1801. It set new limits. For the first time, stars invisible to the naked eye were included. The chart projections were more sophisticated than anything before. Bode introduced constellation boundaries - the invisible borders between regions of the sky that the International Astronomical Union would later formalise in 1930. His Uranographia was the bridge between the artistic tradition and the scientific one. After Bode, the constellation figures disappeared. Star maps became functional again. The art drained out of astronomy. ## What Was Lost The transition from artistic star atlases to purely scientific ones happened gradually through the 19th century. It was driven by the telescope - as instruments improved, the number of known stars exploded from a few thousand to millions. You cannot draw a Renaissance figure around a million data points. The last major atlas to include constellation figures was Elijah Burritt's in 1835. After that, star maps became what they are today: precise, useful, and invisible. Nobody hangs a modern star catalogue on their wall. Something was lost. The Golden Age atlases were not just tools for finding stars. They were objects of contemplation. They invited you to look and keep looking. The figures gave structure to chaos - they turned scattered points of light into stories. Orion was not just a pattern of dots. He was a hunter. Cassiopeia was not coordinates. She was a queen. The data was the same. The meaning was different. ## A Different Kind of Sky We think about this lineage when we build Codex Stellarum. We are not mapping the heavens. We are mapping something more personal - the pattern of someone's work over time. Every day is a star. Bright days burn large. Quiet days are faint points in the dark. The pattern that emerges is unique to each person, as individual as a fingerprint. The connection to the Golden Age atlases is not superficial. Like Bayer, we plot data points with precision and then wrap them in beauty. Like Flamsteed, we use coordinate systems to give structure to information. Like Bode, we are trying to make visible something that would otherwise just be a row in a database. And like al-Sufi a thousand years ago, we believe that data is more meaningful when it is beautiful. The Planisphere layout - a circular star map with months around the circumference - is a direct descendant of the planispheres in Bayer's Uranometria. The Latin inscriptions (TABVLA CONTRIBUTIONVM, MAGNITUDINES STELLARVM) are a nod to the tradition. The themes - Observatory, Blueprint, Parchment - are named for the aesthetic worlds these atlases inhabited: dark observatory domes, architectural drafting tables, aged manuscript paper. The name itself is a homage. A codex is a manuscript. Stellarum is the Latin genitive plural of stella - "of the stars." The great atlases of the Golden Age had names like Uranometria, Atlas Coelestis, Firmamentum Sobiescianum. Codex Stellarum sits in that lineage. It is a small, modern entry in a tradition that stretches back four centuries - and arguably thirty-two thousand years, to a mammoth tusk in a German museum. ## Data as Art The idea that data can be art is not new. Florence Nightingale's polar area diagrams in 1858 were designed to be beautiful so that politicians would actually read them. Charles Joseph Minard's 1869 visualisation of Napoleon's march on Moscow is considered one of the greatest data visualisations ever created - it is also a work of art that hangs in museums. What is new is the personalisation. Spotify Wrapped proved that people love seeing their own data reflected back at them as something beautiful and shareable. The annual ritual of sharing your top songs is not about the music. It is about identity. "This is who I am, rendered in data." Codex Stellarum does the same thing for code. Your contribution graph is already data. We just give it the treatment that Bayer gave the sky in 1603 - precision wrapped in beauty, data turned into something you want to hang on a wall and stare at. The mammoth tusk, the Persian manuscript, the copper-engraved atlas, the Giclée print on your wall. Different centuries, different skies, same human impulse. Take something vast. Make it visible. Make it yours. --- *See your sky. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and preview your atlas for free.* --- # The Best Code Is Written in the Dark URL: https://codexstellarum.com/blog/the-best-code-is-written-in-the-dark Published: 2026-03-29 · Updated: 2026-03-24 Author: Codex Stellarum 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](https://codexstellarum.com) and see the shape of your coding life - free to preview, prints from £25.* --- # Your Data, Your Mirror URL: https://codexstellarum.com/blog/your-data-your-mirror Published: 2026-03-28 · Updated: 2026-03-24 Author: Codex Stellarum Every December, 245 million people open Spotify and stare at a screen that tells them who they are. Not in words. In data. Your top artist. Your total minutes. Your listening personality. Your "music age." The colours are bright, the fonts are big, and the whole experience is engineered for exactly one purpose: to make you screenshot it and post it to your Instagram story. And it works. In 2025, Spotify Wrapped generated 500 million shares in the first week. Half a billion people voluntarily advertised for a corporation - not because they were asked to, not because they were paid, but because Spotify showed them a mirror and they liked what they saw. This is not a story about Spotify. It is a story about a shift in how humans relate to their own data. Something changed in the last decade, and it is worth understanding - because it explains why a developer would want to hang their GitHub contribution graph on a wall. --- ## The Need to Be Seen Social psychologist Marilynn Brewer proposed a theory in the early 1990s called Optimal Distinctiveness Theory. It states that humans are driven by two competing needs: the need to belong to a group, and the need to stand out from it. We want to be part of something. We also want to be unique within it. Spotify Wrapped nails both. When you share your top artist and discover three of your friends also had the same one, you feel connected. When your number-five slot is a Finnish death metal band nobody else has heard of, you feel distinct. The same data point serves both needs simultaneously. Behavioral scientist Ishani Banerji at Clemson University puts it simply: "As humans, we have evolved to have social identities. We want to feel like we belong. But at the same time, we have this competing motivation where we also want to feel unique and distinct." Wrapped satisfies both impulses in a single swipe. But Wrapped is just the most visible example. The same psychology is at play in every "year in review" product that has launched in its wake. ## The Wrapped Effect Spotify did not invent the concept of showing users their own data. But they perfected the format - and in doing so, triggered an arms race. Strava launched "Year in Sport" - a personalised recap of your runs, rides, and walks, complete with shareable graphics. In 2025, their platform hit 180 million users, with new clubs quadrupling and 14 billion kudos exchanged. The year-end recap is now a central part of the Strava experience. Apple built fitness rings into the Apple Watch - three coloured circles that close when you hit your daily movement, exercise, and standing goals. The gamification is so effective that people feel genuine anxiety when a ring is not closed. Third-party developers saw the gap and built "Apple Health Wrapped" - turning a year of health data into shareable infographics. Duolingo sends you a year-end report of your language learning streaks. Goodreads shows you how many books you read. PlayStation and Xbox generate gaming recaps. Even ChatGPT launched "Your Year with ChatGPT" in December 2025, complete with personalised awards and AI-generated images reflecting your conversation topics. The pattern is always the same. Take data that already exists. Package it beautifully. Frame it as identity, not statistics. Make it shareable. Researchers call this "wrappification" - the transformation of behavioural data into identity narratives. The term comes from a 2025 academic paper by Taylor Annabell and Nina Vindum Rasmussen, who studied how university students responded to Spotify Wrapped. They found that participants experienced the data as simultaneously self-affirming and reductive - they loved seeing themselves reflected, but also felt the algorithm missed something essential. That tension - "this is me, but not all of me" - is what makes data mirrors so compelling. They are close enough to feel personal but incomplete enough to leave room for interpretation. ## Why Developers Are Different Developers have had access to their own data for years. GitHub contribution graphs have existed since 2013. Every developer can visit their profile and see a grid of green squares showing their commit activity for the past year. And yet, nobody posts their GitHub contribution graph to Instagram. The reason is obvious once you see it: the data exists, but the mirror does not. A grid of green squares is a database query rendered as pixels. It communicates volume - how many contributions, on which days - but it communicates nothing about meaning. There is no narrative. There is no beauty. There is no identity. Compare this to Spotify Wrapped. Spotify does not show you a spreadsheet of play counts. They show you a "Listening Personality." They tell you that you are an "Alchemist" or a "Hypnotist" based on your habits. They assign you a "Music Age." They turn data into story. GitHub does none of this. The contribution graph is a tool for accountability, not reflection. It tells you that you made 4 contributions on a Tuesday, not that you were in the middle of the most productive quarter of your career. It shows the data but hides the meaning. That gap - between the data that exists and the mirror that doesn't - is why we built Codex Stellarum. ## From Grid to Galaxy The core insight behind Codex Stellarum is that the same data, presented differently, becomes a different thing entirely. A grid of green squares says: "You were active on these days." A star atlas says: "This is the shape of your year. These bright clusters are the months you shipped. This dark gap is the holiday you took. This gradual brightening is the project that changed everything." The data is identical. The experience is not. This is not a superficial difference. When data is presented as art, it invites contemplation in a way that dashboards do not. You linger on a star atlas. You trace the spiral with your eyes. You remember what you were working on when that cluster of stars appeared. The atlas does not tell you what to feel - it creates a space where feeling can happen. Spotify understood this. Their design team packages listening data in bright colours and playful language specifically because they know that the emotional response drives sharing. The data story is designed to make you feel something - pride, nostalgia, amusement, connection - and then act on that feeling by posting it. Codex Stellarum works on a similar principle but arrives at a different destination. We are not designing for sharing (though people do share their atlases). We are designing for permanence. A Spotify Wrapped story disappears after 24 hours. A star atlas print hangs on your wall for years. The feeling it produces is not the quick dopamine hit of a social post - it is the slow, accumulating satisfaction of having your work made visible in a form that is worthy of it. ## The Quantified Self, Qualified The "Quantified Self" movement - tracking every aspect of your life through data - emerged in the late 2000s, championed by Wired editors Kevin Kelly and Gary Wolf. The original vision was optimisation: track your sleep to sleep better, track your exercise to exercise more, track your mood to be happier. That vision partially came true. Millions of people wear fitness trackers. But the surprise was that people cared less about optimisation than about reflection. They did not want to see their data in order to improve it. They wanted to see their data in order to understand themselves. The shift from "quantified self" to "qualified self" - from data-as-optimisation to data-as-identity - is the cultural current that produced Spotify Wrapped, Strava Year in Sport, Apple fitness rings, and Codex Stellarum. People do not share their Spotify Wrapped because they want to optimise their listening habits. They share it because it says something about who they are. The data is the medium. The identity is the message. ## What Your Atlas Says About You A developer's GitHub contribution graph contains more personal information than they realise. Not personal in the privacy sense - the data is public - but personal in the identity sense. It is a record of every day they chose to show up and build something. The bright clusters are not just "high activity days." They are the weeks you were obsessed with a project. The dark gaps are not just "low activity." They are the burnout you recovered from, the job you left, the break you needed. The seasonal rhythms are not just patterns - they are the shape of your life as a builder. This is data that deserves a mirror. Not a grid of green squares. Not a tooltip that says "4 contributions on March 15th." A mirror that reflects the meaning, not just the metric. A star atlas is that mirror. Every developer who sees their contributions rendered as constellations has the same reaction: they stop looking at the data and start seeing the story. The numbers disappear. The narrative appears. That is the Wrapped effect, applied to code. Your data, made beautiful. Your work, made visible. Your mirror, on your wall. --- *See what your data looks like as a star atlas. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) - free to preview, prints from £25.* --- # Nothing to Hold URL: https://codexstellarum.com/blog/nothing-to-hold Published: 2026-03-27 · Updated: 2026-03-24 Author: Codex Stellarum An architect drives past a building they designed and says, "I made that." A surgeon watches a patient walk out of the hospital. A carpenter runs a hand along the grain of a table they built from raw timber. A painter stands in front of a canvas. A chef watches someone close their eyes after the first bite. A software developer closes their laptop and goes home. The work is somewhere. It runs on servers in Virginia or São Paulo. It processes millions of requests. It handles payments, routes ambulances, connects people across continents. It might be the most consequential work on the list. But the developer cannot point to it. They cannot touch it. They cannot hang it on a wall or walk past it on the street. Software, for all its power, produces nothing you can hold. --- ## The Intangibility Problem In 2017, researchers Ozgun Atasoy and Carey Morewedge at Boston University published a study across five experiments showing that people consistently valued physical goods more than identical digital versions. Tourists paid 48% more for a physical souvenir photograph than a digital one. Students paid more to buy a physical textbook than a digital copy. Participants paid more for physical books and films than their digital equivalents. The mechanism, the researchers found, was psychological ownership. Physical objects create a stronger association with the self. You can touch them. You can place them somewhere. You can control them in space. Digital goods feel transient - fast, spontaneous, ephemeral. Physical goods feel permanent and stable. The study was about consumer goods, but the implications reach further. If physical objects create stronger psychological ownership, what happens to a person whose entire professional output is digital? What happens to someone who builds things for a living but never produces anything they can hold? The answer, I think, is a low-grade, persistent sense of unreality about the value of their own work. Developers know intellectually that the software they built matters. They can see the metrics, the user counts, the revenue dashboards. But knowing and feeling are different operations, and the physical world has a monopoly on the second one. ## The Absence of Proof Most professions accumulate artifacts. A lawyer has binders of case files. A doctor has a white coat with their name embroidered on it. An academic has shelves of published papers. Even a plumber has the satisfaction of watching water flow where it did not flow before. Software developers accumulate almost nothing physical. The code lives in repositories. The products live on servers. The work is experienced by users who will never know the developer's name. The best code is the kind nobody notices - infrastructure so reliable it becomes invisible, interfaces so intuitive they feel obvious in retrospect. There is a particular cruelty in this for senior developers. A decade of career progression looks, from the outside, like a series of identical days at the same desk. The desk might get nicer. The screens might multiply. But there is no shelf of trophies, no portfolio of tangible work, no accumulating physical evidence of mastery. Remote work made this worse. At least in an office, there were whiteboards covered in architecture diagrams, sticky notes from sprint planning, a team you could see and touch. Working from home, the developer's entire professional existence collapses into a rectangle of light. Close the laptop and the evidence vanishes. ## Why the Shelf Matters Research on physical awards in the workplace - even in our era of remote teams and digital badges - consistently shows that tangible recognition objects outperform digital ones in emotional impact and memory formation. A trophy on a shelf stays visible long after the initial achievement. It triggers what psychologists call emotional memory - the association of an accomplishment with a specific moment in time that can be revisited physically. A digital badge in a Slack channel does the opposite. It scrolls away. It gets buried under other messages. Within a week, nobody remembers it was there. The human brain evolved in a world of objects. We think with our hands. We understand through touch. We remember what we can see in our peripheral vision as we walk through a room. The physical environment is not a backdrop to our cognitive life - it is woven into it. Developers are asked to produce their most important work entirely outside this system. Everything they build exists in a medium the brain did not evolve to grasp. The screen shows them text. The terminal shows them output. But the body receives nothing. ## The Torres Strait Islanders Had It Right There is a wonderful entry in the academic catalogue of physical data visualisations about the Torres Strait Islanders. In the 19th century, these Pacific islanders did not have a numeral system, so they used sticks to keep counts. Each stick represented an accomplishment - a turtle caught, a fish speared. The sticks were tied to a string, forming a bundle called a kupe. Kupes were used as social displays. Big kupes were greatly prized. When you wanted to show what you had achieved, you unrolled your bundle. Every culture, across all of human history, has found ways to make accomplishment physical. The impulse is universal. Medals, trophies, certificates, diplomas, notches on a belt, merit badges, championship rings. Humans need proof they can hold. Software developers are among the first professionals in history to produce work of enormous value while generating zero physical artifacts. No kupes. No notches. No bundle to unroll. ## What a Print Does A Codex Stellarum atlas is, at its core, a physical artifact of digital work. The data is public - it is right there on the developer's GitHub profile. The information is the same whether you view it as a grid of green squares on a screen or as a constellation of stars on a print. The content has not changed. But something else has. When that data becomes a 70-centimetre Giclée print on 200gsm archival paper, it crosses a threshold. It enters the physical world. It gains weight and texture. It can be framed, hung, touched. It occupies space in a room and in the peripheral vision of the person who made it. The developer who hangs their atlas on the wall is doing something that sounds simple but is actually radical for their profession: they are making their work visible to themselves. Not visible as a dashboard or a metric or a green square. Visible as an object. A thing with presence. A thing that says, quietly and continuously, from the wall above their desk: you built something. Here is the proof. The Wharton researchers found that physical objects create psychological ownership - a felt sense that something is yours, connected to your identity. A digital contribution graph does not produce this feeling. A print does. The same data, in a different medium, creates a different relationship with the self. That is what a print does. It gives a software developer something they have almost never had in their career. Something to hold. --- *See what your work looks like when it leaves the screen. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and preview your atlas - free to try, prints from £25.* --- # Three Shapes of Time URL: https://codexstellarum.com/blog/three-shapes-of-time Published: 2026-03-26 · Updated: 2026-03-24 Author: Codex Stellarum Ask someone to draw time and watch what happens. Some people draw a horizontal line, left to right. Birth on the left, death on the right, everything else in between. The past is behind them. The future is ahead. Time has a direction and it does not loop back. Other people draw a circle. January at the top, summer on the right, autumn at the bottom, spring on the left. When December ends you return to the beginning. The year has no end point, only a rhythm. A third group draws something harder to name. A spiral, maybe. Or a helix. Time moves forward but it also orbits. You pass through the same seasons, the same months, the same weekly rhythms, but each pass is slightly different from the last. You are not where you were a year ago, even though the calendar says the same date. Cognitive scientists have spent decades studying these mental images. The research is clear on one point: humans cannot think about time without converting it into space. Time has no shape, no colour, no position. But the brain insists on giving it all three. --- ## Time Needs a Body In 2007, psychologist Daniel Casasanto and linguist Lera Boroditsky published a study at Stanford showing that people cannot process duration without recruiting spatial representations. Participants who saw a longer line on screen judged a simultaneous tone as lasting longer, even when it did not. But the reverse was not true - hearing a longer tone did not make people see a longer line. The finding was stark. Space shapes our perception of time, but time does not shape our perception of space. The relationship runs in one direction. We borrow from the concrete to understand the abstract, and never the other way around. This asymmetry shows up everywhere in language. We talk about a long weekend and a short meeting. We look forward to Friday and look back on childhood. We say time flies and deadlines approach. Every temporal metaphor is secretly spatial. We have no other vocabulary for it. But the shape we give time varies. And that variation is the interesting part. ## The Line Western cultures overwhelmingly default to the linear mental timeline. Past on the left, future on the right, matching the direction of reading. Arabic and Hebrew speakers tend to reverse it - past on the right, future on the left. Mandarin speakers sometimes orient time vertically, with the past above and the future below, reflecting the traditional top-to-bottom writing direction. The linear model treats time as a one-way street. Each moment is unique. Each day is consumed and cannot be revisited. History has a beginning, a middle, and an end. Christianity, Islam, and Judaism all structure time this way - creation, life, judgment. There is a destination. In a developer's career, the linear view is the resume. Started as a junior in 2015. Became a senior in 2019. Moved to a lead role in 2022. Each year is a rung on a ladder that only goes up. The line does not curve and it does not repeat. The Chronicle layout in Codex Stellarum is the linear shape made visible. Year by year, band by band, the stars unfold like geological strata. The earliest years are at the top. The most recent are at the bottom. You read it like a timeline, like a core sample drilled through sediment. Each layer is distinct. The whole thing has a direction. People who choose Chronicle tend to be drawn to narrative. They want to see the story unfold. Where did I start? How did it change? What happened next? ## The Circle In 2019, researchers at the University of Oslo and the Norwegian Broadcasting Corporation ran a large online survey with 76,922 participants. They asked people to place the months of December and March on a circle. The majority placed December near the 12 o'clock position and March near 3 o'clock - the same positions as on a clock face. But about a third of respondents preferred other shapes entirely. Ellipses, rectangles, spirals, and arrangements so idiosyncratic they were tied to specific landscapes or personal memories. The researchers concluded that while the circle is the most common spatial model for a year, there is genuine variation in how individuals map time. The circular model is ancient. It comes from observation. The sun rises and sets. The moon waxes and wanes. The seasons return. Crops are planted and harvested in cycles. For most of human history, time was circular because the evidence of the senses said so. The rising and setting of stars is isomorphic with the circle - the same constellations return to the same positions at the same time each year. In a developer's life, the circular view captures rhythm. The quarterly sprint cycle. The annual review. The conference season. The December freeze. The January burst of motivation. These patterns repeat, year after year, and recognising them is a form of self-knowledge. The Planisphere layout is the circular shape. Months orbit the circumference like hours on a clock face. January sits at the top and the year wraps around. Multiple years can overlay, creating concentric rings of activity. You can see at a glance which months are consistently bright and which are consistently dark, year after year. People who choose Planisphere tend to be drawn to pattern recognition. They want to see rhythm. When am I most productive? Is there a seasonal shape to my work? Do I always slow down in August? ## The Spiral Neither the line nor the circle fully captures how most people experience time. The line implies that each moment is unique and unrepeatable. The circle implies that time returns to the same place. Both are partly right and partly wrong. A spiral resolves the tension. It moves forward - you are always progressing, always aging, always accumulating experience. But it also orbits - you pass through the same months, the same seasons, the same rhythms. Each pass is different because you are different. March 2026 is not March 2024, even though the calendar is identical, because you have changed in the intervening loops. The philosopher Friedrich Nietzsche wrote about eternal recurrence - the idea that you might live your life over and over, infinitely. He meant it as a thought experiment about how to live. Would you choose the same life again? The spiral is a gentler version of this idea. You do not repeat your life. But you revisit its rhythms, and each revisitation carries the weight of every previous pass. In cognitive science, the spiral shows up as a natural hybrid. People who report "spatial sequence synesthesia" - a condition where time sequences have vivid spatial locations in the mind's eye - sometimes describe their year as a spiral rather than a line or circle. The shape captures both progression and periodicity in a single form. In a developer's career, the spiral is the most honest shape. You are not the same programmer you were three years ago, but you are still working through the same patterns - bursts of energy, periods of rest, seasonal rhythms, annual cycles. The code changes. The language changes. The problems change. The rhythm does not. The Helix layout is the spiral made visible. Time unwinds from the center outward. The earliest contributions sit at the core and the most recent trace the outer edge. The shape is organic and continuous - there are no hard boundaries between years, just a flowing curve that tightens and loosens with activity. People who choose Helix tend to be drawn to feel. They are less interested in reading the data and more interested in experiencing it. The Helix is the most visually striking layout because the spiral creates natural tension - the eye follows the curve inward and then back out, tracing the developer's journey as a single, unbroken path. ## Why Shape Matters The shape you give your data changes what you see in it. A linear chart of the same GitHub contributions shows growth or decline. A bar that goes up or a bar that goes down. The question it answers is: am I doing more or less? A circular chart shows rhythm. Bright spots and dark spots repeat at the same positions each year. The question it answers is: when do I work? A spiral shows both. Movement and recurrence. Change and continuity. The question it answers is harder to articulate, which is why it tends to be the layout that makes people pause longest when they see it for the first time. Cognitive scientists call this "framing." The same information, presented in different spatial configurations, activates different interpretive frameworks in the brain. A temperature reading presented as a number feels like a fact. Presented as a rising line on a graph, it feels like a trend. Presented as a colour on a heat map, it feels like an environment. The data has not changed. The frame has. Codex Stellarum's three layouts offer three frames for the same data. The Chronicle says: here is your story, from beginning to now. The Planisphere says: here is your rhythm, repeating across the years. The Helix says: here is your journey, spiralling outward from where you started. Each one is true. Each one is incomplete. The shape you prefer says something about how you think about your own time. --- *Discover which shape fits your story. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and try all three layouts - free to preview, prints from £25.* --- # The Rosette Layout URL: https://codexstellarum.com/blog/the-rosette-layout Published: 2026-03-25 · Updated: 2026-03-25 Author: Codex Stellarum In 1220, the master builders at Chartres faced a structural problem. The north transept wall was enormous, load-bearing, and almost entirely blank. They could not fill it with narrative reliefs because the stone was structural. They could not pierce it with a grid of small windows because the light would be wrong. What they built instead was a single circular opening nearly eleven metres across, divided by stone ribs radiating from a central roundel to concentric rings of glass, each ring further divided by radial lines into segments of colour and story. It was not decoration. It was information. In a congregation that could not read, it was a map of the cosmos, a calendar of the saints, a diagram of creation. Light passed through it and made meaning. The geometry has not changed. It is still the most efficient shape for displaying a full cycle of data around a fixed centre, and there is one domain of modern life where that matters more than anywhere else: the career of a long-tenured developer, or the contribution history of an organisation that has been building software for a decade. ## THE WINDOW AND THE WHEEL The rose window arrived in northern France in the early 12th century, but the geometry behind it was older and came from further away. Islamic craftsmen had been constructing interlocking geometric patterns (circles divided by radial lines, concentric rings subdivided into equal segments) for at least three centuries before the first Gothic cathedral broke ground. Their source was partly astronomical. The astrolabe, an instrument used to map the visible sky, is a flat disc with concentric rings marked by angular divisions. The planisphere, used to show which stars are visible at a given time of year, is a rotating pair of discs, each divided into rings and segments corresponding to the coordinate grid of the celestial sphere. The Gothic master builders absorbed this geometry and gave it new meaning. The concentric rings represented the hierarchy of heaven. The radial divisions marked time: the calendar, the saints' days, the turning year. The central roundel held Christ or the Virgin. The whole window was simultaneously a scientific instrument and a theological argument. What made it work was the density. A rose window divided into 52 segments per ring does not feel sparse. It feels complete. The eye moves around the circumference and finds something in every segment. The circle closes on itself and the sense of totality is immediate. Fifty-two is not an arbitrary number. There are 52 weeks in a year. ## THE GEOMETRY OF A WORKING YEAR The Rosette layout renders a GitHub contribution history as a rose window. Each year of activity becomes a concentric ring, with the most recent year at the outside and the earliest at the centre. Each ring is divided into 52 equal segments, one for each week of that year, radiating from the hub. The brightness of each segment reflects the weight of contributions in that week: commits, pull requests, code reviews, issues opened and closed. The choice of 52 weekly segments per ring is not aesthetic convenience. It is the right resolution for code data. Daily resolution is too noisy for any view longer than a few months. The day-to-day variance in commit counts reflects interruptions, meetings, travel, illness, the morning spent in a design review instead of at a terminal. None of that variance is meaningful at the scale of a career. Monthly resolution is too coarse in the other direction: a month is long enough to conceal the sprint cycle entirely, to average away the difference between the week a team shipped a major release and the recovery week that followed. The week is the natural unit of software development. The sprint. The weekly standup. The pull request that opened on Monday and merged on Friday. The week of hotfixes after a bad deploy. The quiet week between Christmas and new year. The week a side project suddenly got traction. At weekly resolution, the patterns that actually matter become visible. Which weeks are consistently bright across every ring: the spring sprint before the annual conference, the September push before the fiscal year closes, the burst of energy in January. Which weeks are reliably dark: the August slowdown when half the team is on leave, the two weeks in December that every organisation knows but nobody schedules around. The Rosette makes those patterns structural. They repeat in the same angular position across every ring, and the eye finds them without instruction. Real celestial instruments divide their coordinate rings into units that map directly onto the calendar. The planisphere is usable precisely because its divisions match the astronomical year. A contribution chart with 52 weekly segments per ring inherits that tradition directly. The data fits the instrument. The instrument fits the data. ## LIGHT THROUGH GLASS For organisations and long-tenured developers (contributors with five, ten, fifteen years of activity on record), the Rosette exists because no other layout could hold the data with the same legibility. A linear chart becomes a narrow ribbon stretched across a screen, too long to print, too compressed to read. A grid arrangement runs out of vertical space and forces the viewer to scroll through years that should be visible simultaneously. The Rosette adds a new ring for each year and keeps the full history at once, at the same scale, in the same field of view. The oldest contributions sit at the centre like the original stone of the roundel. The newest ring at the edge carries the most recent season on its outer circumference. This is why the Rosette is the default layout for organisations in Codex Stellarum, and why it is well suited to individual contributors with long careers. An organisation's contribution history is dense, layered, and genuinely cyclic. It has seasons that repeat. It has patterns that only become legible when multiple years are visible at the same time. What the Rosette reveals about an organisation goes further than simple activity levels. Brighter outer rings often reflect team growth: more contributors, more concurrent projects, more pull requests in flight at once. The texture of successive rings tells the story of how a team matured. Early rings tend to be spiky, with a few very bright segments and long stretches of darkness: a small team shipping in bursts. Later rings tend to be smoother and more uniformly lit, the signature of a larger team with established processes, regular sprint cadences, and distributed ownership. You can see the moment an organisation stopped being a startup. The same logic applies to individual developers. A junior developer's early rings are characteristically uneven: intense periods of learning broken by gaps, the jagged output of someone still finding their working rhythm. Senior developer rings look different: steadier, more consistent, with the occasional bright cluster marking a major feature or a difficult migration rather than a frantic scramble to keep up. The transition between those two textures, visible across successive rings, is the shape of a developer growing into their craft. The medieval congregation at Chartres did not read the rose window as a diagram. They experienced it as light. The theological argument arrived through colour and luminosity, through the sensation of a dark interior suddenly crossed by coloured beams at a particular hour of the day. The data was encoded in glass, and glass needed light. The Rosette works by the same logic. Brightness maps to activity. Position maps to time. The circular form makes the cyclical nature of a working year visible in a way that a list of numbers never can. You do not need to read the axes to understand a ring that is bright all the way around versus a ring with one bright quadrant and three dark ones. The difference is immediate. ## THE MOST CELESTIAL LAYOUT Codex Stellarum offers four layouts. The Chronicle renders contributions as a vertical timeline, layered like geological strata. The Planisphere maps the year onto a circular disc, the astronomer's star chart flattened into a single season. The Helix traces a spiral outward from the centre, one revolution per year, good for showing a career as a continuous thread. Each layout has its logic. The Rosette is different in character. It looks, more than any other layout in the collection, like a scientific instrument. The concentric rings. The radial divisions. The dense, even segmentation that gives the whole disc a sense of completeness even before you examine any individual ring. Hold it at arm's length and it could be a planisphere pulled from a navigator's chart case. It has the visual grammar of a tool built for reading the sky. This is not accidental. The same geometric tradition that produced the astrolabe produced the rose window. The same division of a circle into equal angular segments that lets an astronomer read right ascension from a coordinate disc lets a viewer read a full year of weekly contributions from a single ring. The instrument shape carries authority precisely because it was developed over centuries for the serious purpose of measuring and displaying cyclic phenomena. A developer's contribution history is cyclic. It has seasons. Projects begin and accelerate and end. Months of low output follow periods of intensity. Years of growth alternate with years of consolidation. The code changes. The language changes. The problems change. The rhythm does not. The Rosette makes all of that visible at once, in a form that humans have been trained by eight centuries of scientific and sacred geometry to read instinctively. ## THE CIRCLE CLOSES The word "rose" was not applied to these windows until the 17th century. For the builders who created them, they were simply wheels. Rota, in Latin. The wheel of fortune. The wheel of the year. The wheel of the cosmos turning around its fixed centre. There is something right about that older name. A wheel implies motion. A wheel implies a centre that does not move while the rim turns around it. The Rosette layout has the same structure: the innermost ring is the oldest year, fixed and unchanging, while each new year adds a ring at the outside and the whole disc grows outward in time. The centre holds. The edge moves forward. The builders at Chartres were trying to put the entirety of sacred history into a circle of glass. The geometry forced clarity. Everything had to fit, every segment had to earn its place, and the whole had to cohere into a single legible image that a stonecutter's apprentice at the back of the nave could understand without instruction. That is still the right constraint. The best visualisation makes the shape of the whole visible at a glance, before analysis begins. Ten years of a developer's working life. A decade of an organisation's output. All of it in one circle, every ring in place, every week accounted for. The window does not need explaining. Neither should the chart. --- *Explore the Rosette layout and every other layout in the collection at codexstellarum.com. Enter your GitHub username to preview your atlas free, with prints from £25.* --- # The Helix URL: https://codexstellarum.com/blog/the-helix-layout Published: 2026-03-25 · Updated: 2026-03-25 Author: Codex Stellarum A nautilus does not plan its shell. It grows, chamber by chamber, each new section larger than the last, the whole curving outward in a ratio so precise that mathematicians spent centuries trying to name it. The result is a logarithmic spiral, one of the most frequently recurring forms in nature. Not because the nautilus chose it, but because it is the natural shape of accumulation over time. Galaxies spiral. Trees grow in rings. Sunflower seeds pack themselves into double spirals that always number consecutive Fibonacci values. DNA, that most fundamental record of biological history, is a double helix. The instructions for building every living thing are written in a spiral. There is something the nautilus, the tree ring, and the double helix all share: they do not simply grow, they cycle as they grow. Each new ring of a tree returns to the same point in the year, but one layer further out, carrying the added mass of everything before it. The cycle and the progression are the same description. A developer who has been writing code for eight years will recognise this immediately. ## THE SHAPE OF ACCUMULATED TIME The Archimedean spiral was studied as a pure mathematical object as far back as 225 BC, when the Greek mathematician Archimedes described it in a treatise that has survived two millennia. In an Archimedean spiral, the distance between successive turns remains constant. The shape expands at a steady rate. It is the geometry of something growing evenly, outward, ring by ring. Tree rings work this way. Each year of a tree's life is visible as a band of growth, and the bands spiral outward from the centre. Cut a cross-section and you are looking at a compressed record of the tree's entire history: wet years and dry years, good summers and hard winters. Everything that happened, laid out in concentric rings, readable if you know how to look. A developer's contribution history has the same structure. The rings are years. The texture within each ring - the density of commits, the cadence of pull requests, the rhythm of code reviews - records the conditions of that year as faithfully as a tree records rainfall. The sprint cycles that defined Q1. The release that consumed October. The open-source burst in March, before the conference. The quiet that followed a big ship. Each year is a ring, and each ring is a record. ## THE TENSION THE HELIX RESOLVES There is a long-running argument in how we represent time visually, and most data visualisations never acknowledge that it exists. Linear time says that yesterday is behind you and tomorrow is ahead. A timeline stretches from left to right. Progress is motion in one direction. For a developer, the linear view is essentially the resume: started as a junior in 2018, moved to a senior role in 2021, took on staff engineering in 2023. Each point further along the line. Useful, but incomplete. Circular time says that time has rhythm. Mondays feel like Mondays. January is a particular kind of month. The quarterly sprint cycle. The December code freeze. The January burst of motivation that refills the backlog. A developer who has shipped software for five years knows that October always feels like a certain kind of month, and that August is characteristically quieter. The cycle is real. The problem is that neither model alone is true. The linear view cannot explain why your December 2024 feels qualitatively different from your December 2021, even if the commit count is similar. You are carrying more context. The architectural decisions are yours now, not someone else's legacy. You have been around this loop before. The circular view cannot explain why that matters - why the second pass through the same problem is faster, less anxious, more considered. The helix is both models at once. Each revolution is a year, acknowledging the cycle. But the spiral moves outward as it turns, acknowledging progression. The seventh year of a career sits further from the centre than the first. You revisit the same problems each year - performance bottlenecks, dependency upgrades, the open-source contribution sprint - but each time you do, you are one loop further out. The same quarterly cadence, but the code is better. The same release pressure, but you wrote the incident runbook this time rather than reading it. A developer is simultaneously progressing and cycling. The Helix makes that visible. ## THE PATH THE EYE FOLLOWS Look at a bar chart and your eye moves in discrete jumps. Bar to bar. Comparison to comparison. The movement is analytical. You are evaluating. Look at a spiral and your eye follows a path. It traces the curve inward or outward, continuously, without jumping. The movement is something closer to reading a story. You are following. This is not accidental. The Gestalt principle of continuity holds that the eye follows smooth curves and lines as single objects, even when those objects are made up of many separate elements. A spiral of stars reads as one continuous path before the eye has registered any individual star. The curve compels tracking. Following it feels natural in a way that hopping between bars or scanning across a grid does not. For a developer's contribution history, this matters in a specific way. The contribution record is not a collection of independent data points. It is a continuous experience, and the continuity is part of the meaning. The refactor you did in November 2024 connects directly to the original code you wrote in November 2022 - you can follow the path. The tight loops near the centre, where an early-career developer was still finding their rhythm in short bursts and tentative PRs, give way to wider, more assured loops further out. A career change appears as a sudden shift in the spiral's texture: the density changes, the cadence breaks and reforms. Following the spiral with your eye feels less like analysing a chart and more like remembering a career. The continuous path from first commit to now, traced in a single unbroken movement, is a different experience from scanning a grid. The data is the same. The experience of it is not. ## FELT BEFORE IT IS READ There is a category of data visualisation that works primarily through analysis: you read the axes, you compare the values, you extract the insight. There is another category that works through recognition: you look at the shape and you understand something before you have consciously processed a single number. The Helix belongs to the second category. Developers who see their own contributions rendered as a Helix for the first time often describe it as immediately recognisable in a way they cannot quite explain. The years of lower output, spiralling tight near the centre. The year everything expanded, the rings pushing outward into open space - often the year of the first serious project, the first codebase they owned rather than inherited. The rhythms within each revolution: weekday density and weekend voids, the quiet of August, the concentrated burst before a conference talk, the three weeks when a single pull request consumed everything else. None of this requires reading a legend. The eye finds the shape and something older than analysis takes over. The same pattern-seeking machinery that led humans to read the sky for seasons and find meaning in scattered light. Personal data, rendered in a form the brain already knows how to feel. Codex Stellarum renders your GitHub contributions in this form: your full contribution history, every commit and review and merged PR, unwinding outward from the centre of the spiral, one revolution per year, oldest at the core and most recent at the edge. The tight early loops of the years you were learning. The wider loops as scope and confidence expanded. This is why developers who choose the Helix tend not to be primarily motivated by legibility or precision. Those qualities are present. The draw is something else: the sense that this is the right shape for this particular kind of record. That years of work, accumulated ring by ring, look like what they are. That the form and the content finally match. The nautilus does not plan its shell. But the shell, when you look at it, feels exactly right. --- *Explore the Helix and every other layout with your own contribution data at codexstellarum.com, free to preview, prints from £25.* --- # The Planisphere Layout URL: https://codexstellarum.com/blog/the-planisphere-layout Published: 2026-03-25 · Updated: 2026-03-25 Author: Codex Stellarum The circle is the oldest shape for cyclical data. Long before bar charts and line graphs, humans tracked seasons, tides, and planetary motion on circular instruments. The sundial. The astrolabe. The zodiacal wheel. The compass rose. The circle is not a stylistic choice. It is the correct answer to a particular kind of question: what happens, and when does it happen again? A year of code is exactly that kind of question. The sprint cycles come back. Hacktoberfest lights up October; the December freeze dims it again. January brings its burst of resolution; February settles into the grind. You have lived this sequence before. The question is whether you can see it clearly enough to learn from it. ## THE INSTRUMENT BEHIND THE LAYOUT In the 2nd century CE, the Alexandrian astronomer Claudius Ptolemy described stereographic projection: a method for mapping the curved surface of the celestial sphere onto a flat disc. Every star, constellation, and coordinate line could be transferred from sphere to plane while preserving the angles between them. You could hold the sky in your hands. The physical instrument that followed was the astrolabe. Medieval Islamic astronomers - al-Farghani, al-Battani, al-Zarqali - refined it into the most sophisticated scientific instrument of the pre-modern world: a brass disc engraved with a precise map of the visible stars. Rotate the overlay to match the current hour and latitude, and the position of every star in the sky was immediately legible. A thousand years of scholarship, encoded in a circle. The European planisphere followed. In the 17th century, the Dutch cartographer Frederik de Wit produced hand-painted celestial planispheres mapping the northern and southern hemispheres of the sky - scientific instruments and objects of beauty simultaneously. In the 1680s, Jean-Dominique Cassini took the concept to its most literal extreme: a planisphere built into the floor of the Paris Observatory, twelve metres across, that visitors could walk across. Today the planisphere is still manufactured as a rotating star-finding tool. Set the date and hour, and the window shows exactly which stars are above your horizon. The principle is unchanged from Ptolemy's original description. The circle persists because the problem persists: cyclical data belongs on a cyclical surface. ## TWELVE MONTHS, TWELVE POSITIONS A calendar year has twelve months. A clock face has twelve hours. The coincidence is convenient, but the deeper logic is geometric. Both divide a cycle into equal arcs. Both use position around a circumference to encode the passage of time. The Planisphere layout places January at the top and proceeds clockwise, so that months orbit the circumference the way hours orbit a dial. Each month occupies thirty degrees of arc - a clean division of the full circle, a slice of the year made visible as a slice of the disc. Contributions within each month radiate inward toward the centre, with density encoded as stellar brightness: a heavy day sits near the circumference like a bright star near the horizon, a quiet day recedes toward the centre like a faint star near the zenith. The result is that the year becomes a single legible object. You do not scan left to right, hunting for the month you want. You read the whole thing at once, the way you read a clock face. Twelve and six, three and nine: the eye finds its bearings immediately. This geometry does something a sequential layout cannot: it places opposite months in direct visual relation. March sits across from September. June faces December. A developer who wonders whether their summer slowdown is real can compare it to the top arc at a glance - no scrolling, no memory required. The question becomes spatial rather than analytical, and spatial questions are the ones human vision answers effortlessly. ## THE RHYTHM THE GRID CANNOT SHOW The standard GitHub contribution grid is a rectangle: 52 columns of weeks, 7 rows of days, colour-coded from pale green to saturated green. It is honest and it is useful. It answers the question "did I commit today?" It does not answer the question "what is the shape of my year?" That question matters more than it first appears. Most developers do not work at a constant rate. They work in rhythms: the intensive sprint before a release, the quiet aftermath when the adrenaline clears, the slow weeks in August when half the team is on holiday, the sudden cluster in October that Hacktoberfest always produces. These rhythms are the actual texture of a working life. They are more interesting and more revealing than any single day's count. The grid represents those rhythms as a sequence, which means you have to hold them in working memory to perceive them as a pattern. You scan from January to December, you notice the dark patch in August, you notice the cluster of activity in March and again in October, and then you have to synthesise those observations into a shape. The shape exists in your mind, not in the image. The Planisphere externalises the shape. The year is laid out in space, not in sequence. The March cluster and the October cluster are visible simultaneously, positioned symmetrically on either side of the disc. The dark patch in August sits at the bottom of the circle, a void in the lower arc. The eye does not need to synthesise. It sees. ## BRIGHTNESS AND DARKNESS Astronomers have always talked about the sky in terms of brightness and darkness. Hipparchus devised the magnitude scale in the 2nd century BCE: first-magnitude stars are the brightest, sixth-magnitude stars are the faintest visible to the naked eye. The language of stellar brightness became the standard vocabulary for describing the distribution of light across the sky. The Planisphere layout borrows this vocabulary. Dense months glow. Sparse months dim. The visual effect is of a star field with concentrations and voids - a natural distribution, uneven in the way that real skies are uneven, rather than the uniform grid of a spreadsheet. Where the grid assigns colours on a fixed scale, the atlas assigns brightness on a relative one. The brightest point is always your most productive period; the rest is scaled accordingly. This makes the layout particularly good at one task: revealing which months are consistently bright and which are consistently dark. When multiple years are overlaid, the structural patterns of a working life become unmistakable. If October is always dense and February always sparse, the circle makes that rhythm visible as a spatial fact. You stop asking whether the pattern is real; you can see that it is. The more interesting questions begin from there: why does Q1 always start strong? Is the post-launch quiet in May a recovery or a drift? Does the conference season correlate with a burst of new thinking, or does it drain the weeks around it? Codex Stellarum renders those questions as light and shadow on a disc you can put on a wall. The numbers are there, encoded in the brightness of each point. But what you read is not numbers. You read the shape of how you work. ## THOSE WHO CHOOSE THE CIRCLE Developers who select the Planisphere layout tend to share a preoccupation. They are not primarily interested in their peak day or their total commit count. They are interested in how they work over time - in whether the rhythms they sense in their own practice are real, and whether the year, viewed whole, has a shape. There is something clarifying about discovering that your working patterns are seasonal: that you always slow down in summer, always resurface in September, always burn bright in the weeks before end of quarter. These are not failures. They are the rhythm of a practice that has found its shape over years of iteration. Seeing them in space, not in sequence, is the first step toward understanding them. The circular format rewards that kind of attention. A rectangle presents data as a list. A circle presents data as a pattern. The Planisphere does not invite you to count your contributions. It invites you to recognise them. Ptolemy's stereographic projection was admired for two thousand years because it solved a genuine problem: the celestial sphere is real, but it cannot be examined directly. The projection made it examinable without making it false. The Planisphere layout does the same for a year of work. Once a year has passed, it becomes opaque: twelve months of decisions and effort compressed into vague impressions. The layout returns it to you as a legible object - a disc you can hold, a pattern you can read. The circle persists because the problem persists. --- *Find the shape of your working year. Enter your GitHub username at codexstellarum.com and preview your Planisphere atlas - free to try, prints from £25.* --- # The Chronicle Layout URL: https://codexstellarum.com/blog/the-chronicle-layout Published: 2026-03-25 · Updated: 2026-03-25 Author: Codex Stellarum In the scriptorium of a Benedictine monastery, some time in the ninth century, a monk unrolled a length of parchment and began at the top. He recorded what had happened. Then the year turned, and he moved down. Then the year turned again. The record grew downward, season by season, reign by reign, in a single unbroken column of time. This was the chronicle form. It was not invented by any one person. It emerged independently across literate cultures because it reflected something true about how time actually works. It begins. It continues. It accumulates, always downward, always in sequence, with no gaps permitted and no reordering allowed. We have been making vertical timelines for over a thousand years. When a developer runs `git log`, the output is a vertical column, newest at the top, oldest receding below. Stack traces read from top to bottom. Changelogs list releases in descending order. The vertical sequence is not a convention developers happen to tolerate; it is the native shape of code work: one thing follows another, in order, without rearrangement. The Chronicle layout in Codex Stellarum is the latest version of the same idea. ## THE OLDEST INFORMATION DESIGN In 1765, the English chemist and polymath Joseph Priestley published something that had never existed before: a visual representation of history. His "Chart of Biography" plotted 2,000 years of lives along a single horizontal band, each person rendered as a line whose length corresponded to their lifespan. Time moved left to right. Density of lines signalled density of intellectual activity. The shape of human knowledge became visible at a glance. Priestley called it a "rational amusement." His contemporaries called it revolutionary. Within a decade, the idea of mapping time visually had spread across Europe. But Priestley was building on a tradition that stretched back centuries. The Anglo-Saxon Chronicle, begun under Alfred the Great in the ninth century, is one of the oldest continuous historical records in the English language. It moves in a single direction: forward. Year follows year in strict sequence, with no retroactive reorganisation and no attempt to group events thematically. The form itself makes a claim about time: it moves in one direction only, and the record must follow. In 1871, the American cartographer Sebastian Adams published his Synchronological Chart of Universal History, a twenty-three-foot continuous scroll mapping the whole of human civilisation from Eden to the present day. Scholars could unroll it, trace a dynasty from birth to collapse, and place it alongside every other dynasty unfolding in the same years. The scroll made time tangible. You could hold two centuries in your hands. All of these objects share a single structural decision: time runs in one axis, from the earliest point to the most recent, without interruption. Developers make this same decision every time they write a commit message. The log is the record. It only runs forward. ## GEOLOGICAL TIME There is a reason geologists use the vertical column as the primary model for deep time. The layer at the bottom came first. The layer at the top came last. The sequence is not a convention; it is a physical fact. Sedimentary rock records history the way the monastic chronicles recorded it: continuously, without selection, in strict order of occurrence. Every year deposits its layer. Dry years leave thin bands. Flood years leave thick ones. A volcanic eruption leaves a grey seam that can be identified at sites thousands of miles apart. The record is honest because it cannot be otherwise. The top is now. The bottom is the beginning. Everything in between is exactly where it belongs. The Chronicle layout applies this principle to GitHub contribution data. Each year occupies a horizontal band. Weeks run left to right within that band. Bands stack from oldest at the top to most recent at the bottom. Contribution density determines star brightness. The result is a layered record, read from past to present, in which nothing is hidden and nothing is reordered. Every quiet week is visible. Every burst of activity forms its own bright stratum. Read downward through the bands, and the strata of a coding career resolve into something unmistakable: the intense pre-launch week, bright and dense; the refactoring quarter, steady and even; the gap when you changed jobs and barely touched a keyboard. A side project appears as scattered bright spots that never consolidated into a sustained band. Open-source contributions surface as irregular flares around a library release or a conference talk, then fade again. The shape of a working life, read downward, accumulates into something that looks very much like geology. ## THE HONEST LAYOUT Some layouts summarise. The GitHub contribution grid, for instance, arranges the full year as a compact rectangle. It is readable at a glance, which is useful, but the glance is what you get. Individual weeks blur into colour. The shape of the year resolves into a general impression of activity or inactivity, and the fine-grained rhythm of how the work actually unfolded is lost to compression. The Chronicle layout does not compress. Every week occupies the same amount of space, regardless of what happened in it. A week with no commits sits in the record at the same visual weight as a week with fifty. This is what makes it the most honest of the available layouts. It hides nothing, because its structure prevents hiding. The gaps are fully visible. The dry spells are fully rendered. The record is complete. This will feel familiar to developers who care about their craft. The same instinct that keeps a git history clean, that writes a thorough changelog, that documents a breaking change rather than quietly shipping it, finds the Chronicle legible rather than exposing. Transparency in a codebase and transparency in a timeline come from the same disposition: a preference for the complete record over the curated summary. This is not always comfortable. Seeing a vertical timeline of your contributions means seeing everything, in sequence, from the year you began. The long quiet after a project ended. The erratic rhythm of a year when other things were consuming your attention. The three-week stretch where a single pull request sat in review and the rest of the work stalled around it. The moment when output picked up again and held. Developers who choose the Chronicle tend to want exactly this. They are not looking for a flattering summary. They are looking for a narrative: a story of how their practice has developed over time, told in the only way a story can be told: beginning, middle, now. ## NARRATIVE IN ONE AXIS Cognitive scientists distinguish between two modes of understanding: categorical and narrative. Categorical understanding groups things by type and compares across dimensions. Narrative understanding places events in sequence and derives meaning from the order of things, from what came before and what followed. Humans are constitutively narrative creatures. A sequence of events becomes a story almost automatically. We supply causation, detect turning points, anticipate resolution. The vertical timeline activates this directly. Reading downward through the Chronicle, the eye follows the same path it follows when reading text: from the established past toward the unresolved present. A dense cluster reads as a chapter. A long gap reads as a pause. A change in rhythm reads as a transition. The year you learned a new language shows up as a different texture: commits concentrated in exploratory repositories, sparser in production work, then gradually normalising as fluency arrived. The period of deep maintenance work has its own signature: steady, even, unspectacular bands that indicate a codebase being held together rather than extended. The star rendering reinforces this. Bright stars and dark voids form a landscape with features: peaks and valleys, the bright streak of an intensive period, the dark quiet that followed it. The brain reaches for the same pattern-recognition machinery it uses for reading text and for reading the night sky. The result feels less like a chart and more like a record: less like analysis and more like memory. ## READING YOUR OWN CHRONICLE When you see your contributions rendered in Chronicle form for the first time, the experience is usually one of recognition rather than discovery. The data is not new. You lived through all of it. But the vertical sequence places the familiar material in a context that makes its structure legible in a new way. The thin years and the thick ones. The period when commits came every single day. The gap that lasted longer than you remembered. The slow return to momentum, and then the steady output that followed, year by layer by year. The open-source project that briefly lit up a whole band, then receded into a faint scatter as the community took over. The side project that quietly died: a bright cluster followed by nothing, not abandoned in haste but simply outcompeted by the next thing. Sebastian Adams unrolled his twenty-three-foot scroll and saw the whole of human history at once. The Chronicle layout in Codex Stellarum offers something smaller but more personal: the whole of your own working history, in sequence, from the first contribution to the most recent, rendered as a single column of light and dark. The oldest information design still works because time has not changed its direction. --- *Your Chronicle is waiting. Enter your GitHub username at codexstellarum.com to preview your atlas - free to try, prints from £25.* --- # Connecting the Dots URL: https://codexstellarum.com/blog/connecting-the-dots Published: 2026-03-25 · Updated: 2026-03-24 Author: Codex Stellarum There are roughly 9,000 stars visible to the naked eye. They are scattered across the sky in no particular order. They are not arranged in rows. They do not form grids. They are random points of light at random distances, some a few light years away, some thousands, projected onto the same flat dome by accident of geometry. And yet, for at least 5,000 years, humans have looked at those random points and drawn pictures. A hunter. A bear. A scorpion. A lyre. The stars that form Orion's belt are not physically related to each other. Alnitak is 1,200 light years from Earth. Alnilam is 2,000. Mintaka is 1,070. They are nowhere near each other in three-dimensional space. But projected onto our sky, they form a short, neat line, and that was enough. We drew a hunter around them and named him. Constellations are the oldest example of a pattern that exists in the observer, not in the observed. --- ## The Pattern-Seeking Brain In the 1950s, German neurologist Klaus Conrad coined the term "apophenia" to describe the human tendency to perceive meaningful patterns in random information. He was studying patients with schizophrenia, where pattern recognition spirals into delusion. But subsequent research has shown that apophenia exists on a spectrum, and everyone is on it. It is a basic feature of human cognition, not a bug. The visual version has its own name: pareidolia. Seeing a face on the front of a car. Seeing the Virgin Mary on a piece of toast (which sold on eBay for $28,000 in 2004). Seeing a rabbit in the moon. Brain imaging studies show that the fusiform face area - the part of the brain specialised for recognising faces - activates at 165 milliseconds when presented with face-like objects, nearly as fast as it responds to actual human faces. The brain does not wait to confirm whether something is a face. It fires first and asks questions later. Evolutionary psychologists explain this as a survival advantage. For an early human on the savanna, mistaking a shadow for a predator costs a moment of unnecessary fear. Mistaking a predator for a shadow costs your life. The brain evolved to over-detect patterns because the cost of a false positive (seeing a pattern that is not there) is trivially small compared to the cost of a false negative (missing a pattern that is). We are descended from the nervous ones. This same machinery is what makes constellations feel real. Orion is a pattern that early humans imposed on a random scatter of photons. The pattern says more about the observer's brain than about the stars. And yet Orion has been recognised across cultures for millennia. The ancient Egyptians associated those three belt stars with Osiris. The Babylonians saw a shepherd. The Chinese saw a hunter called Shen. Different cultures, different stories, same three dots in a line. The dots do not change. The stories do. The pattern-seeking brain provides both. ## Gestalt and the Programmer's Eye In the early 20th century, a group of German psychologists developed what became known as Gestalt theory - a set of principles describing how the brain organises visual information into coherent wholes. The word "Gestalt" roughly translates as "shape" or "form," and the central insight was that perception is not a passive process. The brain actively constructs what it sees. Several Gestalt principles are directly relevant to how we read scattered data: Proximity: dots that are close together are perceived as a group, even if there is no line connecting them. A cluster of GitHub contributions in March feels like "a project" even though each dot is an independent day. Continuity: the eye follows smooth lines and curves. A spiral of stars reads as a single path, even though each star is a separate data point. The brain connects them automatically. Closure: the mind fills in gaps to complete a recognisable shape. A ring of stars with a few missing still reads as a ring. A month of contributions with a few blank days still reads as "an active month." Figure-ground: the brain separates foreground objects from their background. Bright stars stand out from the dark sky. Dense clusters of contributions stand out from the surrounding quiet. These principles are pre-conscious. You do not choose to see a cluster of dots as a group. You cannot un-see it once your brain has constructed the pattern. The Gestalt psychologists demonstrated this repeatedly: once the brain has found a pattern, the pattern becomes the reality. Programmers, incidentally, are unusually good at this. The daily work of reading code is an exercise in pattern recognition - spotting the relevant signal in dense, visually monotonous text. Debugging is almost entirely about finding the wrong pattern: the one line, among thousands, that does not belong. Senior developers describe this as "code smell" - a pre-conscious sense that something is off before they can articulate what. It is Gestalt perception applied to syntax. The same skill transfers to data visualisation. Show a developer a scatter plot and they will find structure in it faster than most people, because their visual cortex has been trained on years of dense, patterned information. They are professional pattern-finders. ## Why Scatter Plots Beat Tables In 1973, the statistician Francis Anscombe published a now-famous paper containing four data sets. Each set had nearly identical statistical properties - the same mean, the same variance, the same correlation, the same linear regression line. By every numerical measure, the four sets were the same. Plotted as scatter plots, they were wildly different. One was a clean line. One was a curve. One was a line with a single outlier. One was a vertical cluster with one distant point. The four pictures told four completely different stories, despite the numbers being identical. Anscombe's Quartet, as it came to be known, demonstrated something that statisticians already suspected but could not prove: visualisation reveals structure that summary statistics hide. The eye sees what the spreadsheet misses. The same principle applies to GitHub contributions. The raw data is a table of dates and counts. Day, number, day, number. The table tells you how much work was done. But it tells you nothing about the shape of the work. Was it clustered or spread out? Was there a burst followed by silence? Did activity build gradually or arrive all at once? A green grid answers some of these questions, but crudely. The grid is a table pretending to be a visualisation. It uses position but not shape, not proximity, not the Gestalt principles that allow the eye to extract meaning from scatter. A star atlas uses all of them. Bright stars cluster naturally. Gaps form dark voids. The eye traces the spiral or reads the bands without instruction. The brain's pattern-seeking machinery fires automatically, constructing stories from the arrangement of points: this was a productive phase, this was a break, this was the project that changed everything. The data has not changed. But the brain can now do what it evolved to do. ## Reading Your Own Sky Here is the part that nobody expects. When developers see their own contributions rendered as a star atlas for the first time, they do not read it as data. They read it as memory. The clusters trigger recognition. "That bright patch was when we launched the new API." The voids trigger recognition too. "That gap was when I was interviewing for the new job." The gradients - the slow brightening or dimming over months - map to emotional arcs that the developer lived through but never saw from the outside. This is pareidolia operating on personal data. The brain is finding patterns in scattered dots, but the patterns are real. They are not faces in toast. They correspond to actual events in the developer's life. The pattern-seeking machinery, for once, is working on genuine signal. And that is what makes the experience of seeing your atlas different from seeing a chart. Charts are read. Atlases are recognised. The distinction is in the speed. You read a bar chart by decoding axes, comparing heights, calculating differences. You recognise a star atlas the way you recognise a photograph - instantly, holistically, with feeling. The ancient stargazers did the same thing. They looked at scattered dots and saw a hunter, a bear, a lyre. Their brains were doing what all human brains do: constructing coherent shapes from chaos, imposing narrative on randomness, finding the signal that was always there. Five thousand years later, we look at scattered dots on a dark background and see something too. Not a hunter. Not a bear. A year of our life. Bright where we worked. Dark where we rested. The shape of a chapter, rendered in points of light. The dots do not change. The stories never stop. --- *Find the patterns in your own sky. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and preview your atlas - free to try, prints from £25.* --- # Seven Ages of the Developer URL: https://codexstellarum.com/blog/seven-ages-of-the-developer Published: 2026-03-24 · Updated: 2026-03-24 Author: Codex Stellarum In the 1950s, a programmer was someone who punched holes in cardboard. Each hole was a bit. Each card was a line of code. A program of modest complexity required a stack of cards thick enough to fill a shoebox. If you dropped the stack, you were in serious trouble - the cards had to be fed into the reader in exact sequence, and re-sorting a scattered deck by hand could take hours. Programmers drew diagonal lines across the edge of the stack with a felt-tip pen so they could see at a glance if a card was out of order. It looked like a barcode. It was a barcode, of a kind. Grace Hopper, who in 1952 built the first compiler - the program that translates human-readable instructions into machine code - described the experience of early programming as a form of puzzle-solving under severe physical constraints. You wrote your logic on paper. You translated it to card format. You walked the cards to the computer room, handed them to an operator, and waited. If you were lucky, the turnaround was an hour. If the system was busy, you waited until the next day. One typo meant starting the cycle over. Seventy-four years later, a developer types a sentence in plain English and an AI agent writes, tests, and deploys the code in minutes. Andrej Karpathy, who coined the term for this workflow, recently declared it had already evolved past its original name. The practice once called "vibe coding" is now "agentic engineering" - orchestrating autonomous systems that do the typing for you. Between the punch card and the agent, the job changed seven times. Each change felt like the end of programming. Each time, the programmer survived by becoming something else. --- ## Age 1: The Machine Whisperer (1940s-1960s) The first programmers were mathematicians. They worked in machine code and assembly language - raw binary instructions that mapped directly to the hardware. Writing a program meant understanding, at the level of individual electrical signals, what the computer was physically doing. The abstraction layer between the programmer and the machine was zero. These early practitioners were not called programmers. They were called "computers" - the same word used for the humans (mostly women) who had performed calculations by hand during the war. The machines inherited the job title. The humans kept it for a while, awkwardly, until new vocabulary caught up. The skill required was patience. A single program could take weeks to write and debug. Errors were caught by re-reading code printed on fan-fold paper, line by line, looking for a misplaced bit. The computer offered no help. It did exactly what you told it, which was almost never what you meant. ## Age 2: The Language Speaker (1960s-1980s) FORTRAN arrived in 1957. COBOL in 1959. BASIC in 1964. C in 1972. Each language added a layer of abstraction between the programmer and the hardware. Instead of specifying electrical signals, you could now write something that resembled English - or at least resembled mathematics. This was the first time the profession predicted its own death. If machines could understand FORTRAN, went the argument, then soon they would understand plain English, and programmers would be unnecessary. That prediction has been made, in various forms, every decade since. It has been wrong every time, for the same reason: the bottleneck was never the typing. It was the thinking. The languages freed programmers from hardware. The cost was that a new skill became essential: reading other people's code. With machine code, every program was bespoke - written from scratch for a specific machine. With high-level languages, code became portable and reusable, which meant inheriting someone else's decisions, someone else's naming conventions, someone else's bugs. The ability to understand a codebase you did not write became as important as the ability to write one. ## Age 3: The Toolmaker (1980s-1990s) Personal computers changed who could be a programmer. Before the PC, programming required access to a mainframe - which meant working at a university, a corporation, or a government lab. After the PC, programming required a desk and a power outlet. The 1980s and 1990s were the age of the toolmaker. Developers built the tools that other developers used. Compilers, editors, debuggers, version control systems, build tools. The infrastructure of software development itself became a domain of specialisation. Richard Stallman wrote GNU Emacs. Linus Torvalds wrote Git. James Gosling wrote Java. The cultural shift was significant. Programming stopped being a craft practiced in isolation and became a community activity. Bulletin boards, Usenet groups, and eventually mailing lists connected programmers across geographies. For the first time, a developer in Finland could collaborate with a developer in California without either one leaving their desk. Open source was born not from a philosophy but from a practical reality: shared tools made everyone faster. ## Age 4: The Web Builder (1995-2010) The web changed what software was for. Before the browser, software was a product you installed from a disk. After the browser, software was a service you accessed through a URL. The distinction sounds trivial. It transformed everything. Web development introduced a new species of programmer - one who needed to understand not just logic but design, not just data but users, not just performance but accessibility. The full-stack developer emerged: a person who could wire a database to a server to a browser and make the result look presentable. HTML, CSS, JavaScript, PHP, MySQL, Apache. The stack kept growing. Nobody mastered all of it. Everyone pretended to. The web also introduced a new tempo. Software shipped in real time. A bug could be fixed and deployed within the hour. This was exhilarating after decades of shrink-wrapped release cycles, but it also meant the work was never finished. Software became a living system that required continuous maintenance, and the developer became its caretaker. ## Age 5: The Stack Assembler (2010-2020) Somewhere around 2010, the job of a software developer shifted from writing code to choosing code. The explosion of open source libraries, frameworks, and platforms meant that most of the hard problems had been solved by someone else. Your job was to find the right package, wire it up correctly, and handle the edge cases. Stack Overflow launched in 2008. Within a few years, it became the single most important resource for working developers - more useful than any documentation, any textbook, any mentor. The running joke was that programming had become the art of copying from Stack Overflow and modifying until it worked. The joke was funny because it was partly true. GitHub launched in the same year. It turned code sharing from a fringe activity into the default mode of professional development. Your GitHub profile became your resume. Your contribution graph became your proof of work. The skill in this era was integration. The best developers were not the ones who wrote the most elegant algorithms. They were the ones who could glue together fifteen different libraries, deploy to three cloud providers, configure a CI/CD pipeline, and ship a working product before the competitor did. Speed replaced elegance as the primary virtue. ## Age 6: The Prompt Whisperer (2022-2025) GitHub Copilot launched in 2021. ChatGPT launched in November 2022. Within eighteen months, 84% of developers reported using or planning to use AI-assisted programming in their workflow, according to Stack Overflow's 2025 survey. The term "vibe coding" was coined by Karpathy in February 2025 to describe a workflow where the developer describes intent in natural language and accepts whatever the model produces. "I just talk to Composer with SuperWhisper so I barely even touch the keyboard," he wrote. "I 'Accept All' always, I don't read the diffs anymore." Collins Dictionary named it Word of the Year for 2025. The speed was staggering. Twenty-five percent of Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. Garry Tan, YC's CEO, called it a paradigm shift. CEOs who had not written code in a decade - Tobi Lütke at Shopify, Brian Armstrong at Coinbase - returned to active development. Lütke went from 94 commits in all of 2024 to 957 in the first 45 days of 2026. But vibe coding had a problem. It worked for prototypes and demos. It broke in production. The code looked correct on the surface but lacked error handling, introduced security vulnerabilities, and created unmaintainable architecture. The industry coined a term for this too: "AI slop." The skill in this era was judgment. You did not need to type the code. You needed to know if the code was right. The bottleneck moved from production to evaluation - from "can you build this?" to "should you ship this?" ## Age 7: The Orchestrator (2026-) In February 2026, on the one-year anniversary of coining "vibe coding," Karpathy declared the term passé. He proposed a replacement: agentic engineering. "Agentic, because the new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight. Engineering, to emphasize that there is an art and science and expertise to it." The shift from vibe coding to agentic engineering mirrors every previous transition in the profession. A new layer of abstraction is added. The old skill is automated. A new skill emerges. The developer survives by moving up the stack. In the orchestrator age, the developer does not write code. They do not even prompt a model. They design systems of agents - specialised AI workers that research, plan, write, test, review, and deploy in parallel. The developer defines the architecture, sets the quality gates, reviews the output, and maintains accountability. Stripe's agent system produces over 1,000 merged pull requests per week. The human developers supervise. The word "developer" itself may not survive this transition. "Agentic engineer" is the current candidate. But the history of the profession suggests that titles change faster than skills, and the core skill has been the same across all seven ages: understanding what needs to be built, and making sure it gets built correctly. Punch cards required it. Assembly required it. FORTRAN required it. The web required it. Stack Overflow required it. Copilot required it. Agent swarms require it. The tools change. The thinking doesn't. --- ## What Your Atlas Shows Every age leaves a trace on the contribution graph. The Stack Assembler era shows up as dense, steady activity - daily commits, continuous integration, the rhythm of a well-oiled pipeline. The Prompt Whisperer era shows up as sudden bursts - rapid prototyping, quick spikes of output that appear and disappear. The Orchestrator era is still being written, and its pattern is not yet clear. But here is what is already visible: the graphs are getting brighter. More commits, more frequently, across more projects. The tools are amplifying output in ways that show up as physically denser star fields on the atlas. The developers of 2026 are producing more visible artifacts per day than the developers of 2020, who produced more than those of 2010. The atlas does not show which lines were typed by a human and which by an agent. It does not distinguish vibe-coded prototypes from carefully reviewed production code. It shows only that work happened, that someone showed up, that something was built. Across seven ages, that has never changed. --- *See the shape of your own era. Enter your GitHub username at [codexstellarum.com](https://codexstellarum.com) and preview your atlas - free to try, prints from £25.* --- # The Shape of Your Code URL: https://codexstellarum.com/blog/the-shape-of-your-code Published: 2026-03-23 · Updated: 2026-03-24 Author: Codex Stellarum Every developer's GitHub contribution graph tells a story. Not the story GitHub thinks it's telling - not "this person made 4 contributions on a Tuesday" - but a deeper one. A story about rhythm, obsession, rest, and reinvention. We've rendered thousands of these graphs as star atlases since launching Codex Stellarum, and patterns have emerged. Not patterns in the data - patterns in the lives behind the data. Here are the ones we see most often. --- ## The Steady Orbit Some developers have contribution graphs that look like a heartbeat - consistent, rhythmic, unbroken. Day after day, week after week, the same steady pulse of commits. These aren't necessarily the most prolific contributors. They're the most disciplined. On a star atlas, the Steady Orbit looks like a continuous band of evenly-spaced stars. No dramatic flares, no dark gaps. Just light, all the way through. It's the kind of pattern you see from senior engineers who've been at the same company for years, or from open-source maintainers who treat their project like a garden - tending it daily. There's something deeply beautiful about consistency. In a world that celebrates launches and breakthroughs, the Steady Orbit is a quiet monument to showing up. ## The Supernova Then there's the opposite: long stretches of near-silence, punctuated by explosive bursts of activity. Weeks of nothing, then suddenly 40 commits in a day. Then silence again. The Supernova pattern shows up as dramatic clusters of bright stars surrounded by dark void. It's visually stunning - the contrast makes the active periods burn even brighter. This is the pattern of builders. People who get seized by an idea and disappear into it for a week. Hackathon winners. Weekend project addicts. Founders in the early days of a startup, writing code like their life depends on it - because for a while, it does. The gaps aren't laziness. They're recharging. The Supernova needs darkness to burn. ## The Renaissance This one is the most fascinating pattern of 2025 and 2026 - a graph that was nearly dark for years, then suddenly ignites. The most dramatic example might be Shopify CEO Tobias Lütke. His GitHub profile tells the story in three numbers: 94 contributions in all of 2024. Then 833 in 2025. Then 957 in just the first 45 days of 2026. A near-vertical spike after almost a decade of near-silence. Lütke built the original Shopify codebase himself in 2004 using Ruby on Rails. Then he did what every founder-CEO does - drifted into meetings, board decks, and strategy. The thing that made him dangerous collected dust for twenty years. Until AI coding tools brought him back. In March 2026, he used an AI agent to run 120 automated experiments on Shopify's Liquid template engine, landing a pull request that made it 53% faster. The CEO hadn't just returned to the codebase - he was shipping performance improvements to production. He's not alone. Coinbase CEO Brian Armstrong posted his own GitHub graph on X in February 2026 with the caption: "Beware, it's 2026 and the CEO is back in the code base thanks to AI." Y Combinator CEO Garry Tan has been open about staying up until 5am building with Claude Code - then publicly revealing that 25% of YC's Winter 2025 batch had codebases that were 95% AI-generated. On a star atlas, the Renaissance is the most hopeful pattern there is. Darkness giving way to light. A sky that was nearly black, filling with stars. It proves that chapters end, but the book doesn't. And the current chapter being written across the industry is remarkable: the people who stopped coding a decade ago are building again. Not because they have to. Because the tools finally let them. ## The Fade This one is bittersweet. A graph that starts dense and bright, then gradually thins out. The stars get fainter. The gaps get wider. The trail ends. The Fade can mean many things. A developer who moved into management and stopped writing code. Someone who burned out and stepped away. A person who found a different passion. Or simply someone whose work moved to a private repository that GitHub's public graph can't see. On a star atlas, the Fade looks like a comet trail - bright at the head, dissolving into darkness. It's one of the most poignant patterns we see, because it reminds you that every graph is a snapshot of a specific chapter, not the whole book. ## The Seasons Some graphs have a clear cyclical rhythm. Active in winter, quiet in summer. Or the reverse - alive during conference season, dormant in December. You can see holidays, academic semesters, fiscal quarters. The Seasons pattern is particularly visible on the Planisphere layout, where months orbit the circumference like hours on a clock. The seasonal rhythm becomes literal - you can see which months of the year this person writes the most code, year after year. It's a reminder that developers are human. We have rhythms. We're affected by weather, holidays, deadlines, and the simple fact that sometimes you need to close the laptop and go outside. ## The Constellation Finally, there's the pattern that defies categorisation. A graph so unique, so idiosyncratic, that it doesn't fit any archetype. Dense clusters here, scattered points there, a strange gap in the middle, an unexpected burst at the end. Every atlas is a Constellation, really. The archetypes above are just lenses - ways of reading a pattern that is, ultimately, as unique as a fingerprint. No two developers have the same graph. No two have the same story. That's the whole point of Codex Stellarum. We don't think your contribution history should be reduced to a number or a colour-coded grid. We think it should be art. Because the shape of your code is the shape of a chapter of your life, and that deserves to be beautiful. --- *Want to see the shape of your code? Enter your GitHub username on [our homepage](https://codexstellarum.com) and preview your atlas for free.*