The Green Squares: When a Color Becomes a Career

The Grid

This is episode fourteen of Git Good, Season Two.

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. Dark green means a lot of activity. Pale green means a little. Gray means nothing. A day that, as far as GitHub is concerned, did not happen.

GitHub introduced this contribution graph in two thousand thirteen. The idea was modest. A heat map of activity. Commits, pull requests, issues, code reviews, all reduced to a color gradient on a profile page. A small decorative feature. A glanceable summary of what someone had been up to.

It quietly became one of the most psychologically powerful interfaces in all of software development. Not because of what it shows, but because of what people decided it means. This is the story of a visualization that became a measure of worth, a hiring signal, a gamification trap, and finally, a target for machines. Four things it was never designed to be. Four things it became anyway.

The Chain

In two thousand fourteen, John Resig published a blog post that would reshape how thousands of developers thought about their daily work. Resig had created jQuery, the JavaScript library that powered half the interactive web. But he was struggling with side projects. Weekend bursts of energy followed by weeks of nothing. Context lost, momentum gone.

So he made a rule. Write meaningful open source code every day. Push it to GitHub before midnight. No exceptions. The idea borrowed from a productivity trick attributed to Jerry Seinfeld. Mark an X on the calendar every day you work. Watch the chain grow. The psychological weight of the unbroken chain makes it harder to skip than to sit down and do the work.

The GitHub contribution graph became the calendar. The green square became the X. And the culture of the streak was born.

There was something Resig wrote that most people who adopted the practice missed entirely. 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.

GitHub did not just show the contribution graph. It showed your streak. Right there on your profile, a number. Your current streak in days. Your longest streak ever. Two numbers, prominently displayed, that turned a personal practice into a public scoreboard.

A developer named Karan Goel started his streak in the summer of two thousand thirteen. He was a freshman at the University of Washington, not yet accepted into the computer science department, without an internship. The goal was simple. One Python problem a day for thirty days. Learn the language, learn Git, build discipline.

Those thirty days became three hundred. Three hundred became five hundred. Five hundred became eight hundred and forty-four.

I found myself looking for ways to get new green squares, thinking less about the quality of my contributions and more about maintaining the streak.

Eight hundred and forty-four days meant nothing had interrupted his output for over two years. Not weekends, not holidays, not illness, not exhaustion. The number had become the point. Not the learning. Not the code. The number. Goel ended the streak deliberately. Not because he wanted to stop coding, but because the streak had replaced the reason he started.

He was 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 auto-committed to private repositories so the graph would stay green while they slept. The streak counter had turned a version control platform 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 with a title that was impossible to misread. 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 precise. The contribution graph itself was fine. The streak counter was the problem. It rewarded 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. The counter did not care why you missed a day. It only knew that you had. And it reset you to zero.

The community split. Some developers agreed the gamification had gone toxic. Others pushed back. The streak was motivating. It fought procrastination. Programming was a hobby, and the chain helped them stick with it.

Within two months, GitHub quietly removed the streak counter. The current streak and longest streak numbers vanished from profiles. The contribution graph stayed, still showing that year of green and gray squares. But the explicit scoreboard was gone. GitHub said the simplified interface focuses on the work you are doing rather than the duration of your activity. A diplomatic way of admitting the counter had done more harm than good.

Sixty-seven people gave a thumbs up to an issue asking why the streak had been removed. The crutch was gone, and some people had needed it.

But removing the counter did not solve the deeper problem. The graph was still there. And people were still reading it. Specifically, the people making hiring decisions.

The Resume You Never Wrote

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 nobody wrote and nobody could 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.

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. And when they see a year of gray, they are not seeing laziness. They might be seeing a parent, a caregiver, a developer who writes excellent code for forty hours a week at a company that does not open source anything.

Consider the team developer. Ten years of experience shipping production systems. Hundreds of thousands of lines of code behind corporate firewalls. Never committed to a public repository once. Their GitHub profile is a wasteland of gray squares. In an interview, the hiring manager pulls up the profile, sees the empty grid, and forms an opinion before the candidate finishes introducing themselves.

Now consider the vibe coder. Six months of experience, all of it generated by AI tools. Their graph is a constellation of green. Not because they wrote more code, but because every prompt they gave to an AI assistant produced commits, and every commit colored a square. They did not game the system on purpose. The system gamed itself.

The contribution graph is simultaneously demanded by hiring managers and meaningless as a signal. A developer on Hacker News put it bluntly, with five hundred upvotes. Expecting developers to have a link to GitHub repos is toxic as fuck.

The Market for Green

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 who observed in nineteen seventy-five that 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.

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 called github-spray. A third does not bother with a clever name. It is just called Fake Contributions.

Beyond the free tools, there is a paid economy. Sellers offer pre-loaded GitHub accounts, profiles stacked with contributions to popular repositories and fabricated commit histories, for up to five thousand dollars. Basic accounts 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 the textbook progression. A visualization becomes a signal. A signal creates demand for fake signal. Fake signal destroys the original signal. And nobody can tell the difference between a developer who committed meaningful code every day for a year and a developer who ran a Python script for thirty seconds.

But that was the human version of the problem. The machine version is worse.

The Flood

In February of two thousand twenty-six, Remi Verschelde, a maintainer of the open source game engine Godot, posted a message that ricocheted through the developer world. AI-generated pull requests were drowning his project. Not one or two. A constant, rising tide. Submissions that looked plausible at first glance but contained broken logic, fundamental errors, and code that made no sense in context. The people submitting them had not tested the code. Many had not read it. They had prompted an AI, copied the output, and opened a pull request.

I do not know how long we can keep it up.

The Godot thread collected over three thousand upvotes. The community called it an existential crisis for every single large open source project. Not because AI code is inherently bad. But because the volume overwhelms the humans who have to review it. Every bad pull request that a maintainer has to read, evaluate, and close is time stolen from actual development. And the ratio is brutal. The people submitting AI-generated pull requests can create them in seconds. The people reviewing them need minutes or hours to determine they are worthless. The asymmetry favors the machines.

When someone suggested using AI to detect AI-generated submissions, Verschelde called it horribly ironic. Fight the flood of machine output by adding more machines. He was not keen on feeding the AI machinery.

Godot was not alone. In March of two thousand twenty-six, the Jazzband collective shut down. Jazzband had been a ten-year experiment in cooperative open source maintenance for Python projects. Everyone who joined got access to push code, triage issues, and merge pull requests. The model worked for a decade. Then AI-generated spam made open membership untenable. Only one in ten AI-generated pull requests met project standards. The collective announced its sunsetting and began coordinating project transfers.

Daniel Stenberg killed curl's bug bounty program after AI-generated submissions made it useless, a story episode seventeen will tell in full. The pattern is the same in every case. Maintainers are drowning in submissions from people who are not trying to contribute. They are trying to get their name on a project. A green square on a graph. A line on a resume. The AI makes it trivially easy to produce something that looks like a contribution, and the maintainers are left holding the cost of determining that it is not.

Four Perspectives on the Same Grid

The contribution graph means something different depending on where you stand. And the distance between those meanings tells you everything about how broken the signal has become.

The solo developer does not care. Their repositories are private. Their audience is themselves. The graph is a screensaver they never look at. It exists on their profile the way a potted plant exists in a dentist's waiting room, decorative, irrelevant, noticed by no one. They commit when they feel like it. They go weeks without pushing anything. The gray squares do not bother them because nobody is watching. For the solo developer, Git is a save button, not a stage. The graph is an artifact of a social layer they never opted into.

The vibe coder farms it without knowing they are farming it. Every AI-assisted commit fills a square. Every prompt that produces a push produces green. Their graph looks healthy, active, productive. They did not game the system. They did not even think about the system. The system just happens to count everything the AI does under their name. Ask them about their contribution graph and they will look at you blankly. They do not know what it is. They do not know that the commits their AI tool made on their behalf are being tallied, displayed, and read by strangers making judgments about their competence. The graph says they are prolific. What the graph does not say is how much of the work was theirs.

The team developer is judged by it. Their manager pulls up GitHub profiles during quarterly reviews. The recruiter at the next company scans the grid before deciding whether to schedule a phone screen. Ten years of shipping production code in private repositories, invisible. Six months of AI-assisted side projects, a wall of green. The graph punishes the people who do the work that matters most and rewards the people who produce the most visible artifacts, regardless of value. The team developer knows this. They resent it. But they also maintain a personal GitHub account with weekend projects, just in case, because the alternative is showing up to an interview with a gray grid and trying to explain that their real work lives behind a corporate firewall.

The open source maintainer is drowning in it. Every AI-generated pull request is another square on someone else's profile and another hour of their unpaid time. The maintainer's own graph might be sparse, because review and triage and saying no to bad code do not always produce commits. The people flooding their project with machine-generated noise have greener profiles than the people keeping the project alive. The maintainer closes the twentieth bad pull request of the week, and the person who submitted it walks away with twenty green squares and a line on their resume that says "contributor to Godot Engine." The maintainer walks away with nothing except less time to do the actual work.

The Signal That Collapsed

Here is the argument this episode has been building toward, and it is not subtle. The contribution graph is broken. Not because of a design flaw. Because of success.

GitHub built a visualization. Hiring managers turned it into a metric. The metric created incentives to game it. Gaming destroyed the signal. And then AI automated the gaming at a scale that humans cannot match. Every step was predictable. Every step happened anyway.

The strongest counterargument is that the graph was never meant to be a hiring signal, and blaming GitHub for how recruiters use it is like blaming a thermometer for the weather. That is fair. GitHub did not tell anyone to hire based on green squares. But GitHub did put the graph on every profile, did count streaks, did add badges for contribution thresholds. They gamified a platform used by tens of millions of developers and then expressed surprise when the gamification produced pathological behavior.

Some projects are experimenting with progressive trust systems. New contributors face increasing barriers before their pull requests get human attention. First contribution? Automated checks only. Second? A bot review. Third? Maybe a human looks. The idea is to make the cost of submitting garbage high enough that the people farming green squares move on to easier targets. It is triage by friction. It works, but it also makes contributing to open source harder for everyone, including the genuine first-time contributor who just wants to fix a typo.

GitHub itself considered a kill switch for pull requests, a way for maintainers to disable external submissions entirely. Think about what that means. The platform that made open source contribution accessible with a single button is now building tools to make contribution harder, because the accessibility it created is being exploited at industrial scale.

The contribution graph started as a mirror. A reflection of what you actually did. Then it became a mask. A performance of what you wanted people to think you did. Now it is becoming noise. A jumble of human and machine activity that tells you almost nothing about the person behind the profile.

And that is the uncomfortable truth that runs underneath this entire episode. We have never been able to measure developers. 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. 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.

The green squares look simple. A year of work, reduced to a color gradient. But underneath that gradient is a story about anxiety, privilege, gaming, and machines. A story about what happens when you reduce human contribution to a color and then let the world decide what that color means.

Git was designed to track who changed what and when. That information was meant for debugging, for archaeology, for understanding how code evolved. Somewhere along the way, we took that metadata and built a culture around it. A culture that rewards visibility over value, quantity over quality, and presence over impact. The contribution graph did not create that culture. But it gave it a scoreboard. And now that the machines are playing, the score does not mean anything at all.

That was episode fourteen of Git Good, Season Two.

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.