The Green Squares

The Grid

This is episode twenty-eight of Git Good. Open any developer's GitHub profile and you will see a grid. Three hundred and sixty-five squares, one for each day of the year, arranged in columns like a calendar rotated on its side. Each square is a shade of green. A pale square means a little activity. A dark square means a lot. A gray square means nothing at all. Nothing committed, nothing reviewed, nothing opened. A day that, as far as GitHub is concerned, did not happen.

GitHub introduced this contribution graph in two thousand thirteen. The original idea was modest. A simple visualization of activity. A way to glance at a profile and get a sense of what someone had been working on. The design borrowed from a concept that was already floating around the internet, heat maps that showed density of activity over time. GitHub applied it to commits, pull requests, issues, and code reviews, then placed it prominently on every user's profile page.

It was a small feature. A decorative touch on a profile page. And it quietly became one of the most psychologically powerful interfaces in all of software development.

Last episode, we looked at how code review creates social dynamics between developers. This episode is about what happens when those dynamics get quantified. When your work becomes a color. When a color becomes a signal. And when a signal becomes a trap.

The Chain

In two thousand fourteen, John Resig published a blog post that would influence thousands of developers. Resig was already famous. He had created jQuery, the JavaScript library that powered half the interactive web. But he was struggling with side projects. He would work on them in intense weekend bursts, then lose momentum during the week. The gaps between sessions grew longer. Context evaporated. Projects stalled.

So Resig made himself a rule. He would write code every single day. Not just any code. Useful code. No reformatting, no indentation tweaks, no busywork. The code had to be open source, pushed to GitHub before midnight. Every day. No exceptions.

The feeling of making progress is just as important as making actual progress. This was a change I was making in my life for myself, not a change I was making to satisfy someone else's perception.

The idea was borrowed from a productivity trick attributed to Jerry Seinfeld. Write every day. Mark an X on the calendar. Watch the chain of Xs grow. Do not break the chain. The psychological weight of the unbroken chain makes it harder to skip a day than to just sit down and do the work.

Resig was nearing twenty consecutive weeks when he wrote about it. The blog post spread. Developers read it and started their own chains. The GitHub contribution graph, that grid of green squares, became the calendar. The green square became the X. And the culture of the streak was born.

There is something Resig wrote that most people who adopted the practice missed. He said the habit was for himself, not for anyone else's perception. That distinction matters enormously. Because what happened next was that the green grid stopped being a personal tool and became a public performance.

The Thousand-Day Trap

GitHub did not just show the contribution graph. It showed your streak. Right there on your profile, a number: your current streak, in days. How many consecutive days you had made at least one contribution. And your longest streak ever. Two numbers, prominently displayed, that turned a personal practice into a public scoreboard.

A developer named Amit Goel started his streak in the summer of two thousand thirteen. The goal was simple. One Python problem a day for thirty days. Those thirty days became three hundred. Three hundred became five hundred. Five hundred became eight hundred and forty-four.

Somewhere along the way, the streak changed from a learning tool into something else. Goel noticed himself thinking less about the quality of his contributions and more about acquiring new green squares. The anxiety was not about the code. It was about the number. Eight hundred and forty-four days meant nothing had interrupted his output for over two years. Not weekends, not holidays, not illness, not exhaustion.

He ended the streak deliberately. Not because he wanted to stop coding, but because the streak had become the point instead of the coding.

Jed Watson, the creator of KeystoneJS, maintained a streak that exceeded a thousand days. He wrote about how it followed him through life milestones, the launch of his open source project, the birth of his daughter. A thousand days without a single gap. The streak became a companion, then a compulsion, then an obligation.

And they were not alone. Developers around the world were making empty commits at eleven fifty-five at night to keep their numbers alive. Pushing trivial changes on Christmas morning. Writing bots that would auto-commit to private repositories so the graph would stay green while they slept. The streak counter had turned a version control tool into a treadmill, and stepping off felt like failure.

The Intervention

In April of two thousand sixteen, a developer named Sasha Romijn opened an issue on GitHub. The title was direct. The contribution graph can be harmful to contributors.

Any mechanism in our community that motivates people to avoid taking breaks can be harmful to the well-being of contributors. When I see someone with a four-hundred-and-sixteen-day streak, it means they have not taken a break for a single day in over a year.

The argument was not that the contribution graph was useless. It was that the streak counter specifically created perverse incentives. The graph rewarded people for working on as many different days as possible, which meant penalizing anyone who took a weekend off, went on vacation, got sick, or simply decided that a Saturday was for something other than code. GitHub streaks counted every day. Weekends. Holidays. The day your child was born. The day you buried a parent. Miss one, and the number reset to zero.

The community response split cleanly. Some developers agreed. The gamification had gone too far. Others pushed back. The streak was motivating. It helped them maintain side projects. It fought procrastination. Programming was a hobby, they argued, not exploitation.

But within two months of Romijn's issue, GitHub quietly removed the streak counter. The current streak and longest streak numbers vanished from profiles. The contribution graph itself stayed, still showing that year of green and gray squares. But the explicit scoreboard was gone. GitHub's statement was measured.

They said the simplified interface focuses on the work you are doing rather than the duration of your activity. It was a diplomatic way of admitting the streak counter had done more harm than good.

Not everyone was grateful. Issue one sixty-three on the dear-github repository asked why the streak had been removed. Sixty-seven people gave it a thumbs up. The streak had been a crutch, but some people needed that crutch, and nobody had asked them before taking it away.

The Resume

Removing the streak counter did not solve the deeper problem. The contribution graph still sits on every GitHub profile, and people still read it. Specifically, hiring managers read it.

Somewhere in the early twenty-tens, a quiet shift happened in tech hiring. Recruiters started looking at GitHub profiles. Not just for the code, but for the graph. A year of solid green signaled dedication. A year of mostly gray signaled laziness, or worse, irrelevance. The contribution graph became a resume line that you never wrote and could not control.

In two thousand thirteen, a programmer and diversity advocate named Ashe Dryden published an essay called "The Ethics of Unpaid Labor and the OSS Community." The numbers she cited were stark. Only one and a half percent of free and open source software contributors were women, compared to twenty-eight percent in proprietary software. Twenty-four percent of the tech industry overall.

The belief that everyone starts off with the same level of access to opportunity, time, and money is demonstrably false. Fifty-nine to seventy-five percent of caregivers are women. When you hire based on GitHub activity, you are hiring based on free time. And free time is not equally distributed.

The argument cut deep because it was so obviously correct. Open source contribution requires free time. Free time requires either a job that pays well enough that you are not exhausted after work, or no caregiving responsibilities, or both. The demographics of who has those things are not random. They track along lines of gender, race, and economic class. When a hiring manager looks at a contribution graph and sees a year of green, they are not seeing dedication. They are seeing privilege.

Dryden noted that many women in open source used gender-ambiguous usernames and avoided posting photos of themselves, because discrimination happened that quickly. Some had stopped contributing entirely after harassment. The green squares that were supposed to represent merit were actually representing who could afford to work for free and who felt safe enough to do it publicly.

Five years later, even GitLab, a company built entirely on open source, published a blog post arguing that hiring based on open source contributions could be harmful. They recommended alternatives. Code samples. Panel interviews. Take-home assessments. Anything other than treating a green grid as proof of competence.

A developer named Claire Parker-Jones, who had herself maintained a streak exceeding a hundred days, put it plainly in a two thousand eighteen blog post.

Contributions do not represent effort or time spent. A commit could be a feature you spent two hours on, or it could be a quick fix that took two minutes. A commit that changes one character is represented the same way as a ten-file commit. The green graph is a false representation of a developer's ability.

She was right. The graph tells you that something happened on a given day. It does not tell you what, or how hard it was, or whether it mattered. But the graph is still there. And hiring managers are still looking at it.

The Market

Here is where the story turns dark. If a metric determines who gets hired, people will game it. That is not cynicism. That is Goodhart's Law, named for the British economist Charles Goodhart, who observed in nineteen seventy-five that any statistical regularity will collapse once pressure is placed upon it for control purposes. The popular version is simpler. When a measure becomes a target, it ceases to be a good measure.

The contribution graph became a target. And a market formed to serve it, one that would make the entire concept of the graph absurd.

There are now at least five tools on GitHub itself, with a combined eighteen thousand stars, dedicated entirely to faking contribution graphs. They generate backdated commits. They let you click any date on a calendar and assign a commit count. They paint pictures in your green grid, literally turning your contribution history into pixel art. One tool is called GitHub Painter. Another is simply called Fake Contributions.

Beyond the free tools, there is a darker economy. Sellers offer pre-loaded GitHub accounts, profiles stacked with contributions to popular repositories and long commit histories, for up to five thousand dollars. Basic accounts, the ones with a stock photo and a handful of random commits, go for about twenty-five dollars. If a vanity metric exists on a profile, someone has figured out how to sell it.

This is Goodhart's Law in its purest form. The contribution graph was supposed to show activity. It became a hiring signal. The hiring signal created demand for fake activity. The fake activity made the signal unreliable. And now nobody can tell the difference between a developer who committed code every day for a year and a developer who ran a Python script for thirty seconds.

The Ghost in the Graph

And then came the machines. If human gaming was not enough to destroy the contribution graph's credibility, artificial intelligence finished the job.

In two thousand twenty-five, GitHub's own data showed that its AI coding agent was contributing to approximately one point two million pull requests per month. An analysis of over one hundred and thirty-five thousand developers found that twenty-two percent of merged code was AI-authored. Not AI-assisted. AI-authored. Written by a model, reviewed by a human, merged into the codebase.

Every one of those AI-authored contributions colors a green square on someone's profile. The machines are filling in the grid, and the humans get the credit.

The question that nobody has a clean answer to is whose square it is. If Copilot wrote the function and you reviewed it and clicked merge, is that your contribution? If an AI agent opens a pull request that fixes a bug you described in an issue, and you approve it, did you do the work? The contribution graph does not know. It counts events. A commit happened. A pull request was merged. A square turns green. The graph has no concept of authorship, only attribution.

This is the final stage of the contribution graph's journey from useful visualization to meaningless decoration. First, people gamed it with empty commits. Then, people gamed it with purchased accounts. Now, machines are filling it in automatically, and the humans whose profiles they decorate may not have written a single line of the code those squares represent.

Season one of this series told you about a tool that was built on trust. Git tracks authorship because Linus Torvalds needed to know who wrote every line of kernel code. The contribution graph took that authorship data and turned it into a leaderboard. AI took that leaderboard and filled it with ghosts. The next episode looks at what happens when the sheer volume of code, human and machine alike, overwhelms the systems we built to manage it. The scale problem.

But the contribution graph is not really about code. It never was. It is about the uncomfortable question that software development has never been able to answer. How do you measure a developer?

Lines of code is meaningless. A brilliant refactoring that deletes a thousand lines is more valuable than a thousand lines of spaghetti. Commits per day is gameable, as we have just seen. Code review quality is real but nearly impossible to quantify. Impact is subjective. The developer who spent a week thinking about an architecture and then wrote fifty lines that solved the problem permanently does not show up on any graph. The developer who churned out five hundred commits of incremental fixes lights up like a Christmas tree.

Every metric we have invented for developer productivity has been gamed, manipulated, or rendered meaningless within years of its adoption. Story points get inflated. Velocity gets optimized for the chart instead of the product. Pull request counts incentivize splitting work into tiny pieces. The contribution graph is just the most visible example of a universal problem. We want to measure something that resists measurement. And every time we try, we change the thing we are measuring.

That was episode twenty-eight. The green squares look simple. A year of work, reduced to a color gradient. But underneath that gradient is a story about anxiety and performance, about who gets to be visible and who gets erased, about a metric that started as a mirror and became a mask. The squares are still there on every profile, still green, still gray, still being read by people making decisions about careers and worth. The only honest thing to do with them is to admit what they have always been. A picture of activity that tells you almost nothing about the person behind it.

Git shortlog with the dash s and dash n flags. It counts commits per author and sorts them, most prolific first. The output is a leaderboard. Run it on any repository and you will see who committed the most, which is not the same as who contributed the most, which is not the same as who mattered the most. The person at the top might be a bot. The person at the bottom might have written the one commit that saved the project. Shortlog gives you a number. What you do with that number says more about you than it says about the code.