What Makes a Great Developer? What 2.5M Public Profiles Show

Ask ten engineering leaders what makes a great developer and you will get ten answers, most of them about attitude. Curiosity. Ownership. Communication. All plausible, all unfalsifiable, and none of them much use at four o'clock on a Tuesday when you are staring at a list of two hundred candidates.

So we went the other way. We took the aggregate activity data behind 2.5 million public developer profiles and asked a narrower question: which observable signals actually vary between developers, and which ones only look like they do?

This is not a claim to have measured greatness. Public code is a partial view — plenty of excellent engineers work almost entirely in private repositories, and the data says nothing about how someone behaves in a code review or handles a production incident. But it does let us test a few widely repeated beliefs against something other than intuition.

The median developer is far less prolific than you think

Start with the baseline, because almost everyone gets it wrong.

Across the largest skill populations, the median developer has around 24 public repositories, 42 contributions in the last year, and 8 followers. Not 300 commits a month. Not a starred side project. Twenty-four repositories, most of them dormant, and roughly one public contribution every nine days.

This matters more than it sounds. If your mental model of a strong candidate is someone with a busy contribution graph, you have set a bar that the median engineer in every major language fails to clear — including a large share of the people currently doing excellent work at companies you admire.

The practical version: contribution volume is a terrible primary filter. It is fine as a tiebreaker between two otherwise similar profiles. As a screen, it mostly selects for people who happen to work in the open, which correlates with employer policy and career stage far more than with skill.

Where signals actually separate

The interesting result is not the medians. It is which numbers move when you change the population.

Contributions barely budge across languages — 39 to 47 across most of the table above. But two things do move.

Followers move with language age and community. C developers show a median of 12 followers and Bash developers 15, against 8 for JavaScript and Python. That is not a statement about ability. It reflects smaller, older, more tightly networked communities where the same people keep showing up. Reading follower count as a proxy for reputation works within a community and breaks completely across them.

TypeScript is the outlier on contributions, at 69 against a field of roughly 42. The likely explanation is selection rather than diligence: TypeScript adoption skews toward developers who deliberately chose it over JavaScript, and deliberate tooling choices correlate with the kind of engineer who is engaged enough with their craft to make them.

That is the pattern worth internalising. The signal is rarely the number. It is the number relative to the population the person actually belongs to. A developer with 60 contributions is unremarkable in TypeScript and well above median in Java. Comparing the raw figure across the two tells you nothing.

Popular is not the same as employable

The largest skill populations in the index:

1. JavaScript — 1,336,934 developers
2. HTML — 1,202,938
3. Python — 1,153,995
4. TypeScript — 749,904
5. Java — 743,885
6. CSS — 684,048
7. C++ — 510,023

Then the tail drops sharply. Rust has 127,090. Kotlin has 123,406. Swift has 105,978.

The gap between JavaScript and Rust is roughly ten to one, and it inverts the difficulty of hiring. There is no shortage of JavaScript developers in absolute terms, which means a JavaScript search returns more results than you can act on and your real problem is ranking. A Rust search returns a pool small enough to read end to end, and your real problem is response rate.

These are different jobs requiring different tactics, and treating them the same is one of the more common ways a sourcing effort stalls. For a large pool, invest in filters. For a small one, invest in the message.

Geography is more concentrated than the remote-work narrative suggests

Of developers with a resolvable location, the top ten countries:

The United States alone accounts for about 23% of located developers, and the top three countries together account for roughly 42%.

The more useful reading is further down. Colombia (19,878) sits ahead of France (17,865). Bangladesh (16,621) is close behind Japan (17,657). If you are hiring remotely and searching only the markets you already know, you are ignoring pools that are competitive on size and considerably less contested — most companies sourcing internationally are all fishing in the same four or five countries.

So what does correlate with being good?

Honestly: nothing in this dataset, taken alone. That is the finding, and it is worth stating plainly rather than dressing up.

What the data supports is narrower and more useful:

Recency beats volume. Someone with 40 contributions spread across the last twelve months is telling you something different from someone with 400 concentrated in a single month two years ago. The first is a working engineer. The second is a bootcamp graduate or a burst of open-source enthusiasm that ended.

Depth beats breadth. A developer with four languages and sustained activity in two is a more legible profile than one listing fourteen. The second pattern usually means tutorial repositories, which inflate every count without indicating anything.

Context beats the raw number, always. Every figure above is only interpretable against its population — language, country, and career stage.

And the things that most predict a good hire are not in this data at all. How someone reasons about a problem they have not seen before. How they handle disagreement. Whether they can explain a technical decision to someone who does not share their assumptions. No amount of public activity substitutes for a conversation, and any tool claiming otherwise — including ours — is overselling.

What the data is genuinely good for is the step before that conversation: narrowing two million people to twenty worth talking to, based on evidence you can inspect instead of a self-reported skill list.

How to use this when you are actually sourcing

1. Set thresholds per population, not globally. Look at the median for the specific skill and country you are searching, then filter relative to it.
2. Filter on recency first. Activity in the last twelve months eliminates more noise than any other single criterion.
3. Read the repositories, not the graph. Two minutes in someone's most substantial repository tells you more than any aggregate on this page.
4. Widen the geography before you lower the bar. If a search returns too few people, the constraint is usually the country list, not the requirements.

Every figure here is drawn from the same index you can search. The skill pages break the numbers down by technology, and the country pages do the same by location, both free to browse.