The software salary debate usually turns into two groups yelling past each other. One side sees a junior developer making $90k or $100k and says tech is overpaid, while the other side sees a staff engineer keeping a giant system alive and says developers are underpaid compared to the money they help companies make. Both sides can be right depending on what kind of developer they are talking about, but the conversation usually falls apart because people use one job title to describe a bunch of completely different jobs.
A junior dev building admin screens, a mid-level dev fixing production bugs, a staff engineer designing systems across teams, and an AI engineer working near model infrastructure are all technically “developers,” but they are not living in the same labor market. Some of that work is closer to skilled trade work with a keyboard, some of it is business automation work, some of it is infrastructure work, and some of it is high-scale technical decision-making where one bad call can cost a company a lot of money.
I also do not like when developers act like software is the only hard work that exists. I have been a roofer, I was a medic in the Army, I worked private security, and I have done warehouse-style work loading roofing materials onto job sites, so it is hard for me to listen to someone act like fixing a React bug is automatically harder than climbing a roof, treating people under pressure, standing a post all night, or throwing heavy material around in bad weather for less than $20 an hour.
At the same time, I do not like fake arguments that pretend software work is easy just because it is not physically brutal. A job can be easier on the body and still be valuable to a company, because the company is not paying based on how much your back hurts. The company is paying based on leverage, replacement cost, scalability, risk, and how close the work sits to money.
That is the uncomfortable part. A junior developer can do work that looks simple, like fixing a form or wiring an API call, and still get paid more than someone doing harder physical work. That does not mean the junior developer is tougher or more useful to society. It means software sits inside a business model where one small piece of work can be reused, deployed, copied, and sold again and again.
Table Of Contents
- The Real Question
- Why I’m Comparing These Jobs At All
- The Pay Numbers That Start The Argument
- Salary Comparison Graphic
- Why A Junior Dev Can Make More Than People Doing Harder Work
- Roofing Compared To Software Development
- Army Medic Work Compared To Software Development
- Private Security Compared To Software Development
- Warehouse And Manual Labor Compared To Software Development
- Teaching Compared To Software Development
- Do Most Developers Even Do DSA?
- Is Web Development Skilled Trade Work With A Keyboard?
- Are Junior Developers Overpaid?
- Are Mid-Level Developers Fairly Paid?
- Are Staff Engineers Overpaid?
- Where AI Changes The Pay Conversation
- The Three Different Developer Economies
- The Honest Answer
- Sources
The Real Question
The real question is not “are developers overpaid?” because that question is too broad to be useful. A better question is, “overpaid compared to what, for what type of work, at what company, and under what business model?” Without those details, the argument turns into people comparing a junior web developer at a small company to a staff engineer at Google like those are the same thing.
If we compare developers to the national median worker, developers are paid a lot. If we compare developers to roofers, EMTs, paramedics, security guards, warehouse workers, construction laborers, or teachers, software pay can look insane, especially when the software job is remote and the other job is physically dangerous, emotionally heavy, or socially necessary.
If we compare developers to the money their work can generate, the answer changes. A developer working on a SaaS product, payment system, cloud platform, AI tool, ad system, internal dashboard, or automation flow can touch systems that scale to thousands, millions, or even billions of interactions. That kind of scale is why the salary conversation gets weird fast.
That is the part people miss when they only compare effort. The labor market does not pay only based on pain, danger, stress, intelligence, or how noble the job is. It mostly pays based on leverage, scarcity, replacement cost, company margins, and how close the work is to revenue.
This is why the argument feels morally wrong but economically explainable. A medic can do more socially important work than a junior web developer and still make less, because medical labor is often trapped inside public budgets, insurance structures, military pay tables, local contracts, or staffing models. Software work, especially inside product companies, can sit closer to high-margin revenue.
That does not mean the market is fair. It means the market is not built around fairness. It is built around money, risk, supply, demand, and who has the power to negotiate.
Why I’m Comparing These Jobs At All
I am not comparing software to roofing, Army medic work, private security, warehouse-style labor, and case management because I think they are all the same job. I am comparing them because I have lived enough of those worlds to know that “hard work” and “high pay” are not the same thing, and pretending they are is one of the reasons the developer pay debate gets so fake.
My own work history did not start in tech. I served as a Healthcare Specialist in the Army from 2011 to 2014, including training environments and combat-zone medical support, where the work involved triage, emergency response, medical readiness, supplies, physical exams, medication administration, and staying calm when things were unpredictable. After that, I worked roofing and roofing supply roles from 2017 to 2020, including general contracting, tear-off, shingle work, site prep, cleanup, and roof loading heavy materials onto job sites in bad weather and under tight schedules. I also worked private security, and later worked in case management with Veterans Court, Drug Court, and Mental Health Court, where documentation, communication, crisis intervention, and keeping people on track mattered every day.
I also worked at Mason County Kitten Rescue from 2020 to 2022, which was not high-paying tech work, but it taught organization, intake, care routines, training volunteers, watching for signs of distress, and doing important daily work that does not become more profitable just because it matters. Then I started moving seriously into software, contributing as a Junior Frontend Developer with CIRIS Ethical AI in 2024 by running the project locally, improving onboarding and setup documentation, adding small code changes, improving token-verification logging, fixing lint issues, improving error messages, and opening GitHub Issues to keep larger ideas tracked. In 2025, I completed an on-site AWS Cloud Support Engineer internship in Seattle, where the work included guided support rotations in training environments with no customer data, guided Juniper and Junos troubleshooting labs in Jupyter Notebooks, and a capstone serverless metadata extraction workflow using Lambda, DynamoDB, S3, and an accessible frontend deployed on AWS Amplify.
The reason that timeline matters is because none of the earlier physical or service-heavy jobs paid me over $20 an hour at the time, but they still demanded discipline, pressure management, communication, safety, documentation, and the ability to keep moving when things were not comfortable. Then tech came along and suddenly the pay ceiling was completely different, not because the work became morally superior, but because the business model changed. Software is not automatically harder than those jobs, but it can be attached to systems where the output scales in a way those jobs usually cannot.
The Pay Numbers That Start The Argument
The U.S. Bureau of Labor Statistics listed the median annual wage for software developers at $133,080 in May 2024. The same BLS page says the lowest 10 percent earned less than $79,850, while the highest 10 percent earned more than $211,450.
That number is already high compared to normal American wages. BLS listed the median annual wage for all workers at $49,500 in May 2024, which means the median software developer made about 2.7 times the median worker.
The comparison gets uncomfortable when software is placed next to jobs that are clearly hard, risky, or socially important. BLS listed roofers at $50,970, EMTs at $41,340, paramedics at $58,410, security guards at $38,370, construction laborers and helpers at $46,050, hand laborers and material movers at $37,680, and high school teachers at $64,580.
Those numbers explain why people outside tech get annoyed when developers complain about pay. A junior developer can make more than a roofer, medic, security guard, teacher, construction laborer, or warehouse worker before that junior developer is even fully useful to the team.
Levels.fyi shows even larger numbers because it tracks total compensation, not just base salary. In May 2026, Levels.fyi listed U.S. software engineer median total compensation around $191,000, with the 25th percentile around $135,000, the 75th percentile around $276,100, and the 90th percentile around $380,000.
BuiltIn shows a lower junior number than Levels.fyi, which makes sense because BuiltIn pulls from a broader mix of companies. BuiltIn lists U.S. junior software engineer average base salary around $89,847, average additional cash compensation around $10,590, and average total compensation around $100,437.
| Role Or Group | Recent Pay Data | Why It Matters |
|---|---|---|
| All U.S. workers | $49,500 median wage | This is the broad baseline for the whole labor market. |
| Roofers | $50,970 median wage | This is skilled, physical, dangerous work, but the pay is close to the national median. |
| EMTs | $41,340 median wage | This is life-safety work, but the labor market pays it far below software. |
| Paramedics | $58,410 median wage | This pays more than EMT work, but still far below the median developer. |
| Security guards | $38,370 median wage | This is common risk-bearing work, but it pays far below software. |
| Construction laborers and helpers | $46,050 median wage | This is hard physical work that often pays less than many junior tech jobs. |
| Hand laborers and material movers | $37,680 median wage | This covers a lot of warehouse-style physical labor and shows how low that work often pays. |
| High school teachers | $64,580 median wage | This requires education, responsibility, and social value, but it is still below junior software pay in many cases. |
| Software developers | $133,080 median wage | This is where the comparison starts looking unfair to people outside tech. |
| U.S. software engineers on Levels.fyi | $191,000 median total comp | This includes bonus and equity, so it shows the higher end of tech more clearly. |
| Junior software engineers on BuiltIn | $100,437 average total comp | This is one reason people ask whether junior developers are overpaid. |
The table is not saying developers have easy lives or that every developer is rich. It is showing why the discussion gets tense, because the pay gap is real and the explanation is not as simple as “developers are smarter” or “developers work harder.”
The market is not judging pay by soreness, danger, or public good. It is judging pay by how much money the company has, how scalable the output is, how hard the role is to fill, and how expensive it is when the work is done badly.
Salary Comparison Graphic
Why A Junior Dev Can Make More Than People Doing Harder Work
This is the question people are really asking. Why is a junior developer who barely knows the codebase getting paid more than somebody climbing roofs, treating casualties, standing security posts, moving freight, or managing a classroom?
The answer is not that junior devs are tougher than roofers, medics, teachers, or security guards. A junior dev sitting at a desk with a laptop is not taking the same physical beating as a roofer, and they are not carrying the same kind of immediate life-and-death pressure as a medic.
The answer is also not that every junior developer is doing genius-level computer science all day. Most junior developers are not writing compilers, designing databases, or inventing new algorithms. Most are fixing bugs, building components, writing API calls, updating forms, handling validation, reading existing code, asking questions, and trying not to break the build.
The reason junior developers can still get paid more is leverage. A junior dev working on the right product can ship a small feature that thousands of customers touch, while a roofer can only roof the house, building, or section physically in front of them.
That does not make the roofer less skilled, and it does not make the medic less important. It means software output can be copied, deployed, reused, sold, and scaled in a way physical labor usually cannot.
A roofer finishes a roof and that roof exists in one place. A developer finishes a login flow, billing screen, internal automation, or API endpoint, and that work might run all day for every user the company has.
A medic treats the patient in front of them, and that work matters in a direct human way. A developer builds a system that might remove manual steps for a whole department, process thousands of payments, or prevent support tickets before they exist.
A security guard protects a site, handles access, watches patterns, and responds to incidents in one location. A developer who builds access controls, audit logs, or monitoring systems might affect every user and every employee at the company.
That is why software salaries feel disconnected from effort. The pay is not really for typing code. The pay is for building and maintaining systems that can scale past one person’s physical output.
Roofing Compared To Software Development
Roofing is one of the easiest jobs for people to underestimate because the final product looks simple. A roof keeps water out, but anyone who has actually done the work knows that a roof is only simple when you ignore everything that makes it fail.
When I think about roofing, there are about 10 things you have to actually learn before you are useful and safe. You need to understand tear-off, decking, underlayment, flashing, shingles, fasteners, ventilation, valleys, measurements, and job-site safety.
Tear-off is not just ripping old material off the roof. It is removing layers without destroying the deck, managing debris, watching for rot, keeping the site clean enough to work, and not creating a bigger problem before the new material even goes on.
Decking matters because the roof is only as good as what it is attached to. In software, this is like discovering the data model, old architecture, or legacy service is rotten underneath the feature request.
Underlayment, ice barrier, and water protection are the hidden layers most homeowners never think about. In software, those are like validation, auth checks, error handling, logging, and safe defaults, because nobody praises them when they work but everybody notices when they fail.
Flashing is where a lot of bad roofs lose. In software, the equivalent is integrations, permission boundaries, third-party APIs, weird browser behavior, and all the places where one clean system meets another messy system.
Shingles look easy from the ground, but alignment, overlap, nailing pattern, starter strips, and sequence all matter. In software, that is the repeatable pattern work, because a component, endpoint, or service should fit the system instead of being random every time.
Fasteners matter because using the wrong nail, wrong placement, or wrong pressure creates future failure. In code, that is like using the wrong dependency, weak typing, fragile state management, a bad query, or a shortcut that only works until the system changes.
Ventilation is one of those things that makes a roof fail slowly. In software, performance, caching, queues, background jobs, and infrastructure limits are the same kind of hidden system health work.
Valleys, edges, vents, chimneys, and walls are where the easy middle stops being easy. In software, the happy path is usually simple, but the edge cases, weird inputs, expired sessions, duplicate requests, broken permissions, and production-only bugs are where the real work shows up.
Measurement and material planning matter because waste costs money and bad estimates kill jobs. In software, bad estimates create missed deadlines, half-built features, rushed testing, and pressure that usually lands on the people doing the work.
Safety matters because roofing can hurt or kill you fast. Software usually will not do that to your body, but it can hurt customers, leak data, break billing, stop operations, or create business damage if the system is important enough.
| Roofing Work | Software Equivalent | Why The Comparison Makes Sense |
|---|---|---|
| Tear off the old roof without damaging the deck | Refactor old code without breaking production | Both jobs start by removing bad or outdated layers carefully. |
| Inspect problem areas before quoting the job | Read requirements, logs, errors, and existing code before coding | Both jobs punish people who start swinging before understanding the problem. |
| Measure the roof and calculate material | Scope the feature, data model, and implementation work | Both jobs need estimating, waste control, and planning before execution. |
| Replace rotten plywood or damaged joists | Fix bad architecture, bad data, or broken dependencies | Both jobs reveal hidden problems once the surface layer comes off. |
| Install underlayment and water protection | Add validation, auth, error handling, and security checks | Both jobs need invisible protection that the customer may never notice until it fails. |
| Flash chimneys, walls, valleys, and vents | Handle edge cases around integrations, permissions, and weird states | Both jobs usually fail at the edges, not in the big flat middle. |
| Lay shingles with proper overlap and alignment | Build UI and API flows with consistent patterns | Both jobs need repeatable patterns, not random improvisation every few feet. |
| Cut materials around vents, walls, and valleys | Adapt code around browser quirks, API limits, and product exceptions | Both jobs require custom fitting while still following a system. |
| Install ventilation correctly | Design performance, caching, and operational flow | Both jobs can look fine at first and fail later if system flow is wrong. |
| Work safely on ladders, slopes, heat, wind, and job sites | Work safely around production data, secrets, deployments, and user impact | Both jobs have risk, but the kind of risk is different. |
This is why I do not buy the argument that software work is always intellectually superior to trade work. A lot of software development is applied craft, pattern recognition, troubleshooting, repetition, and learning how to avoid known failures.
The difference is that software companies can sell the same work again and again. A roofing company cannot install the same roof on 100,000 houses with one deployment.
Army Medic Work Compared To Software Development
Medic work is another comparison that makes software pay feel strange. As a medic, especially in the Army, the job is not just knowing medical facts. It is applying training under stress, around chain of command, with imperfect information, limited time, and real consequences.
The Army describes the 68W Combat Medic Specialist role as assessing injuries, stabilizing patients, making critical medical decisions under extreme conditions, training other soldiers in first aid, and providing emergency medical treatment. That is a lot of responsibility for a role that often does not pay anywhere near what a developer makes.
Civilian pay shows the gap clearly too. BLS lists EMTs at a median annual wage of $41,340 and paramedics at $58,410, which means a junior software developer can easily make more than someone doing emergency medicine work.
This is not because the junior developer has more immediate responsibility than a medic. A junior dev might break a page or slow down a sprint, while a medic can be involved in decisions where minutes matter.
The software comparison is not about physical danger or emotional pressure. It is about decision-making inside a system, because medics and developers both work with incomplete information and need to decide what matters first.
A medic has to assess the patient, control bleeding, protect the airway, manage shock, communicate with the team, prepare evacuation, document care, and keep working under pressure. A developer has to assess the bug, isolate the failure, protect production, communicate with the team, prepare a fix, document the change, and keep working under pressure.
Those are not equal jobs. The human stakes are not the same. But the pattern is similar because both involve triage, prioritization, systems thinking, and knowing when the wrong action is worse than taking a moment to understand the problem.
| Medic Work | Software Equivalent | Why The Comparison Makes Sense |
|---|---|---|
| Triage multiple problems under pressure | Prioritize incidents, bugs, and outages | Both jobs require deciding what matters first. |
| Stop bleeding before treating smaller injuries | Fix the production-breaking issue before cosmetic bugs | Both jobs need damage control before polish. |
| Maintain airway, breathing, and circulation | Protect uptime, data flow, and core system health | Both jobs depend on keeping the main system alive. |
| Work with limited information | Debug with incomplete logs or unclear reports | Both jobs rarely start with perfect information. |
| Communicate with chain of command or evacuation teams | Communicate with managers, product, support, and engineers | Both jobs fail when communication fails. |
| Track treatment and patient status | Document incident notes, fixes, and follow-up work | Both jobs need records so the next person is not blind. |
| Train others in basic first aid | Mentor juniors and write operational docs | Both jobs scale knowledge through training. |
| Stay calm when people panic | Stay calm during production issues | Both jobs punish panic and reward process. |
This is why I do not like when developers exaggerate how hard coding is compared to everything else. Medic work can be more stressful, more direct, more personal, and more consequential in the moment.
The reason software pays more is not because society values medics correctly. Software pays more because companies can turn working software into repeatable revenue, while emergency medical work is often limited by public budgets, contracts, insurance systems, military pay structures, and staffing models that do not reward the worker based on the actual human value of the work.
Private Security Compared To Software Development
Private security is another job people underestimate because they picture someone just standing around. Sometimes that is what it looks like from the outside, but the actual job is staying alert when nothing is happening, noticing when something changes, handling people without escalating the situation, and being the first person blamed when something goes wrong.
BLS lists security guards at a median annual wage of $38,370 in May 2024. That is about $18.45/hour, and it is still far below what many junior developers make.
When I worked private security, the job was not technically complex the same way software is complex, but it required discipline, awareness, patience, and judgment. You had to watch access points, control entry, write incident reports, handle tense people, stay awake, stay professional, and understand when to call for help.
Software has a security version of that same thinking. A lot of development work is boring monitoring, access control, logging, reviewing permissions, checking systems, and making sure the wrong person does not get into the wrong place.
The pay difference is not because the private security worker has no value. The pay difference is because private security is often treated as a cost center, while software is often treated as a product engine or revenue multiplier.
| Private Security Work | Software Equivalent | Why The Comparison Makes Sense |
|---|---|---|
| Control access to a site | Build authentication and authorization | Both jobs decide who gets in and what they can touch. |
| Watch cameras, doors, lots, and patterns | Monitor logs, dashboards, errors, and metrics | Both jobs require noticing abnormal behavior. |
| Write incident reports | Write bug reports, incident notes, and postmortems | Both jobs need clear records after something happens. |
| De-escalate tense people | Handle support escalations and production pressure calmly | Both jobs need communication under stress. |
| Follow post orders | Follow runbooks, deployment process, and security policy | Both jobs depend on process because memory is not enough. |
| Patrol and inspect areas | Review systems, endpoints, configs, and permissions | Both jobs look for problems before they become incidents. |
| Respond when something changes | Respond to alerts, outages, and suspicious activity | Both jobs can be quiet for hours and then serious fast. |
The unfair part is that security workers are paid like replaceable labor even though bad security can cost a company a lot. Software developers are paid better because their work is closer to scalable revenue and because companies believe replacing a developer is harder than replacing a guard.
That does not mean the market is morally correct. It means the market rewards leverage more than responsibility.
Warehouse And Manual Labor Compared To Software Development
Warehouse work is another comparison that matters because a lot of people in tech have never had to do repetitive physical work for a paycheck. BLS lists hand laborers and material movers at a median annual wage of $37,680, which shows how low that work often pays compared to software.
Warehouse work can look simple if you only describe it as “moving boxes.” Software can also look simple if you only describe it as “typing code,” which is why bad descriptions are useless.
Warehouse work requires speed, accuracy, memory, scanning, staging, loading, safety, endurance, and not making mistakes that slow down everyone behind you. A bad pick, bad label, bad count, bad pallet, or bad load can create real downstream problems.
Software has the same kind of flow problem, just in a different form. A bad data migration, wrong config, bad deploy, missed environment variable, or broken API contract can hold up the whole team or create customer issues.
| Warehouse Work | Software Equivalent | Why The Comparison Makes Sense |
|---|---|---|
| Pick the right item | Pull the right data or dependency | Both jobs fail when the wrong thing moves through the system. |
| Label and scan correctly | Name, type, and log data correctly | Both jobs need traceability. |
| Stage items in the right place | Prepare code, branches, builds, and environments correctly | Both jobs depend on sequence and organization. |
| Load without damaging product | Deploy without damaging production | Both jobs involve moving work safely from one state to another. |
| Keep pace without losing accuracy | Ship quickly without breaking quality | Both jobs punish sloppy speed. |
| Follow safety and workflow rules | Follow code review, testing, and deployment rules | Both jobs use process to reduce mistakes. |
The difference is not that software is always harder. The difference is that software work can automate the warehouse workflow itself, reduce headcount, improve routing, change inventory systems, or improve company-wide efficiency.
That is why a developer who has never done warehouse work might make more than the warehouse worker. It is not because the developer is automatically tougher, it is because the developer may be building the system that changes how 500 warehouse workers operate.
Teaching Compared To Software Development
Teaching is one of the clearest examples of how pay does not equal social value. BLS lists high school teachers at a median annual wage of $64,580, which is above the national median but still far below software developer pay and below many junior tech offers.
A good teacher has to understand the subject, manage a room, communicate clearly, adjust to different students, track progress, deal with parents and administrators, follow standards, grade work, and keep showing up even when the system is not built to make the job easy.
That sounds a lot like developer mentorship in some ways. A senior developer who cannot explain anything clearly is less useful than a senior developer who can teach patterns, review code well, write docs, and help juniors become productive.
The difference is that teaching usually sits inside public budgets, district funding, local taxes, political fights, and credential systems. Software sits inside companies that can sell products repeatedly and use technical work to increase margins.
| Teaching Work | Software Equivalent | Why The Comparison Makes Sense |
|---|---|---|
| Break down hard concepts | Explain systems, code, and architecture | Both jobs require turning complexity into something another person can use. |
| Manage different skill levels | Mentor juniors and collaborate across teams | Both jobs involve uneven experience levels. |
| Grade and give feedback | Review code and give actionable comments | Both jobs need feedback that improves the person, not just the output. |
| Follow curriculum and standards | Follow product requirements, security standards, and engineering process | Both jobs work inside constraints. |
| Track progress over time | Track technical debt, sprint work, and developer growth | Both jobs require long-term attention. |
| Handle classroom pressure | Handle meetings, incidents, and team pressure | Both jobs require communication when things get messy. |
This is why the “developers are paid because they are smarter” argument falls apart. Teachers need skill, judgment, patience, communication, and subject knowledge, but their labor does not scale the same way software does.
A teacher teaches the students in front of them. A developer builds a feature once and the company can put it in front of every customer.
Do Most Developers Even Do DSA?
Most developers do not spend their normal workday implementing red-black trees, writing graph algorithms from scratch, or solving LeetCode-style dynamic programming problems. Most business software work is much more ordinary than the interview process makes it look.
That does not mean data structures and algorithms are useless. It means there is a difference between the theory that helps you think and the daily work most developers are paid to do.
Most web developers spend more time reading existing code, changing components, writing endpoints, shaping data, handling errors, fixing tests, wiring third-party services, working with databases, and pushing changes through a deployment process. That work still uses data structures, but usually in the form of arrays, objects, maps, JSON, query results, collections, queues, and state.
A roofer does not calculate structural engineering formulas all day either. That does not mean roofing has no skill. It means the job is mostly applied field knowledge, judgment, tool use, sequence, safety, and knowing what failure looks like before it happens.
A medic does not write a medical textbook during every patient interaction either. They apply training, assess the current situation, follow protocol, make decisions, communicate, and act before the situation gets worse.
A security guard is not doing legal theory all night either. They follow post orders, watch patterns, control access, de-escalate, document, and call the right people when something crosses the line.
Software is similar for most developers. The job is less “solve a puzzle from scratch” and more “change a living system without making it worse.”
The reason DSA still matters is that some jobs really do need it. Search, ranking, distributed systems, graphics, compilers, databases, high-frequency trading, AI infrastructure, embedded systems, and large-scale platform work can absolutely require deeper computer science.
The problem is that the hiring process often treats every web developer like they are applying to build a search engine. That creates a fake picture of the job, because plenty of developers make solid money doing CRUD, integrations, infrastructure, UI, testing, debugging, and maintenance.
This is part of why salary conversations get weird. A person outside tech hears that developers make six figures and assumes they must be doing advanced math all day. A person inside tech knows plenty of developers are mostly moving data from one place to another, validating it, displaying it, storing it, and making sure it does not break.
That work still matters, but it is not always the mythical version of software engineering people imagine. Most companies pay for working systems, not for how many algorithm problems someone can solve on a whiteboard.
Is Web Development Skilled Trade Work With A Keyboard?
A lot of normal software work is closer to skilled trade work than developers want to admit. Most business developers are not doing advanced algorithm research, because they are building, fixing, connecting, deploying, documenting, and maintaining systems.
That does not make the job fake or easy. Roofing is also “just putting materials on a roof” if someone wants to describe it badly, but anyone who has done it knows that a bad roof can look fine for a little while before the leak exposes every shortcut.
Software is the same way. Bad code can look fine in the demo, pass the happy path, and still fail when users hit weird inputs, network errors, bad permissions, slow queries, expired sessions, broken environment variables, or real production load.
This is where the trade comparison gets useful. A lot of web development is not elite math, but it is still skilled production work where experience matters because the edge cases are what punish you.
The same pattern shows up across roofing, medic work, security, warehouse work, teaching, and software. The public sees the visible output, but the worker knows the job is mostly about preventing the failure that nobody notices if you did it right.
In roofing, a customer might only see shingles. In software, a product manager might only see a button. The worker sees the layers under it, the ways it can fail, the shortcuts that were taken before, and the cleanup nobody budgeted time for.
That is why I think “easy job” is the wrong phrase. Some development work is physically easy, and some tickets are technically simple, but the job becomes valuable because the work lives inside a larger system with users, data, revenue, and future maintenance attached to it.
Are Junior Developers Overpaid?
Compared to roofers, EMTs, teachers, security guards, warehouse workers, construction laborers, and the national median worker, junior developers are usually overpaid in the plain social comparison sense. A junior developer making $90k to $120k while still learning the job is making more than many people who carry more physical risk, more public responsibility, or more immediate consequences.
Compared to the business model they work inside, juniors are not always overpaid. A junior who can ship small production improvements, automate annoying internal work, fix customer-facing bugs, improve documentation, and grow into a mid-level developer is not just being paid for today’s output.
The company is paying for the pipeline. Hiring a junior is partly a bet that the person will become useful enough to retain, promote, or use as a cheaper alternative to hiring only seniors.
This is also why junior hiring gets ugly when the market tightens. If companies stop wanting to invest in training, juniors suddenly look expensive because they need mentorship before they become reliably productive.
That is where the “easy job” complaint has some truth but not the whole truth. A lot of junior tickets are easy compared to roofing, medic work, or private security, but the junior is still learning how to work inside a system where small changes can create bigger problems.
So yes, juniors can be overpaid if the company expects them to be productive immediately and they are mostly being carried. But juniors can be underpaid if they are doing real production work, learning fast, getting little support, and still being treated like replaceable cheap labor.
The more honest answer is that junior pay is not about whether the current ticket is easy. It is about whether the company believes the person can become valuable before the cost of training them becomes a loss.
Are Mid-Level Developers Fairly Paid?
Mid-level developers are probably the closest thing to fairly paid in normal software work. They usually know enough to ship, debug, communicate, review code, understand production basics, and ask for help before they create a disaster.
They are not usually responsible for company-wide technical direction. They also are not usually helpless, which makes them valuable without making them as expensive as staff or principal engineers.
This level is where software starts looking most like skilled trade work. A solid mid-level developer knows the tools, knows the common failure points, knows how to estimate better than a junior, and knows when a “small change” is not actually small.
A solid roofer with a few years in the field is the same kind of person. They may not own the company or design the whole job, but they can look at a roof, understand the next steps, avoid obvious mistakes, and keep the job moving.
A solid medic is also that kind of person. They may not be the doctor, but they know how to assess the situation, act within scope, document, communicate, and keep the patient moving through the system.
A reliable security worker fits the same pattern too. They may not be writing policy, but they know the post, notice what is off, document what happened, and understand when a situation needs to move up the chain.
That is why mid-level dev compensation makes the most sense to me. They are expensive, but they are usually expensive in the same way any reliable skilled worker is expensive, with the added difference that software output can scale.
Are Staff Engineers Overpaid?
Staff engineers are where the conversation becomes almost impossible because the numbers get absurd. A Google L6 staff engineer around $580k, a Meta E6 staff engineer around $775k, and Netflix senior staff compensation near or above $1M sounds fake if you compare it to normal jobs.
But staff engineers at companies like that are not being paid to close Jira tickets. They are paid to reduce risk, set technical direction, unblock teams, review architecture, avoid expensive mistakes, and make decisions that affect systems with huge numbers of users.
That is why revenue per employee matters. NVIDIA reportedly generated around $4.4 million in revenue per employee, and Netflix was reported around $4.15 million per employee, which changes how a $700k engineer looks on a spreadsheet.
That does not mean every staff engineer deserves $700k. Some people have inflated titles, some companies hand out titles loosely, and some senior people become expensive bottlenecks instead of force multipliers.
But a real staff engineer at scale is not just a better coder. They are closer to a technical foreman, architect, incident preventer, reviewer, teacher, and risk manager combined.
That kind of work can be underpaid if it prevents huge losses. It can also be overpaid if the person mostly attends meetings, writes vague docs, and creates no real technical leverage.
The title alone does not answer the question. The value depends on the actual scope, the systems involved, and whether the person makes many other engineers and systems better.
This is the part that normal salary comparisons miss. A staff engineer at a small company and a staff engineer at a global platform can have the same title, but one might be improving internal tooling for 80 employees while the other is making architecture decisions that affect millions of users.
That is why staff pay looks fake from the outside. Sometimes it is inflated, sometimes it is justified, and sometimes it is still cheaper than the damage the wrong technical decision would cause.
Where AI Changes The Pay Conversation
AI makes this debate even harder because it lowers the floor and raises the ceiling at the same time. A junior with AI tools can ship more than a junior could a few years ago, but a weak junior can also create a bigger mess faster than before.
The boring tasks are becoming cheaper. Boilerplate, simple components, basic scripts, basic CRUD, documentation drafts, test scaffolds, and quick debugging help are all easier with tools like ChatGPT, Claude, Cursor, and Copilot.
That means companies may eventually pay less for people who only know how to produce basic code. The value is moving toward people who can understand the system, verify AI output, debug bad suggestions, protect production, think through risk, and connect technical work to business goals.
This is where staff engineers and strong mid-level developers may become even more valuable. If a company has ten juniors using AI and nobody experienced reviewing the architecture, the company did not get faster, it just created problems at higher speed.
AI does not remove the need for judgment. It makes judgment more important because the cost of producing code went down, but the cost of understanding whether that code is correct did not disappear.
This is also why junior dev pay is going to be a rough topic for a while. If a junior can use AI to ship useful work and they can explain what they are doing, their value goes up. If they use AI to produce code they cannot understand, their risk goes up.
The same thing happened in other work when tools improved. Better nail guns did not remove the need for someone who understands roofing. Better medical equipment did not remove the need for someone who can assess the patient. Better cameras did not remove the need for security judgment.
Better coding tools will not remove the need for developers who understand systems. They will probably remove some tolerance for people who only copy output and hope it works.
The Three Different Developer Economies
The software industry is not one labor market anymore. It is at least three different economies pretending to be one because all the job titles use the word developer or engineer.
The first economy is normal software work. These are the developers at small companies, local businesses, agencies, internal IT teams, healthcare companies, manufacturing companies, insurance companies, and non-tech companies where software supports the business instead of being the whole business.
The second economy is high-scale tech. These are developers at Big Tech, AI labs, high-frequency trading firms, cloud infrastructure companies, fintech platforms, and product companies where one technical decision can affect millions of users or billions of dollars in market value.
The third economy is underpaid software work. These are developers maintaining legacy systems, handling frontend, backend, support, infrastructure, deployments, and documentation while making $60k, $80k, or maybe $100k with little mentorship and no real path upward.
This is why the argument goes nowhere. Someone talking about a junior web developer at a small local company and someone talking about an L6 engineer at Google are not talking about the same job.
Both people can be telling the truth. They are just describing different worlds.
| Developer Economy | Typical Work | Typical Pay Reality |
|---|---|---|
| Normal software work | CRUD, internal tools, websites, APIs, integrations, support, maintenance | Often $70k to $180k depending on region and company. |
| High-scale tech | Infrastructure, platforms, AI, distributed systems, revenue-critical products | Can reach $300k to $1M+ because the leverage is massive. |
| Underpaid software work | Legacy maintenance, too many hats, little support, low-budget companies | Can pay closer to $50k to $100k while still demanding broad responsibility. |
This split explains why developers argue past each other. One person is talking about people making $500k and another person is talking about someone doing full-stack work for $70k at a non-tech company.
The title alone does not tell you enough. You need to know the company, the market, the revenue model, the level, the scope, the risk, and whether the person is actually creating leverage or just carrying a fancy title.
The Honest Answer
Developers are overpaid if the comparison is physical danger, social value, or visible effort. A junior developer working from home can make more than a roofer, medic, teacher, security guard, warehouse worker, or construction laborer, and I do not think developers should pretend that feels normal.
Developers are not always overpaid if the comparison is business leverage. A developer who ships a feature used by thousands of customers, prevents outages, improves performance, secures customer data, or automates expensive work can easily create more value than their salary.
Most normal developers are not doing elite computer science all day. They are doing applied software trade work, which means building, fixing, connecting, testing, deploying, documenting, and maintaining systems that break in weird ways.
That work is not magic. It is not always harder than roofing, medic work, construction, warehouse work, teaching, or security work, but it exists inside a business model where output can scale.
The cleanest answer is this: junior devs can be socially overpaid and economically reasonable at the same time, mid-level devs are often the most fairly paid group, and real staff engineers at scale can look wildly overpaid while still being underpaid compared to the money and risk they manage.
The thing I do not buy anymore is the idea that pay equals difficulty. Pay equals leverage, scarcity, company margins, negotiation power, and how close your work is to money.
That is why the junior dev making a React form can out-earn a roofer, medic, guard, teacher, or warehouse worker. It is not because the junior dev is tougher, and it is not because the other jobs are easy. It is because the software company can scale the result in a way most physical or public-service work cannot.
That does not make the market morally correct. It just explains why the numbers look broken.
Sources
BLS, Software Developers, Quality Assurance Analysts, and Testers
BLS, Security Guards and Gambling Surveillance Officers
BLS, Construction Laborers and Helpers
BLS, Hand Laborers and Material Movers
BLS, Fatal Work Injury Rates, 2024
U.S. Army, 68W Combat Medic Specialist
Army COOL, 68W Combat Medic Specialist MOS Overview
Levels.fyi, Software Engineer Salary
BuiltIn, Junior Software Engineer Salary in US
ADP Research, The Rise and Fall of the Software Developer
Top comments (0)