Remote software developers earn more than non-remote developers(whoisnnamdi.com)
whoisnnamdi.com
Remote software developers earn more than non-remote developers
https://whoisnnamdi.com/remote-software-developers-earn-more/
164 comments
I think that it's cause and effect issue. Developers who've proven themselves to be reliable and experienced can 'force' their preferences onto employers. And they happen to cost more as well. I don't believe that going remote magically makes you able command higher salary.
Author here
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
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
One easy dumb trick I use to filter out "interesting" results that are likely just getting causality backwards is to flip the title around and see if it immediately sounds like an obvious truism. In the case of this article, it goes from:
> 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.
> 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.
You could also speculate that employers who offer WFH are more likely to pay more. It’s seen as a perk by many people, and suggesting that employers who offer more perks might pay more doesn’t seem unlikely to me. The headline would seem silly if it said “engineers who get free hot meals at work earn more than those who don’t”.
[deleted]
I feel like for those Sr. Eng's who can negotiate a remote position, if they don't go remote their careers and pay would go even further. It's one reason why I don't go remote, it's hard to reach staff or sr management positions typically when you do that.
It's hard to tease that out in a survey although.
It's hard to tease that out in a survey although.
> hard to reach staff or sr management positions
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.
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.
I work at a company with dual paths (management vs individual contributor) and a requirement to work at the code level would cap your progress upward on either path. As a senior engineer you are expected to spend significantly more time doing architecture work, mentoring other developers, and other non-code activities.
Well, that's a shame. Doing architecture work and mentoring other developers absolutely can include working with actual code.
> 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.
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!
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!
My go-to quip for making decisions based on observable variables when the actual causal relationship is between unobservable variables and outcomes is, "Looking for your watch under the street lamp."
---
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."
---
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."
Totally.
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!
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!
I see you published some code on GitHub that appears to relate either to this study or another one you published recently.
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?
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?
Thanks for checking out the code.
Confirming that, yes, I am using this methodology for the results reported in this post.
Confirming that, yes, I am using this methodology for the results reported in this post.
I tried to find the factors you controlled for. You wrote
> (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.
> (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.
You can't really remove the selection effect of higher paid developers choosing to be remote by adding external controls. You could try using an instrument for remote work or use a Simultaneous Equation Model to remove the selection effect bias.
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.
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.
very cool! any thoughts on where that premium comes from, since we're controlling for the standard stuff?
Pure speculation, but maybe you have to look around or negotiate to find remote work? Those who tend to do that probably also get better salaries than those that stick with one job for very long or don't compare much when looking for jobs.
[deleted]
One possibility is that remote developers are just more productive (or if you prefer, more productive developers are more able to negotiate a remote working allowance from their employer). In standard economic theory, the equilibrium wage is at the workers marginal revenue product (or the marginal revenue that their work produces for the organization). So you would expect remote workers to either earn more because they are more productive or, if remote work makes you more productive, to earn more as a result of working remotely and being more productive
[deleted]
> 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.
... but you have a heading right at the start of the article: "Remote work pays", what was that supposed to mean then?
... but you have a heading right at the start of the article: "Remote work pays", what was that supposed to mean then?
As a manager and software engineer,
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.
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.
Generally agreed, just wanted to point out that "oversite" is "a layer of concrete used to seal the earth under the ground floor of a house", while "oversight" is "the action of overseeing something". So yes, a lot of civil engineers need oversite to get the right things done :)
Independence and reliability are both driving factors for me as a manager. I have a junior dev with 2 years experience and he had to move due to family situation. He asked for permission earlier this year, and I didn't hesitate in saying yes. There are some "almost senior" devs on the team I would have told to walk, if they had made the same request.
[deleted]
Independence, proficiency, and good judgement.
Yes, but if the headline said "Experienced developers tend to have more freedom, like the ability to work remotely", we wouldn't click on this thread and talk about it.
I agree with you. Title is misleading.
Even as a noob it plays out that way, I've only been coding for a couple years.
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.
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.
Don’t we also expect to see this result just by the fact the remote employees working for say Bay Area companies get closer to Bay Area comp then low cost of living level comp? On average then you’ll get a higher average salary for remote employees because non remote employees includes a large number of people outside of Seattle, Bay Area, New York etc.
Another factor may be subjective vs absolute data points in the source.
"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.
"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.
It lets me escape the local (underpaid) market. That's why I won't work for Gitlab, Mozilla or similar company which pays based on the location, not contribution.
I don't even think it's that complicated. Organizations that offer remote usually won't do it for interns and junior engineers and it probably isn't great for those engineers anyways.
If you just took out all these engineers I wouldn't be surprised if the average jumps by 22%.
If you just took out all these engineers I wouldn't be surprised if the average jumps by 22%.
Yes. Most remote positions, clearly state the "prior remote work experience" is greatly appreciated or even required.
Remote usually means more not less work, so there's that too.
Remote usually means more not less work, so there's that too.
You may be onto something. Before Covid managers at my place considered remote work a reward for good behavior and delivering results. Needless to say, those people also tended to get better reviews and salaries.
Multiple reasons.
Choosing the best offer world wide may end up in better pay that choosing the best offer in town.
Choosing the best offer world wide may end up in better pay that choosing the best offer in town.
I also see that as a much simpler explanation, you don't hire unproven people on remote.
A higher portion of remotes are temps, and/or having to incorporate in their countries, and carry the burden of doing paperwork.
A higher portion of remotes are temps, and/or having to incorporate in their countries, and carry the burden of doing paperwork.
Or what about location? I know a lot of remote workers who go live in countries that are much cheaper where they couldn't find a job that would pay like this.
...and other nonlinear cause-effect things.
Working from home is a "benefit," and it can be demanded by developers with more leverage. They can also demand more money.
Working from home is a "benefit," and it can be demanded by developers with more leverage. They can also demand more money.
Myself being remote and developing mostly products from scratch I completely agree with your conclusion based on my own experience.
Exactly. Working remotely by itself doesn't lead to higher pay; it's only a perk of an employee with leverage.
[deleted]
Every time I've posted a remote job listing, I've been buried by a flood of low-effort applications. Remote work has been a hot topic for a long time now. To be blunt, there are a lot of people out there looking for cushy remote jobs where they can fade into the background and do as little work as possible. I've had a lot of negative experiences with digital nomads and "4 hour workweek" followers. One person even tried to keep their old job and the new remote position so they could get two paychecks (He couldn't keep up, didn't last long).
Instead, our remote hiring has been via outbound recruiting only. The bar for selecting these candidates is much higher, and we're also prepared to offer higher compensation to secure those candidates.
Candidates who have a proven track record of delivering quality work in a remote working positions are (or were) hard to come by. They definitely command a premium in the market.
Instead, our remote hiring has been via outbound recruiting only. The bar for selecting these candidates is much higher, and we're also prepared to offer higher compensation to secure those candidates.
Candidates who have a proven track record of delivering quality work in a remote working positions are (or were) hard to come by. They definitely command a premium in the market.
You can only do so many high-effort applications and get completely ignored before realizing it's not worth the effort
That's a good point. I've seen low-effort applications, but they pale in comparison to low-effort job listings, not to mention the "low effort" HR wall.
On my last hunt, one application for a position that'd have been a perfect match got bounced because the HR person felt that I didn't seem enthusiastic enough. (She did deliver the bad news with a happy smiley, though.)
On my last hunt, one application for a position that'd have been a perfect match got bounced because the HR person felt that I didn't seem enthusiastic enough. (She did deliver the bad news with a happy smiley, though.)
The application spam hurts both candidates and companies.
Unfortunately the only way that would change is if the entire application funnel got overhauled to stop using paper resumes as the point of entry.
You can't reasonably spend time vetting hundreds of resumes for quality candidates. And as a candidate you can't spend hundreds of hours perfectly an online application to stand out.
You end up having to game the system as a candidate. Tailoring your resume and technical interviewing skills to get in the door, but neither of those skills are reflected of your ability to deliver business value.
Outbound and reference based recruiting is probably better from a company POV, but that takes investment of time and money, and often gets offloaded to hr or recruiters who are not technically adept and are more worried about getting high conversion rates over actual job performance. From the candidate side, it means you get better opportunities based on your social connections than your technical skills, which can also lead to programmers who can talk their way into a job but can't FizzBuzz.
References from current employees seem to yield the best job-performance to applicant ratio, but can remove strong candidates without the "right connections" from the funnel.
Temp-to-hire is a nice compromise, but presents its own variety of issues.
Unfortunately the only way that would change is if the entire application funnel got overhauled to stop using paper resumes as the point of entry.
You can't reasonably spend time vetting hundreds of resumes for quality candidates. And as a candidate you can't spend hundreds of hours perfectly an online application to stand out.
You end up having to game the system as a candidate. Tailoring your resume and technical interviewing skills to get in the door, but neither of those skills are reflected of your ability to deliver business value.
Outbound and reference based recruiting is probably better from a company POV, but that takes investment of time and money, and often gets offloaded to hr or recruiters who are not technically adept and are more worried about getting high conversion rates over actual job performance. From the candidate side, it means you get better opportunities based on your social connections than your technical skills, which can also lead to programmers who can talk their way into a job but can't FizzBuzz.
References from current employees seem to yield the best job-performance to applicant ratio, but can remove strong candidates without the "right connections" from the funnel.
Temp-to-hire is a nice compromise, but presents its own variety of issues.
In general that's probably true. For the specific incident I mentioned, there are probably only a hundred or so people on the market world-wide at any given moment that have a clearly matching resume. Not caring to notice that at the HR level is truly "low effort".
I have not seen it a clearly as you describe, but at GitLab we've seen a bit of the same.
The digital nomads that move to a new room weekly tend to have a hard time focussing on work. People that move every couple of months or that have a camper tend to do better.
We've found amazing people inbound and most of our current team applied for the job themselves. But there is a lot of noise and we had to decline more than 99% of applicants. We've recently switched to sourcing (outbound recruiting) focussed model https://www.businessinsider.com/gitlab-hire-critical-roles-r...
The digital nomads that move to a new room weekly tend to have a hard time focussing on work. People that move every couple of months or that have a camper tend to do better.
We've found amazing people inbound and most of our current team applied for the job themselves. But there is a lot of noise and we had to decline more than 99% of applicants. We've recently switched to sourcing (outbound recruiting) focussed model https://www.businessinsider.com/gitlab-hire-critical-roles-r...
> The digital nomads that move to a new room weekly tend to have a hard time focussing on work. People that move every couple of months or that have a camper tend to do better.
My experience has been similar.
Honestly, I don't care what people do in their off hours, where they live, or how often they move around. The real problems come from mismatched priorities. Many of the self-described digital nomads are looking to travel, socialize, and essentially vacation all day while putting in just enough work to collect a paycheck. This creates perverse incentives to sandbag, exaggerate effort, pawn off work on coworkers, stretch deadlines, cut corners, and other behaviors that bring the whole team down.
Digital nomads are easy to single out, but the same pattern can apply to people who want remote jobs so they can focus on their side hustle, or who try to be full-time caregivers for small children during the day. In theory, it shouldn't matter if people can get their work done. In practice, it becomes a game of minimizing their work. Ultimately, it's the rest of the team that suffers, which is why I'm very careful to only hire people who can make the job their top priority during working hours.
My experience has been similar.
Honestly, I don't care what people do in their off hours, where they live, or how often they move around. The real problems come from mismatched priorities. Many of the self-described digital nomads are looking to travel, socialize, and essentially vacation all day while putting in just enough work to collect a paycheck. This creates perverse incentives to sandbag, exaggerate effort, pawn off work on coworkers, stretch deadlines, cut corners, and other behaviors that bring the whole team down.
Digital nomads are easy to single out, but the same pattern can apply to people who want remote jobs so they can focus on their side hustle, or who try to be full-time caregivers for small children during the day. In theory, it shouldn't matter if people can get their work done. In practice, it becomes a game of minimizing their work. Ultimately, it's the rest of the team that suffers, which is why I'm very careful to only hire people who can make the job their top priority during working hours.
Meh, I feel like it's probably healthy to minimize work, not dishonestly, but especially if the alternative is going into the office and not being productive for those hours anyway.
> Meh, I feel like it's probably healthy to minimize work
That’s missing the point. I don’t expect people to do work for the sake of doing work. We’re trying to get something done.
The problem comes when individuals on the team try to minimize their own workload at any cost, which inevitably creates more work for other team members. They either find ways to shift difficult tasks to other people on the team, or they cut corners and saddle the team with technical debt.
I know the popular framing is to think of workers vs. big evil corporations, but in reality most of these people end up hurting their coworkers far more than the company by selfishly minimizing their own workloads.
> if the alternative is going into the office and not being productive for those hours anyway
In a properly functioning team, that should never happen. I can’t think of any time in my professional career where our work backlog has literally gone to zero. A properly managed roadmap and backlog means there should always be something to work on.
I don’t expect employees to work extra hours to chip away at the backlog, but if someone finishes their assigned tasks early then they need to step up and help the team or work on the next tasks in the backlog.
If someone is constantly running out of work and finding themselves spending unproductive hours at the office, their team is likely oversized in the first place. Those people are either moved to another team or at the top of the list when it’s time for layoffs, sadly.
That’s missing the point. I don’t expect people to do work for the sake of doing work. We’re trying to get something done.
The problem comes when individuals on the team try to minimize their own workload at any cost, which inevitably creates more work for other team members. They either find ways to shift difficult tasks to other people on the team, or they cut corners and saddle the team with technical debt.
I know the popular framing is to think of workers vs. big evil corporations, but in reality most of these people end up hurting their coworkers far more than the company by selfishly minimizing their own workloads.
> if the alternative is going into the office and not being productive for those hours anyway
In a properly functioning team, that should never happen. I can’t think of any time in my professional career where our work backlog has literally gone to zero. A properly managed roadmap and backlog means there should always be something to work on.
I don’t expect employees to work extra hours to chip away at the backlog, but if someone finishes their assigned tasks early then they need to step up and help the team or work on the next tasks in the backlog.
If someone is constantly running out of work and finding themselves spending unproductive hours at the office, their team is likely oversized in the first place. Those people are either moved to another team or at the top of the list when it’s time for layoffs, sadly.
I think it's only sometimes healthy to take on more stuff after you've completed what you set out to that day. In my mind, the reward for productivity should not be more work. Fuck that. At the office or not, most of the time I'll try and get what I set out to do that day done, and then leave unless there's something pressing. Mostly though, if there was something pressing, then it would have been part of my goal for that day anyway.
You'd put someone on the chopping block for being too efficient? That doesn't sound sensible.
You'd put someone on the chopping block for being too efficient? That doesn't sound sensible.
I like my work and I enjoy being effective but my job is never my top priority.
I think OP means during your work day. You don't want to be working with someone that is working remotely so that, during their work day, they can also look after a young child, or is focused on organizing and going for a long social lunch, or thinking where in this new city they are going to visit.
You want someone who, for the hours that they are working, main priority (unless there is an unlikely emergency) is getting their work done. (and responding on Hacker news)
You want someone who, for the hours that they are working, main priority (unless there is an unlikely emergency) is getting their work done. (and responding on Hacker news)
I'm pretty sure that everyone is interested in minimizing work that they don't like.
I bet you do the same. I bet that if you had a skill that is highly valued, but you're not really into it, you'd do all in your power to minimize the work you put in... Be it in the office or remotely.
Fuck! I had a contract and had a new manager installed 2 months into a 3 month contract. I had to be in the office 9 to 5 every workday - no exceptions. I couldn't leave and I basically did nothing during that month.... While being in the office.
I bet you do the same. I bet that if you had a skill that is highly valued, but you're not really into it, you'd do all in your power to minimize the work you put in... Be it in the office or remotely.
Fuck! I had a contract and had a new manager installed 2 months into a 3 month contract. I had to be in the office 9 to 5 every workday - no exceptions. I couldn't leave and I basically did nothing during that month.... While being in the office.
I am interested in working as a software engineer at Gitlab, what do you feel is a good path to land a job at the company? I plan to start contributing meaningful changes to gitlab itself and have a couple of side projects to show. What else can I do to land a job and how do I get noticed since it's mostly outbound hiring going forward. Note : I don't use linkedin and don't plan to. Given my unique circumstances, any advice would be nice. Thanks.
Edit : Another question : since I am currently in my first job, whom do I give as references? I can't give my current manager as a reference for obvious reasons. Weird question : I contribute to OSS projects (and plan to contribute to gitlab), do you think I can give the OSS maintainers as references?
Edit : Another question : since I am currently in my first job, whom do I give as references? I can't give my current manager as a reference for obvious reasons. Weird question : I contribute to OSS projects (and plan to contribute to gitlab), do you think I can give the OSS maintainers as references?
We don't accept inbound applications from outside the company anymore. We do have a talent community https://boards.greenhouse.io/gitlab/jobs/4700367002?gh_src=d...
Thanks for planning to contribute to GitLab. When your submission passed review consider messaging the reviewer and mention you're interested in working here. We do still accept references from team members.
There is no need for a LinkedIn profile.
If you're currently in your first job a reference can be a peer you trust there, a former teacher, or a manager from a side-job or hobby. OSS maintainers work work as well.
Thanks for planning to contribute to GitLab. When your submission passed review consider messaging the reviewer and mention you're interested in working here. We do still accept references from team members.
There is no need for a LinkedIn profile.
If you're currently in your first job a reference can be a peer you trust there, a former teacher, or a manager from a side-job or hobby. OSS maintainers work work as well.
Hello! I'm Chantal, a Junior Technical Recruiter from GitLab. It definitely sounds like you've got a good plan so far. We love when folks contribute, and it's a way to get to know some GitLabbers.
Another way to stand out would be to make a nice cover letter if you have the time/resources. I can still recall several awesome cover letters I've read and know that it does make a difference!
I'd be happy to have a video call with you if you'd like to talk more about this topic. I was a Junior Backend Engineer with a non-traditional background, so I've gone through a similar experience!
Another way to stand out would be to make a nice cover letter if you have the time/resources. I can still recall several awesome cover letters I've read and know that it does make a difference!
I'd be happy to have a video call with you if you'd like to talk more about this topic. I was a Junior Backend Engineer with a non-traditional background, so I've gone through a similar experience!
I've been a digital nomad for 2 years and you learn pretty quickly how disruptive moving is. I Generally stay in a location for at least a month for that reason. Key is to do your research and identify areas with all the basicls ahead of your arrival (wifi cafe, supermarket, gym etc) so that you can establish a routine within a day. My motivations are a bit different from most nomads as I do this to avoid burnout. There's few things more inspiring to write code than spending spending your off hours swimming with sea turtles and exploring new neighborhoods.
"Outbound recruiting" is eminently practical, but still one of the most chilling phrases I've ever heard.
It's not enough that you essentially have to know someone on the inside to get your resumé reviewed anywhere, now they're not even taking applications.
It's not enough that you essentially have to know someone on the inside to get your resumé reviewed anywhere, now they're not even taking applications.
“People that move every couple of months or that have a camper tend to do better.“
I work remotely but I honestly can’t imagine such people being able to do sustained deep development work. It seems that lifestyle is more suitable for work that’s done in relatively small increments.
I work remotely but I honestly can’t imagine such people being able to do sustained deep development work. It seems that lifestyle is more suitable for work that’s done in relatively small increments.
> relatively small increments.
As in - most software development these days.
As in - most software development these days.
As a current seeker of a remote position, and based on the relatively small amount of responses I've been getting, I feel like I might be falling into that bucket of applications that appear low-effort. What indicates to you that an application is low-effort?
Relatedly I wonder how much a high effort canidate vs a low effort canidate actually works out in a screening process despite whatever prejudices they may hold one way or another.
It reminds me of the recession bad old days where some companies were making a policy of hiring only the already employed and got essentially an exasperated facepalm from congress asking if they /really/ will have to ban hiring discrimination against the unemployed.
It reminds me of the recession bad old days where some companies were making a policy of hiring only the already employed and got essentially an exasperated facepalm from congress asking if they /really/ will have to ban hiring discrimination against the unemployed.
Not having a cover letter that directly speaks to what I am looking for, instead having a generic blurb or no blurb at all. That's one example.
I think the biggest tell would be a resume that isn't tailored to the specific job.
How does one tailor a resume to a specific job without bending the truth? I don't have experience with the exact stack listed but I bet I could get up to speed within a week or two given the chance.
edit: And what does tailoring to a specific job mean? Should I change my job titles to match? Do I just copy a bunch of keywords from it into my descriptions? I've never worked that specific job that is why I am applying
edit: And what does tailoring to a specific job mean? Should I change my job titles to match? Do I just copy a bunch of keywords from it into my descriptions? I've never worked that specific job that is why I am applying
Remove irrelevant positions and focus on projects that match the target.
Assumedly during your career you have done multiple small projects on one topic or another, highlight the ones that interest the employer and the ones you feel particularly proud of, don't mention the others.
Assumedly during your career you have done multiple small projects on one topic or another, highlight the ones that interest the employer and the ones you feel particularly proud of, don't mention the others.
An interesting point. But employers should start giving out instructions on what they want to see.
I had a few employers tell me that my resume of 5 pages was not long enough and others that complained about too much information.
So... This provide only relevant information is as valuable as keeping quiet.
When you advertise a position, do you inform what form the CV should be in?
The hiring process is de facto a completely subjective system of both sides hoping the other would screw up to make their decision easier, while playing mind games.
I interviewed at Bridgewater on site, their interview was awesome and clear. More companies should be that clear and forthcoming as Bridgewater Associates.
I had a few employers tell me that my resume of 5 pages was not long enough and others that complained about too much information.
So... This provide only relevant information is as valuable as keeping quiet.
When you advertise a position, do you inform what form the CV should be in?
The hiring process is de facto a completely subjective system of both sides hoping the other would screw up to make their decision easier, while playing mind games.
I interviewed at Bridgewater on site, their interview was awesome and clear. More companies should be that clear and forthcoming as Bridgewater Associates.
It's just you focus more on the parts that are relevant for the job.
Unless you're fresh out of school, you likely have more experience than what can fit on a CV. However most of it is at best tangentially relevant.
So you reduce/remove the parts that do not apply, and go into more details on the parts that apply.
Of course, if all the jobs you apply are pretty similar (say front end with React), then you won't change much between each CV.
Unless you're fresh out of school, you likely have more experience than what can fit on a CV. However most of it is at best tangentially relevant.
So you reduce/remove the parts that do not apply, and go into more details on the parts that apply.
Of course, if all the jobs you apply are pretty similar (say front end with React), then you won't change much between each CV.
Hello! I'm Chantal, a Junior Technical Recruiter from GitLab. Some other folks have provided great thoughts on this subject.
In general, I think you have to understand your audience. If you're applying for a job at a large company, or one that you know receives a ton of applications, you should find a way to stick out. Also, the recruiters likely won't have enough time to read through a 5 page resume. If you're applying to a smaller company, that long resume and cover letter might not be a bad idea. I asked my teammates to add tips about resume writing since I'm going to be helping out some bootcamp graduates soon. Maybe it will help: https://gitlab.com/gitlab-com/people-group/recruiting/-/issu...
In general, I think you have to understand your audience. If you're applying for a job at a large company, or one that you know receives a ton of applications, you should find a way to stick out. Also, the recruiters likely won't have enough time to read through a 5 page resume. If you're applying to a smaller company, that long resume and cover letter might not be a bad idea. I asked my teammates to add tips about resume writing since I'm going to be helping out some bootcamp graduates soon. Maybe it will help: https://gitlab.com/gitlab-com/people-group/recruiting/-/issu...
If the position requirements describe certain things they want and you have done those things at certain jobs, basically say that you have done what they are asking for at those jobs. Things like "work on multitier web application" or other items that are not stack specific but that you have done. Include text closely matching those descriptions at jobs where you've done it.
If you don't have the experience I don't know how you'd craft it to be honest except for perhaps being descriptive in the cover letter about how you don't match everything but what you are able to offer and why you may be excited to work in the specific role at the company.
If you don't have the experience I don't know how you'd craft it to be honest except for perhaps being descriptive in the cover letter about how you don't match everything but what you are able to offer and why you may be excited to work in the specific role at the company.
While you can definitely tailor your resume, it's as much about not applying for jobs you really aren't qualified for. When we tried to hire for a Postgresql role, we got tons of Excel and Access people that couldn't spell Postgresql. If the job is for an AWS expert, and you're a Rails developer whose AWS experience is using an S3 gem, don't apply.
Ugh, so frustrating to hear this as a remote worker who is only remote because of family. Putting in a lot of effort into applications is not sustainable considering you will not even get a response from a surprising amount of companies, especially during covid where there are a lot of hiring freezes and a higher amount of job-seekers.
Interesting! Do you find most of your outbound hires through LinkedIn? Or what channels do you typically use to look for candidates? (referrals, GitHub, referrals, HN...?)
It took me a fair while to learn how to work productively while fully remote (thankfully it was on my own dime), and I feel like I've gotten the hang of it now. Bit annoying that the issue you're describing will make it harder to get remote work in the future.
This isn't a veiled hiring entreaty by the way, I'm happily employed, but this seems like something useful to know.
It took me a fair while to learn how to work productively while fully remote (thankfully it was on my own dime), and I feel like I've gotten the hang of it now. Bit annoying that the issue you're describing will make it harder to get remote work in the future.
This isn't a veiled hiring entreaty by the way, I'm happily employed, but this seems like something useful to know.
What constitutes a high vs low effort application?
How do you identify potential candidates for remote hiring in your your outbound recruiting efforts?
A friend of mine works/worked for <large company> in Seattle. He's a really talented guy, probably on his way to Principle Engineer in the near future. He's also pretty critical to some major work they're doing. I'm certain he's paid well for it.
He told his boss he was moving to Montreal. Most other developers, if they said that the boss would probably have said "well, it's been great working with you". But my friend was a critical employee. Can't lose that guy.
Somehow, they found a way to let him be a remote developer from Montreal. Still doing great work. Still being paid well, I imagine. And this is all pre-pandemic.
Correlation does not imply causation. Being allowed to be a remote developer and being paid well are both signs that you might just be critical to your organization.
He told his boss he was moving to Montreal. Most other developers, if they said that the boss would probably have said "well, it's been great working with you". But my friend was a critical employee. Can't lose that guy.
Somehow, they found a way to let him be a remote developer from Montreal. Still doing great work. Still being paid well, I imagine. And this is all pre-pandemic.
Correlation does not imply causation. Being allowed to be a remote developer and being paid well are both signs that you might just be critical to your organization.
Author here
I think this is a quite common story, or at least I've heard it a few times now so it feels that way:
(1) Senior, important developer decides they want to change locations.
(2) Boss can't afford to lose them.
(3) So boss let's them work from wherever they want.
This of course leads to natural correlation between working remote and skill, which would further correlate to earnings.
Replacing a good software developers is non-trivial.
That said, to quote from the analysis: Even once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely.
I think this is a quite common story, or at least I've heard it a few times now so it feels that way:
(1) Senior, important developer decides they want to change locations.
(2) Boss can't afford to lose them.
(3) So boss let's them work from wherever they want.
This of course leads to natural correlation between working remote and skill, which would further correlate to earnings.
Replacing a good software developers is non-trivial.
That said, to quote from the analysis: Even once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely.
I guess the problem is that the analysis can't find a variable for "is critical". I know lots of people with age, experience, hours worked, etc, that are not critical. I can think of a few that are exactly the opposite of critical.
The only decent variable to measure whether someone is critical is their salary. But your anlaysis makes it sound as though [remote -> high salary], when really [high salary -> critical] and [remote -> critical].
The only decent variable to measure whether someone is critical is their salary. But your anlaysis makes it sound as though [remote -> high salary], when really [high salary -> critical] and [remote -> critical].
I'd go so far as to say that critical and valuable are not necessarily the same thing. I'd like to think I'm valuable; I go out of my way to not be critical. Intentional knowledge shares, documentation, mentoring, etc, plus focusing on writing systems that are fault tolerant, means that I could leave and it -should- be a minor hiccup. Heck, almost an entire team left along with me at one point in my career, and the projects we left behind just...kept working, no issues. Doubt that company is actually looking to figure them out so they can extend/support them should something need changing, but that's on them.
If I stayed at companies that fall under #2, I'd be eternally miserable.
I hate working with people who cannot be fired because the company would fold.
We, developers, should be the people who the bosses actively want to be there... not "we can't fire him". It makes people less complacent towards other people.
I hate working with people who cannot be fired because the company would fold.
We, developers, should be the people who the bosses actively want to be there... not "we can't fire him". It makes people less complacent towards other people.
I would say every company that has been around the block for a long time falls somewhat under #2.
Some companies have millions and millions of LoC to run their business and it takes months for someone to wrap their head around some of the systems and be productive...
You end up having people in departments that you would rather not lose and will go through great lengths to keep them because the cost of losing the institutional knowledge is just too big.
Some companies have millions and millions of LoC to run their business and it takes months for someone to wrap their head around some of the systems and be productive...
You end up having people in departments that you would rather not lose and will go through great lengths to keep them because the cost of losing the institutional knowledge is just too big.
The hazard there is that a new boss may come in and either not see this person as critical and let him/her go or see this person as critical and go to the effort to find an equivalently senior onsite person to replace him.
If they didn't adjust his salary then he's making ~50-60% more because of the cost of living difference and USD currency.
Even for that guy, this is probably a terminal role at the company. Granted, pushing principal engineer is a pretty good place to settle, but he can't expect much advancement.
It might be obvious to say, but this is really dependent on the culture of the company.
IME, if other engineers at the company (team members, managers) recognize your talent, they will give you a raise to keep you there, no matter whether you're remote or on-site. This is true for the simple fact that talented engineers tend to know they're talented, and when career advancement opportunities dissipate, they do not stick around long.
Anecdotally, my company has several remote staff engineers. They get raises and promotions like anybody else, and have been remote for multiple performance review cycles. Our company has an on-site bias, but not a particularly strong one. That being said, if your company is old (15+ years) and not eng-driven, YMMV.
IME, if other engineers at the company (team members, managers) recognize your talent, they will give you a raise to keep you there, no matter whether you're remote or on-site. This is true for the simple fact that talented engineers tend to know they're talented, and when career advancement opportunities dissipate, they do not stick around long.
Anecdotally, my company has several remote staff engineers. They get raises and promotions like anybody else, and have been remote for multiple performance review cycles. Our company has an on-site bias, but not a particularly strong one. That being said, if your company is old (15+ years) and not eng-driven, YMMV.
Honestly, that sound exactly like the path I took. Was a senior engineer when I moved away from where my office was and went remote on a special dispensation (my company is in general quite hostile to remote work) and since then my career has continued to progress more or less as I expected. Of course I don't really know the counterfactual but in general I think people way overestimate the value of "face time" for career progression. And if you can be more productive working remotely (which I certainly think I have been) then it can be a net benefit. Of course that all depends on the company. Going remote is probably not great if you work at a small company with a tight-knit team.
If you work as a software engineer outside of a handful of cities, you earn much less. E.g. a software engineer working in Tulsa makes a lot less than one working in San Francisco. But if you work remote from Tulsa, you can work for a company in one of the top cities and will make a higher salary, on average than your local peers. I don't think remote workers in the valley make more than their peers - maybe less.
I've worked remote my whole career, and the main reason I do that is I get a substantially higher salary than my local peers because I don't live in the USA.
I've worked remote my whole career, and the main reason I do that is I get a substantially higher salary than my local peers because I don't live in the USA.
Yes, I've said exactly this a bunch of times. My advice to young programmers is always this: work for a while in a city with high salaries and lots of demand, then after some years when you are experienced and high value (genuinely so), make the jump to remote, move to a smaller, less expensive place and buy a house. I honestly think this is the best life advice I can give and I wish I'd done it a decade sooner than I did.
This is similar to my anecdote. I hit the local salary ceiling but was unable to move due to family obligations. That's how I became a remote worker.
If anybody living in Tulsa can do this, the arbitrage opportunity will at some point end and Tusla will get more expensive and SF less expensive.
Not true. Not everyone is cut out for remote work. It needs a certain set of skills and a frame of mind which are not available to everyone or take time to develop.
Does the author control for geography?
Surely remote workers in Europe working for American employers will earn more than their non-remote counterparts, but not the reverse.
(EDIT) I see the author in the original post subset only for US-based workers: "The survey is global, but here I focus on 10,355 U.S. based individuals employed as software engineers on either a part-time, full-time, or independent basis"
Surely remote workers in Europe working for American employers will earn more than their non-remote counterparts, but not the reverse.
(EDIT) I see the author in the original post subset only for US-based workers: "The survey is global, but here I focus on 10,355 U.S. based individuals employed as software engineers on either a part-time, full-time, or independent basis"
Wouldn't US present the same problem? Remote worker in Montana for a SF based company is likely to make more than its peers working in Montana.
Author here
Yes the results include only the U.S. but do not include more granular controls for regions within the U.S. So it's possible that this is biasing the results.
That said, I do control for size of company, which often correlates strongly with region (both big tech companies and startups tend to employ most of their workforce from a certain region, i.e. west coast). I acknowledge this is imperfect though
Yes the results include only the U.S. but do not include more granular controls for regions within the U.S. So it's possible that this is biasing the results.
That said, I do control for size of company, which often correlates strongly with region (both big tech companies and startups tend to employ most of their workforce from a certain region, i.e. west coast). I acknowledge this is imperfect though
Bit of an understatement. Doing a study about remote developers and substituting geography with a proxy. At least for me it would seem really obvious we are disregarding a main factor. What are the numbers if we control for location?
Awesome analysis. Thanks for sharing this @whoisnnamdi
> 10,355 U.S. based individuals employed as software engineers on either a part-time, full-time, or independent basis
I'm unclear how you're controlling for employment-type pay differences, which can be significant. Independent (1099) workers pay 100% of U.S Federal Income Tax, whereas Employees pay 50%. (Same thing for extra costs, like health insurance, retirement plans, etc.)
Edit: I suppose size of employer might be one way to do it.
> 10,355 U.S. based individuals employed as software engineers on either a part-time, full-time, or independent basis
I'm unclear how you're controlling for employment-type pay differences, which can be significant. Independent (1099) workers pay 100% of U.S Federal Income Tax, whereas Employees pay 50%. (Same thing for extra costs, like health insurance, retirement plans, etc.)
Edit: I suppose size of employer might be one way to do it.
Thank you!
Yes this is an important point. I don't mention it there, but I do control for full-time vs part-time vs. self-employed in my analysis.
I'll cover this in a coming post, but full-time and self-employed developers make very similar amounts on average, with a slight benefit for full-time employed.
I cannot control for the tax effects unfortunately, as I have no data on taxes paid.
Yes this is an important point. I don't mention it there, but I do control for full-time vs part-time vs. self-employed in my analysis.
I'll cover this in a coming post, but full-time and self-employed developers make very similar amounts on average, with a slight benefit for full-time employed.
I cannot control for the tax effects unfortunately, as I have no data on taxes paid.
> I cannot control for the tax effects unfortunately, as I have no data on taxes paid.
In that case I suggest separating the "Independent contractor, freelancer, or self-employed" group from the , "Employed Full Time" and "Employed part-time" groups. [1] The way that contractors are compensated is significantly different from how employees are compensated.
[1] https://insights.stackoverflow.com/survey/2019#work-_-employ...
In that case I suggest separating the "Independent contractor, freelancer, or self-employed" group from the , "Employed Full Time" and "Employed part-time" groups. [1] The way that contractors are compensated is significantly different from how employees are compensated.
[1] https://insights.stackoverflow.com/survey/2019#work-_-employ...
I earn remarkably more as a remote developer than I would for my area because I work remotely for a company based in a high income area (NYC) but live in the midwest. I probably make 20-30% more, at least, than a Senior Engineer at a local company would at the top of their payscale.
It has nothing to do with experience levels or anything like that, just companies based in high income areas pay more. My salary is even scaled down a bit based on regional cost of living (I'd likely earn 10% more if I relocated to NYC, which would not make up for the cost of living in new york)
It has nothing to do with experience levels or anything like that, just companies based in high income areas pay more. My salary is even scaled down a bit based on regional cost of living (I'd likely earn 10% more if I relocated to NYC, which would not make up for the cost of living in new york)
I've been working remotely for almost a decade. I'm a senior developer and make a very good living.
It's generally much more difficult for junior developers. At my last job, our team comprised of all senior developers. We hired a few juniors and it was very difficult due to roadblocks/communication. I think this is one reason remote developers earn more: you need to be pretty independent and skilled for it to work out well.
It's generally much more difficult for junior developers. At my last job, our team comprised of all senior developers. We hired a few juniors and it was very difficult due to roadblocks/communication. I think this is one reason remote developers earn more: you need to be pretty independent and skilled for it to work out well.
This is a more useful summary than the headline:
> once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely.
I wouldn't get too attached to any theories of causality or why, but as an experienced remote worker, I'll speculate, FWIW:
* Generally (not always, just generally), employers tend to be hesitant and uncomfortable with remote workers. So the people that get and keep those arrangements tend to be those that have proven to be more trusted, capable, and indispensable. (Which all help with higher pay too, of course.)
This, BTW, describes my anecdotal experience at my company. Over the years we've collected a decent sized group of people who work remotely, even though the company doesn't generally allow it. The specifics of various cases have been different, but generally something happens that would force the issue (often an office move -- don't know why we need to do that so much), and some people either need to leave the company or work remotely. In those cases, accommodations were usually eventually made for people seen as indispensable while others were let go (in one way or another). This is across various management regimes. One time there was a hard-line stance, "move or be laid off". There was a months long game of chicken, but in the end it was the management that was replaced. (Not necessarily for that -- they made various counter-productive decisions.)
* I think another reason for the higher pay may be that (IMO) you really do need to be a better communicator as a remote employee. I think most people working remotely become significantly better communicators, over time, and that translates to more senior positions and pay.
> once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely.
I wouldn't get too attached to any theories of causality or why, but as an experienced remote worker, I'll speculate, FWIW:
* Generally (not always, just generally), employers tend to be hesitant and uncomfortable with remote workers. So the people that get and keep those arrangements tend to be those that have proven to be more trusted, capable, and indispensable. (Which all help with higher pay too, of course.)
This, BTW, describes my anecdotal experience at my company. Over the years we've collected a decent sized group of people who work remotely, even though the company doesn't generally allow it. The specifics of various cases have been different, but generally something happens that would force the issue (often an office move -- don't know why we need to do that so much), and some people either need to leave the company or work remotely. In those cases, accommodations were usually eventually made for people seen as indispensable while others were let go (in one way or another). This is across various management regimes. One time there was a hard-line stance, "move or be laid off". There was a months long game of chicken, but in the end it was the management that was replaced. (Not necessarily for that -- they made various counter-productive decisions.)
* I think another reason for the higher pay may be that (IMO) you really do need to be a better communicator as a remote employee. I think most people working remotely become significantly better communicators, over time, and that translates to more senior positions and pay.
When I see payment for devs here in Germany, it's no surprise.
I had the feeling, that US devs make about double of what German companies are paying.
So now I make more money and add to the exports that everyone in Germany seems to be so happy about :D
I had the feeling, that US devs make about double of what German companies are paying.
So now I make more money and add to the exports that everyone in Germany seems to be so happy about :D
I didn't understand your comment. Are you working for a German company or remote for a US one?
I'm from Germany working for US companies.
I'm "exporting" my work from Germany to the USA.
I'm "exporting" my work from Germany to the USA.
Thank for the clarification.
How do you find gigs/customers in the US?
I'm in nearby Austria and would like to do the same. The salaries here are a joke.
How do you find gigs/customers in the US?
I'm in nearby Austria and would like to do the same. The salaries here are a joke.
I blogged, wrote a book, put myself out there in the English speaking IT community.
People started noticing.
But I have to admit, nowadays I only make money with writing about development and not much production-software development anymore.
People started noticing.
But I have to admit, nowadays I only make money with writing about development and not much production-software development anymore.
For some people it is a bit of a revelation that this can work, at all. Because they are so used to the status quo of some dude in suit micromanaging what they do in a waterfall like process that people insist is agile (usually anything but). This is not the only way to develop software.
If you think about it, there are a lot of developers world wide, which makes any perceived scarcity locally a non issue once you change your mind set and stop insisting that they live within easy commute of wherever your office is.
Also, a lot of OSS software that we love and depend on every day defaults to fully remote people organized in collectives that are vastly larger than most corporate software teams producing software at a pace that these teams can only dream off. Good software gets developed by an army of remote developers and you probably use a lot of it every day and maybe even contribute to it once in a while.
Another thing to consider is that lots of large corporations are so large that most of their people might as well be remote even if they share the same building (if they still fit in just one). Being in the same building doesn't mean people talk to each other.
I used to work in Nokia when that was still a multinational making phones and employing around 30K developers & engineers spread over multiple countries and continents. Think lots of telcos, traveling and miscommunication.
If you think about it, there are a lot of developers world wide, which makes any perceived scarcity locally a non issue once you change your mind set and stop insisting that they live within easy commute of wherever your office is.
Also, a lot of OSS software that we love and depend on every day defaults to fully remote people organized in collectives that are vastly larger than most corporate software teams producing software at a pace that these teams can only dream off. Good software gets developed by an army of remote developers and you probably use a lot of it every day and maybe even contribute to it once in a while.
Another thing to consider is that lots of large corporations are so large that most of their people might as well be remote even if they share the same building (if they still fit in just one). Being in the same building doesn't mean people talk to each other.
I used to work in Nokia when that was still a multinational making phones and employing around 30K developers & engineers spread over multiple countries and continents. Think lots of telcos, traveling and miscommunication.
Could this be selection bias?
Better developers have their choice of companies, and it makes sense that they would prefer WFH over working in an office.
Better developers have their choice of companies, and it makes sense that they would prefer WFH over working in an office.
I prefer working in an office, but do work somewhere that I have the option of WFH when I want to (pre-COVID, we’re all remote now). I felt I had my choice of company when I was job searching last. Its just not universal that talented people want to WFH. I live 1.5 miles from the downtown of my city, in a residential neighborhood. We have parks and space and I can still ride my bike to work and engage with colleagues face to face as I prefer.
The results are also selected from a StackOverflow survey. It is hard to tell if SO survey respondents overrepresent higher-earning remote workers or not.
Yup, this comment should be at the very top. The first problem with this analysis of job salaries is it's based on a self-selected survey and not a random sample.
Of course. Remote developers tend to be more senior. Once you control for that, I'd be surprised if this still holds true, given that the FAANGs tend to pay a high share of the highest salaries and they tend to not allow remote work.
Author here
Thanks, yes this is an important point which I cover later in the analysis:
"Even once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely."
Thanks, yes this is an important point which I cover later in the analysis:
"Even once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more), fully-remote software developers earn 9.4% more than developers who never or only rarely work remotely."
You're probably right, but consider the other side. If you remove the FAANGs from consideration (a heavy weight on the non-remote side of the scales) then the remote work premium would look even better.
Has anyone taken a look at the underlying data set, specifically for the compensation aspect? https://drive.google.com/file/d/1QOmVDpd8hcVYqqUXDXf68UMDWQZ...
Each record has a currency, a "CompTotal" (number of units of pay currency), a "CompFreq" (periodicity of pay; yearly/monthly/weekly) and a "ConvertedComp".
ConvertedComp is CompTotal multiplied by the number of CompFreq periods in a year, converted to USD based on the specified currency and then clipped at the 98th percentile which seems to be $2M.
It seems ConvertedComp is what analysts are intended to use.
Of the United States-based, developer-by-profession responses who gave a salary (~13,500), about 14% specified their CompFreq as something other than annually. That subset has a mean ConvertedComp of >$1M.
On the other hand, there are a grand total of 17 responses for ConvertedComp of >$1M for those who specified their CompFreq as annually.
Color me suspicious, but I suspect a large fraction of the responses in that subset gave annual compensation rather compensation-per-period; undermining the calculation of ConvertedComp quite considerably.
I don't know which fields the author actually used, but I have a lot of questions about the usefulness of this data.
Each record has a currency, a "CompTotal" (number of units of pay currency), a "CompFreq" (periodicity of pay; yearly/monthly/weekly) and a "ConvertedComp".
ConvertedComp is CompTotal multiplied by the number of CompFreq periods in a year, converted to USD based on the specified currency and then clipped at the 98th percentile which seems to be $2M.
It seems ConvertedComp is what analysts are intended to use.
Of the United States-based, developer-by-profession responses who gave a salary (~13,500), about 14% specified their CompFreq as something other than annually. That subset has a mean ConvertedComp of >$1M.
On the other hand, there are a grand total of 17 responses for ConvertedComp of >$1M for those who specified their CompFreq as annually.
Color me suspicious, but I suspect a large fraction of the responses in that subset gave annual compensation rather compensation-per-period; undermining the calculation of ConvertedComp quite considerably.
I don't know which fields the author actually used, but I have a lot of questions about the usefulness of this data.
Much of this may be the effect of averaging a power law.
Whenever you remove barriers to entry (whether geographic, skill-based, or social), you get regression to the mean: if workers are actually identical, they should be paid the same. The mean of a power law distribution is always higher than the media. Hence, if you remove geographic barriers to software development work, the majority of software developers will see their salaries increase. This comes at the expense of a few developers in high-paying areas (Silicon Valley, SF, NYC), who will see their salaries dramatically decreased. We already see this - as someone living in Silicon Valley, I can't take the vast majority of remote jobs because they don't pay enough to live on here.
Someone's inevitably going to ask "If salaries are so unsustainably high in Silicon Valley, why do companies keep hiring there and paying those unsustainable salaries?"
And the answer to that is that opportunities are not normally distributed. In today's consumer markets, consumers don't split their dollars evenly between all firms providing a good, they tend to overwhelmingly go for the best product available in that market, particularly if that product gets on the market early. And that means going for a location where you have deep talent pools in the many subspecialties needed to build that best product, and putting them all in one cube farm so that communication costs between them are at an absolute minimum. Silicon Valley's wage premium is a consequence of growth and of consumer herd behavior: if everybody either thought entirely for themselves or bought solely based on price without regards to features, distributed teams would have an advantage.
It's a very similar phenomena as globalization. In the 80s all of America enjoyed a large wage premium over all of the rest of the world. As globalization broke down labor & trade barriers and innovation slowed, the trend has been toward "equal pay for equal work", which means that the factory worker in America will make something close to what the factory maker in China makes. Global median wages rise (which they have done, substantially), but the gains are at the cost of the majority of American wages, with the exception of a few professions (tech, finance, some marketing) that have substantial skill-based barriers to entry. Those professions have seen their wages increase dramatically as markets get bigger.
Whenever you remove barriers to entry (whether geographic, skill-based, or social), you get regression to the mean: if workers are actually identical, they should be paid the same. The mean of a power law distribution is always higher than the media. Hence, if you remove geographic barriers to software development work, the majority of software developers will see their salaries increase. This comes at the expense of a few developers in high-paying areas (Silicon Valley, SF, NYC), who will see their salaries dramatically decreased. We already see this - as someone living in Silicon Valley, I can't take the vast majority of remote jobs because they don't pay enough to live on here.
Someone's inevitably going to ask "If salaries are so unsustainably high in Silicon Valley, why do companies keep hiring there and paying those unsustainable salaries?"
And the answer to that is that opportunities are not normally distributed. In today's consumer markets, consumers don't split their dollars evenly between all firms providing a good, they tend to overwhelmingly go for the best product available in that market, particularly if that product gets on the market early. And that means going for a location where you have deep talent pools in the many subspecialties needed to build that best product, and putting them all in one cube farm so that communication costs between them are at an absolute minimum. Silicon Valley's wage premium is a consequence of growth and of consumer herd behavior: if everybody either thought entirely for themselves or bought solely based on price without regards to features, distributed teams would have an advantage.
It's a very similar phenomena as globalization. In the 80s all of America enjoyed a large wage premium over all of the rest of the world. As globalization broke down labor & trade barriers and innovation slowed, the trend has been toward "equal pay for equal work", which means that the factory worker in America will make something close to what the factory maker in China makes. Global median wages rise (which they have done, substantially), but the gains are at the cost of the majority of American wages, with the exception of a few professions (tech, finance, some marketing) that have substantial skill-based barriers to entry. Those professions have seen their wages increase dramatically as markets get bigger.
> We already see this - as someone living in Silicon Valley, I can't take the vast majority of remote jobs because they don't pay enough to live on here.
You also can't afford _not_ to take them since the high cost of living limits how much you can save each month.
This is one of those things that isn't mentioned often - somebody with cheaper costs of living can play hardball for months in search of a good gig. Somebody in NYC or San Fran, not so much.
You also can't afford _not_ to take them since the high cost of living limits how much you can save each month.
This is one of those things that isn't mentioned often - somebody with cheaper costs of living can play hardball for months in search of a good gig. Somebody in NYC or San Fran, not so much.
Not so much of an issue for me personally because I built up a bunch of savings before COL became insane. Every time I've been on the job market, it hasn't been an issue to wait several months for a better offer to come around. You can rebuild savings awfully quickly when living costs $120K/year but your job pays $500K/year.
I feel for newer developers that just moved out here with nothing to take $120K/year jobs when living costs $120K/year, though.
I feel for newer developers that just moved out here with nothing to take $120K/year jobs when living costs $120K/year, though.
Author here
I agree with everything in your comment except the first line.
I don't think software developer pay follows a power law, or at least not in this dataset. Ignoring equity (which can cause power law type behavior if enough folks strike it rich), the distribution of pay is probably closer to a lognormal distribution. It's just not skewed enough to constitute a power law — that would imply serious skew.
Additionally, this dataset excludes outliers making multiple millions of dollars, so that also reduces the likelihood of a power law-style distribution.
Lastly, this dataset is only U.S. developers, so there isn't skew across meaningfully different geographies.
With a lognormal distribution, your point remains valid, but the effect is not nearly so dramatic.
I agree with everything in your comment except the first line.
I don't think software developer pay follows a power law, or at least not in this dataset. Ignoring equity (which can cause power law type behavior if enough folks strike it rich), the distribution of pay is probably closer to a lognormal distribution. It's just not skewed enough to constitute a power law — that would imply serious skew.
Additionally, this dataset excludes outliers making multiple millions of dollars, so that also reduces the likelihood of a power law-style distribution.
Lastly, this dataset is only U.S. developers, so there isn't skew across meaningfully different geographies.
With a lognormal distribution, your point remains valid, but the effect is not nearly so dramatic.
Yes, because you have to have a proven track record of being damn good, hence too valuable to let go, in order to get the leverage to ask your boss to work remotely full time.
Most of us coding schlubs will still be expected to show up at the office at 9 a.m. sharp. That won't change, barring something like coronavirus.
Most of us coding schlubs will still be expected to show up at the office at 9 a.m. sharp. That won't change, barring something like coronavirus.
The reason I started as a remote employee was that I could get a local internship in college at $15/hr and have to live in the city or live at home and drive further. On the other hand I applied for remote internships that I could do from home and not have increased expenses while making $25/hr.
Ever since then I have occasionally interviewed for in person roles only to be almost depressed by the offers received. You’re telling me you are offering a Senior/Lead position ~72-80k without providing a laptop, paying healthcare premiums and expecting them to commute 5 days a week? Sure maybe I’ve been had above average positions/compensation but I’ve had better benefits as an intern.
Ever since then I have occasionally interviewed for in person roles only to be almost depressed by the offers received. You’re telling me you are offering a Senior/Lead position ~72-80k without providing a laptop, paying healthcare premiums and expecting them to commute 5 days a week? Sure maybe I’ve been had above average positions/compensation but I’ve had better benefits as an intern.
In 2nd / 3rd world countries a developer earns a good salary when they're paid (depending on the country) something like US$1500 per month. If you can charge US$25 per hour remote freelance to US clients instead you're earning 2,5 times as much and then you're still dirt cheap.
Also most employment is in NY or SF, people that work remotely for companies in those cities usually don't say "oh just pay me less because I'm dialing in from Nebraska" unless their CV's are weak.
Working remote means having access to the best paid jobs while the local market is only interesting if you're living in a select group of cities.
Also most employment is in NY or SF, people that work remotely for companies in those cities usually don't say "oh just pay me less because I'm dialing in from Nebraska" unless their CV's are weak.
Working remote means having access to the best paid jobs while the local market is only interesting if you're living in a select group of cities.
> Also most employment is in NY or SF
Is this true?
This article says over 4 million software developers in the US, and less than a million in the entire of California and New York state.
It says there's more employment in Texas than New York.
https://www.daxx.com/blog/development-trends/number-software...
Is this true?
This article says over 4 million software developers in the US, and less than a million in the entire of California and New York state.
It says there's more employment in Texas than New York.
https://www.daxx.com/blog/development-trends/number-software...
The fancy big tech or tech startup jobs might be concentrated in CA and NY, overall jobs aren't. Nearly all companies have developers, so does every region with large companies.
have you considered the actual employment status? A lot of remote workers are employed as freelancers and therefor need to take care of health care / pension themselves with could increase their gross salary
Makes sense to me, in my company we allow for senior developers to be remote but not for junior ones, since they need more hand-holding, so there's a correlation between experience and being remote.
Same at my company. We actively looked for senior developers for this reason.
Who holds their hands if the seniors are remote?
You can certainly hold hands over Skype/zoom/Slack. I don't think there's a physical proximity requirement for hand-holding.
Then why can't the juniors be remote?
Who handholds the junior developers?
[deleted]
It's nice that the article controls for many reasonable variables.
Of course, there could be other confounding factors (like the employer's trust, perhaps location, etc.), but those may be hard to quantify.
I think, it's interesting to think about the reverse. "Developers that earn more are more likely to work from home". I'm curious whether this still holds for the very best payed and very worst payed? There could be other effects kicking in the tails of the distribution?
I think, it's interesting to think about the reverse. "Developers that earn more are more likely to work from home". I'm curious whether this still holds for the very best payed and very worst payed? There could be other effects kicking in the tails of the distribution?
I didn't see an important point that I think is relevant for fully-remote devs and correct me if I'm wrong: On-site benefits. If you work remotely, you can't use several of the benefits a company provides so a difference in the salary is common as a compensation for those.
Same for healthcare plans and taxes. A lot of remote workers have to pay those, which in many cases are completely or partially paid by the company, so a bigger salary is needed.
Same for healthcare plans and taxes. A lot of remote workers have to pay those, which in many cases are completely or partially paid by the company, so a bigger salary is needed.
One of those on-site benefits is a desk.
With a phone, IT access, rental costs for the floorspace, heating, electricity and all the other associated costs that a company can save on by hiring someone remote.
With a phone, IT access, rental costs for the floorspace, heating, electricity and all the other associated costs that a company can save on by hiring someone remote.
Would be interested if there is a company bias being seen here — a lot of the larger tech companies both pay more and, from my experience, are more flexible with working arrangements than traditional big companies.
My intuition is especially piqued by the fact that the author says the initial foray into remote work is where most of the effect is seen. Most of my peers and my experience is that working remotely once a week or so is not at all uncommon.
My intuition is especially piqued by the fact that the author says the initial foray into remote work is where most of the effect is seen. Most of my peers and my experience is that working remotely once a week or so is not at all uncommon.
I had that perception from friends who work remotely, yet, it seems counter intuitive... I would think that if a company is open to fill a position with someone remote than the supply-side is much bigger lowering the bargaining power of someone filling that position.
Plus as others have mentioned, remote-position is seen as a perk so I expected it to put more downward pressure on salary
Plus as others have mentioned, remote-position is seen as a perk so I expected it to put more downward pressure on salary
And that's before taking into account the huge amount of money you save with lower taxes and living costs.
I've occasionally entertained the idea of moving to a big city like London or New York for work. Every time I did the math I realized how little sense it makes. And I don't live in southern Europe, not some third-world country.
I've occasionally entertained the idea of moving to a big city like London or New York for work. Every time I did the math I realized how little sense it makes. And I don't live in southern Europe, not some third-world country.
It's probably not a factor in US, but in many cheaper countries working remotely means working for clients from richer countries which save a lot on hiring from cheaper countries.
So you can split the difference between the pay in your country and in their country and both sides are happy (and developers earn more).
So you can split the difference between the pay in your country and in their country and both sides are happy (and developers earn more).
Has anyone else noticed that jobs that are advertised as remote on sites like weworkremotely pay substantially less than regular on-site jobs?
Whereas if you start a position on-site, do well, gain the trust of the employer and then go remote, then I can believe the argument of the article.
Whereas if you start a position on-site, do well, gain the trust of the employer and then go remote, then I can believe the argument of the article.
I guess that depends what your base line is. While SV is over-represented here, it's only a tiny fraction of the global developer market. The salary of many remote jobs could exceed local levels for the vast majority while being significantly below SV levels.
I didn't see where this might be controlled for, but presumably someone who's a contractor gets paid more because they're dealing with their own benefits, and it's much more common for contractors to work remotely than in-office somewhere.
I was lucky enough to get a great remote job that was happy to pay me as if I lived and worked in SF, but let me live anywhere I wanted to in the country.
Remote devs that have this arrangement definitely take home more money than their peers who live in more expensive zip codes.
Remote devs that have this arrangement definitely take home more money than their peers who live in more expensive zip codes.
There is not one mention of full-time versus contract work. If he didn't control for that, this entire post is totally useless. Contractors charge a premium because they don't get other benefits, like healthcare.
[deleted]
Though I would love for this to be causal, this analysis needs to control for the experience level of the developer. IME, developers who work remotely tend to be more on the experienced end of the spectrum.
> Even once I control for various observable factors (including age, experience, hours worked, size of employer, programming languages, and more)
(Note 'experience')
(Note 'experience')
I would love to be able to confirm this. Unfortunately since moving away from NYC and starting to work remotely I can't even get 1/3 of the salaries they're offering back there.
I wonder if after COVID-19 more companies will realize having remote people is viable and be open to offer more remote positions (I'm looking at you FAANG, unicorns, etc.)
I doubt it. Distributed work forces being successful is more of a top-down way of management than anything.
Also, COVID-19 remote work is not normal remote work. Lots of other stressors and distractions. So the taste might not be a good one.
Also, COVID-19 remote work is not normal remote work. Lots of other stressors and distractions. So the taste might not be a good one.
Title should be changed from 'remote'. Someone who spends two days a month wfh is not remote, yet that's what they count.
With different agreement. Less perks and probably you need to pay for some stuff on your own. To sum it up sometimes they earn less
Employees at my company get paid 20% more, but don't have benefits. Works out about the same.
Practically all entry level developers are non-remote workers. This makes a lot of difference.
Because there are much more senior positions than junior ones in remote space.
No, well paid developers are more likely to allowed to work remotely.
No causation without intervention.