"Software developer" is a single line in the US government's occupational classification system, SOC code 15-1252. One title, one code, one set of job duties broad enough to cover a huge range of actual work. And within that single code, the wage data shows a spread wide enough to make the phrase "the market rate for a software developer" almost meaningless without immediately asking: which market.
This is a description of labor-market data, not personalized career or compensation advice — what any specific offer should pay depends on the specific role, company, and market, none of which this post can see.
The spread inside one occupation code
Start with the national numbers before geography even enters the picture. BLS's Occupational Employment and Wage Statistics program reports a national median annual wage for software developers of $133,080, with a mean of $144,570 — the mean sitting above the median, itself a sign that a smaller number of very high earners are pulling the average upward. The 10th percentile sits at $79,850. The 90th percentile sits at $211,450. That's a spread of more than $130,000 between the bottom and top deciles, inside one occupation code, describing people who are all, by the government's own classification, doing the same job. A lot of what makes software engineer salaries work in practice is process rather than code, which is the territory covers. A lot of what makes software engineer salaries work in practice is process rather than code, which is the territory the XenGrowth practice covers.
Percentile | Annual wage (BLS OEWS, software developers, national) |
|---|---|
10th | $79,850 |
25th | ~$104,000 |
50th (median) | $133,080 |
75th | $169,000 |
90th | $211,450 |
Some of that spread is experience and seniority mixed into one occupation code that doesn't distinguish a first-year developer from a twenty-year veteran. But experience alone doesn't explain why the same experience level, doing genuinely comparable work, can land at very different points on this scale depending purely on where the job is located — which is where geography actually enters.
What the metro-level data adds on top
BLS also breaks OEWS data out by metropolitan area, and the geographic spread compounds on top of the national spread rather than replacing it. The San Jose-Sunnyvale-Santa Clara, CA metro area has recorded the highest mean annual wage for software developers of any US metro in recent OEWS releases, at roughly $175,070 — well above the national mean of $144,570. That's not a small city-to-city difference; it's a mean wage roughly 20% above the national average for the same job title, in one direction, before you even get to smaller and lower-cost metros sitting well below the national mean in the other direction.
It's worth being precise about what this data can and can't tell you. It describes an aggregate mean or percentile across a metro's entire developer population, not a prediction for any individual role, company, or negotiation. What it does establish reliably is that the underlying labor markets are genuinely different from each other, not just differently priced versions of the same market. works through the operations side of this in more operational detail. The XenGrowth resource library works through the operations side of this in more operational detail.
Cost of living explains some of it, not all of it
The instinctive explanation is that expensive metros just pay more because everything costs more there, and that's true as far as it goes — nobody would expect the same nominal salary to represent the same standard of living in a metro with much higher housing costs. But cost-of-living adjustment alone doesn't fully close the gap in either direction, and it's worth being specific about why it's an incomplete explanation rather than a wrong one.
A nominal wage premium in an expensive metro shrinks once you convert it to real purchasing power, but real purchasing-power studies of high-cost tech hubs generally still find a residual premium left over after that adjustment — not the full nominal gap, but not zero either. That residual is where the more interesting explanations live.
Cost of living tells you why a dollar buys less in one city than another. It doesn't tell you why an employer in that city was willing to offer more dollars in the first place.
What actually drives the residual: thickness and concentration
Labor economists call a market "thick" when there are many buyers and many sellers of the same kind of labor transacting close together, and a thicker market tends to produce both higher wages and faster matching, because a worker has more competing options and an employer faces more competing bids for the same candidate. A metro with a genuinely dense concentration of software employers — not just a few large companies, but many, competing directly for the same talent pool — creates that thickness in a way a market with one or two dominant local employers does not, regardless of what either market's cost of living looks like. For the AI agents and marketing automation angle, see . For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
Industry concentration compounds this. A metro with a dense cluster of high-margin software and technology companies isn't just competing on volume of jobs — it's competing on the underlying economics of those specific businesses, and companies with higher revenue per employee generally have more room to pay above a given market's baseline for the same role. This is one honest reason wages in a market cluster around a specific, well-funded industry, rather than a broad average of "tech," tend to sit at the high end of the distribution independent of the cost of housing nearby.
Factor | What it explains | What it doesn't explain on its own |
|---|---|---|
Cost of living | Why a given nominal salary buys a different standard of living across metros | Why the nominal salary was set at that level in the first place |
Labor market thickness | Why a market with many competing employers and workers tends to bid wages up | Absolute wage levels in markets with similarly thick labor pools but different industries |
Industry concentration | Why a metro dominated by high-margin software firms clusters at the high end of pay | Wage variance within that same metro across different-sized or different-stage employers |
Experience mix | Part of the spread within the national percentile range itself | Why the same experience level pays differently by metro |
A fast-growing occupation changes the local bargaining position
There's a demand-side factor worth separating from the metro-level story above: how fast the occupation itself is growing overall, since that shapes how much bargaining leverage workers have almost everywhere, not just in the highest-paying hubs. BLS's Employment Projections program puts software developer employment at roughly 1,693,800 in 2024, projected to grow to about 1,961,400 by 2034 — an increase of roughly 16% over the decade, well above BLS's average projected growth rate across all occupations combined. A fast-growing occupation nationally doesn't distribute that growth evenly across every metro, but it does mean employers generally cannot rely on a large reserve of idle qualified candidates locally, which keeps competitive pressure on wages even in markets well outside the handful of highest-paying hubs.
This is also a reasonable partial explanation for why the spread between the 10th and 90th percentile nationally has stayed as wide as it has, rather than compressing over time as the occupation has grown. If growth were concentrated in low-wage segments of the field, the whole distribution would compress toward the bottom; if it's concentrated in the higher-paying, higher-skill segments instead, the top of the distribution keeps pulling further away from the bottom even as total employment grows. The BLS data alone doesn't settle which of those is happening — it just establishes that the occupation is growing quickly enough that the underlying dynamics are worth taking seriously rather than assuming the current spread is a stable, permanent feature of the field. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
Remote work has scrambled the geography, not erased it
Remote work changes this whole picture, but not in one clean direction. On one side, it lets a subset of engineers effectively access a higher-paying labor market's wages while living somewhere with a lower cost of living — a real form of arbitrage that compresses the gap for the specific people able to do it. On the other side, a number of employers responded to widespread remote hiring not by paying a single national rate, but by adopting explicit location-based pay bands, deliberately preserving some version of the geographic differential rather than letting remote work flatten it.
The net effect is genuinely mixed rather than a clean story in either direction, and it varies enormously by company policy. What it has clearly done is decouple, for at least some workers, the previously tight link between where you live and which labor market's wage curve you're actually competing inside — which is a meaningfully different situation from the one the BLS data above describes on its own, since that data is still organized by where the job (and often the worker) is physically located.
Compare salary numbers against the specific metro's data, not just a national median — the spread between metros can rival the spread across an entire career's worth of seniority
Treat a cost-of-living-adjusted number as a starting point, not a final answer — real purchasing-power premiums in dense tech hubs tend to persist even after adjustment
Ask what a given employer's pay-band policy actually is for remote roles — location-based bands and flat national rates produce very different outcomes for the same job
Consider industry concentration, not just city, when comparing markets — two metros with similar costs of living can have very different local wage ceilings depending on what industries actually cluster there
Remember that BLS percentile and mean data describe an aggregate population, not a specific negotiation — useful for context, not a substitute for market research on your specific role
None of this is personalized compensation advice, and it isn't a claim about what you specifically should be paid — that depends on your role, your employer, your market, and factors this post has no visibility into. It's a description of why the same job title produces such a wide range of real numbers, and the honest answer is that geography was never really about the map. It's about how many employers are actually competing for you where you are, or where your employer has decided to price you as if you are. is worth a look if you're interested in how the commercial side of a given market's industry concentration actually operates day to day.
Further reading from XenGrowth
Where this work meets go-to-market
Studying labor markets or compensation strategy from inside a commercial team? cover the revenue side of the industries this post argues actually set the local wage ceiling.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of software engineer salaries, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of software engineer salaries, see XenGrowth's growth operations team.
Five questions on the actual BLS numbers behind geographic salary spread. This describes labor-market data in general, not a prediction of what any specific offer should pay.
