Agreed, which is why I didn't say,"working remote causes developers to earn 22% more", only that developers who work remote earn 22% more, which is an interesting fact in itself.
Early in the article I adjust this for various controls to better get at causality. This includes observable factors like age, years of experience, hours worked, size of employer, programming languages used, etc.
As I note in the article: >Much of the apparent premium earned by remote developers is in fact driven by seniority and tenure. These are older, more experienced developers who either prefer to work remote or whose organizations grant them that privilege.
However, controlling for manually selected factors doesn't imply causality, so I use principled covariate selection to select the best set of controls and get closer to something that could be called causal. You can read more about this method, called Double Lasso Selection, in Urminsky, Hansen, and Chernozhukov [0].
This results in an adjusted pay premium of 9.4% for remote developers relative to those that never work remote. Hard to know for sure if this is causal either, but it's likely much closer to whatever the true causal impact is. Unsurprisingly, it's a lower number.
Thanks for reading!
[0] http://home.uchicago.edu/ourminsky/Variable_Selection.pdf
There are likely many other factors which aren't "observable" by your methodology, which are causing the 9.4% pay-premium. Factors like competency, domain knowledge, and how essential they are to the organization. I find it much more believable that these unobservable factors are causing both the pay-premium, and working-remote flexibility.
This is a common problem that comes up in such studies. Adjusting for various observable factors is great, but it still leaves behind the other unobservable factors. At which point you have to use your judgement to figure out whether those unobservable factors are more compelling than the hypothesis being tested.
That said, this is still a very cool analysis that demonstrates an interesting correlation. Thanks for sharing!
The "etc" I used in my quote is doing a lot of work here - I control for a fairly extensive list of observed factors from the dataset. I just listed out a few because otherwise the list gets absurdly long.
I control for domain knowledge via what programming languages, technologies, and tools the developers know. I use a proxy for importance to the organization by controlling for the control the developer has over buying decisions within their organization. I control for education levels and college major. I control for employment status (full-time, part-time, independent). Hours worked per week.
The list goes on but those are a few.
But your point remains that unobservables could be confounding the results, so one can never be sure.
Thanks for reading!
---
For those who aren't familiar with the aphorism, it's from a joke that goes:
One night, I came upon a man staring at the ground under a street lamp. "Looking for something?" I asked, and the man nodded, "My watch." "You lost it here?" I asked, but the man shook his head. "I lost it further down the street."
"Why look here, if the watch is over there?"
The light's better under the street lamp."
It's hard to tease that out in a survey although.
There's a lot of us that don't want to move into positions where we don't work on software development at the code level. Unfortunately, that also tends to put a cap on how much we can make because a lot of people see management as an upward movement rather than a lateral one.
> Remote Software Developers Earn 22% More Than Non-Remote Developers
To something like:
> Higher-paid software developers more likely to be working remotely
And at that point, yes, it's fairly obviously going to be true. Working remotely is a perk for those who prefer it so we should expect it to be positively correlated with other forms of compensation.
I think all that your data really shows is a hidden variable: competence. Better software developers get paid more, work remotely more, and probably also get more paid time off, larger bonuses, and all sorts of other perks.
Counter to your analysis, I'd actually expect the pay premium for remote work would be negative simply because the opportunity to work remote is worth paying for.
> (including age, experience, hours worked, size of employer, programming languages, and more)
but the "and more" link didn't give me more insight into what controls you used. The interpretation here is super duper sensitive to what those were, so you have just a straight up list of what your controls were? (before & after feature selection)
I am most curious about geographic controls, which are going to be tricky, especially since you can't just one-hot encode them and throw them into double-LASSO. The association might be as simple as "remote workers more likely to be paid in USD" or something analogous, and I'm trying to determine whether/how you controlled for that.
... but you have a heading right at the start of the article: "Remote work pays", what was that supposed to mean then?
Can you clarify whether you're using the methodology from that code for limiting your sample?
https://github.com/whoisnnamdi/highest-paid-software-develop...
e.g. only those reporting a salary between $10K and $250K?
Confirming that, yes, I am using this methodology for the results reported in this post.
Seniority is also implicitly more about _independence_ than _capability_. This is something Junior engineers are often confused about.
Its easier to hire, or let a senior work at home, because generally, they have a much stronger track record of "not becoming blocked" and "not needing someone to prioritize tasks" etc.
In short, its less about "forcing" preferences, and more about managements have seen this person execute with less oversite. Which is almost definitionally seniority.
A lot of you will respond to this "I don't need oversite to get things done" and a lot of you will be wrong. Because a lot of engineers need oversite to get _the right things_ done.
First I was in the office all the time, then I started working from home maybe one day a week....
After everyone got comfortable with me and I proved I could produce my pay increased dramatically, and at the same time work from home turned into 3-5 days a week.
Trust, pay, and working from home and / or remote all are generally related I think.
"Do you work from home more than 50% of your working hours?" has a simple yes/no answer. "What is your salary, including average annual bonus, after tax?" has a single numeric answer.
"How many years have you been a developer?" sounds simple; but has interpretation issues. Do I count from my first line of code when playing as a kid, my first computer science class, my first paying job as a developer, or some other time? If this is a measure of seniority (e.g. we define senior as anyone who's been coding for 10+ years) there will be a mixed bag.
This may mean that despite trying to factor out variables they're hiding in the noise of bad data; so may still have a hand in the result. i.e. Those developers who've counted 9 years developing from their first salaried job and now earn more and work from home are in the same group as those who've just graduated but counted their time coding from their 8-year-old-self's first foray who are in their first year of the job, and thus on lower salary and less perks.
If you just took out all these engineers I wouldn't be surprised if the average jumps by 22%.
Remote usually means more not less work, so there's that too.
Choosing the best offer world wide may end up in better pay that choosing the best offer in town.
A higher portion of remotes are temps, and/or having to incorporate in their countries, and carry the burden of doing paperwork.
Working from home is a "benefit," and it can be demanded by developers with more leverage. They can also demand more money.