[Yanu-3452]

This is an odd analysis, because as it highlights, salaries are strongly correlated with wealth of the country.

So the question really becomes, not why are salaries different, but "why is programming difficult to offshore".

If programming was easy to import and export then either salaries would even out or, more likely, would be relocated to cheaper countries like many kinds of manufacturing.

But software is difficult to outsource even from one department to another let alone between companies or countries.

If you can solve outsourcing, then you've solved the problem of knowing what you want from software.

But if you've done that, you've just become the software engineer.

[vbtemp]

> why is programming difficult to offshore"

Lack of professionalism and absence of a professional engineering culture in many of the places you'd seek to outsource to save money.

Doesn't mean that professionalism doesn't exist, it's just that the ones that have it are already busy with their own thing and not interested in being low-cost labor

[pydry]

Or they've emigrated in search of those higher salaries already.

I used to work in a relatively "low salary programming culture" and it wasn't just the salary that sucked in that location, the programmers did too. Smart people either emigrated or ventured into a profession that made $$$ (typically real estate, management or finance). Eventually I left too.

[ChuckNorris89]

Out of curiosity if I may ask, in which country did this happen and to which profession did you move after?

[pydry]

Singapore. I'm still a software developer. Just not there.

It's ironic that the country had a serious case of silicon Valley envy and would try literally anything to clone some of that valley magic. They threw a lot of money around in pursuit of this goal.

They'd try anything, that is, other than decent, internationally competitive pay and working conditions.

[sireat]

Curious where did the money go then if it did not go into competitive salaries?

[pydry]

Grants for startups that were relocating from overseas, free office space for tech startups, grants for various kind of tech company masquerading as hot startups and funding for programming courses to train up more programmers.

If you ask a lot of tech founders what they really want the answer is usually going to be free money, free stuff or cheaper programmers. That's what the Singapore government attempted to deliver.

[redis_mlc]

Canada, Japan and Singapore are notorious for just refusing to pay competitive salaries for programmers.

I have a feeling it started off as lack of appreciation for software, then turned into intransigence at raising salaries since then "everybody would want a raise too."

The money goes to other parts of the business.

[JohnBooty]

    Lack of professionalism and absence of a 
    professional engineering culture in many 
    of the places you'd seek to outsource to 
    save money.

I think the "absence of a professional engineering culture in many of the places" results primarily from the nature of contracting itself. I see this in onshore contracting as well.

Contract-based engineering is nearly always a recipe for technical debt.

The team will nearly always focus on today's problems. Not tomorrow's. Because... why should they? They are judged solely on how well they're solving today's problem. And they likely won't be around in three months or three years to reap the true rewards of reduced technical debt anyway.

Contracted engineers also haven't simply been around your business long enough to truly understand it and anticipate what future needs will even exist.

All other things being roughly equal I'll take a full-time, permanent, offshore engineer over an onshore contractor any day of the week.

[vbtemp]

I think you're absolutely correct. The whole model of contracting in general is entirely based around perverse incentives. And all the more so when going offshore for it.

[JohnBooty]

If I can help it, I'll never everrrrrr consult again.

I had one positive consulting relationship. It was a longer-term project. I was the sole consultant and I was able to work closely with my client and explain tradeoffs between short-term deliverables and longer-term technical debt. My client was also instrumental of course and brought a very understanding approach to the table, and was able to understand the technical side of things.

But of course, that is almost never the case. Even with good intentions, that approach never seems to scale up. Not even a little bit.

Some consulting shops do try to bring a similar approach to the table in a scaled-up way. My current employer hired one of the better-known Ruby shops for a long-term engagement.

On the bright side, I would say that the consulting shop did try their best to manage technical debt and bring a good engineering approach. On the flip side, I would say that the end results were decidedly mixed.

[VMisTheWay]

I found it quite difficult to outsource Engineering work to Engineers in another country.

It might be a cultural thing, but issues I've ran into- Slow/low prioritization, no movement unless you follow up often, lack of experience.

Don't get me wrong, I can be lazy too. But when things are outsourced it's really hard to keep positive relations and get stuff done on time with high quality.

[simias]

In my experience the core of the problem, regardless of outsourcing, cultural issues or other considerations, is the good old "if you pay peanuts, you get monkeys". Good software engineers are highly coveted wherever they are. If you attempt to outsource work to a country with much lower wages in order to save money you're not going to get the local rockstars working for you.

Those outsourced teams are also aware of their status as "disposable cheap workforce" and are not super invested in the project. They have very little chance of career growth within the company since their whole reason to be here is to be cheap. They do the bare minimum to meet the objectives and nothing more, and in their place I'd probably do the exact same thing.

[wongarsu]

I've experienced those exact problems with a project that was outsourced to a company 20km away. I'm sure there's lots of success stories, but outsourcing isn't easy even when culture and face-to-face meetings aren't an issue. It's very easy to slip into apathy or an us-vs-them mentality.

[gbasin]

Turns out, the hard part of software is figuring out what to build.

The rest is cheap in comparison, whether done in SF or Bangalore.

[ryanianian]

Yes. And how to build it. I worked with a brilliant but rather lazy contractor once. His code was unmaintainable despite him being obviously competent. His rationale was very explicitly that maintainable code doesn't make for good job-security. You don't want to be held hostage by your own code.

[vsareto]

These guys can be goofballs and only appear competent on the surface. Referrals can be job security as well, and you won't get referrals if you intentionally write bad code.

In other cases, it's skilled people that just don't want to apply 100% effort and are just coasting, maybe for external reasons (some folks can write decent code without 100% effort in the moment due to practice beforehand).

[onemoresoop]

> You don't want to be held hostage by your own code.

If your code is unmaintainable you become hostage to your own code because making changes breaks things, causes frustration, etc

I totally get the idea of job security if you’re maintaining a codebase that only you understand but that is very likely to bite you back quite badly, especially if you’re a contractor: you may not get any new work, the code you write is very visible and can be judged quite quickly by a qualified person

[JohnBooty]

Yeah.

There are obviously times when you can truly "write yourself out of a job." That truly happens.

I think that there are far more times where a transparent and earnest approach to managing technical debt and keeping things maintainable for your clients leads to more work in the long run. Possibly even permanent employment if that's what's desired.

(Of course, this depends entirely upon your communication skills and the client's savvy and receptiveness to such an approach)

Because the usual reality is that any client who needs consulting work in the first place is certainly going to need more of it in the future - maintenance, iterations, new projects, etc.

[JohnBooty]

I think the hard parts are:

1. figuring out what to build

2. for non-trivial/long-lived projects, figuring out how to build it in a way that makes scaling, iteration, and maintenance something other than a total nightmare. (of course, many projects are one-off projects that don't need to be engineered for the long haul)

[bagacrap]

(Product) managers decide what to build. Engineers decide how to build it. You make it sound as if software engineering has no value. Clearly this isn't true as small local banks will have awful sites and apps despite the problem statement being pretty clear cut. The most successful tech companies also happen to be the ones that have attracted the top engineering talent. Generally, ime, an engineer you pay $150k is worth more than two engineers at $75k.

[dgellow]

> Product) managers decide what to build. Engineers decide how to build it.

That’s not how software is done though.

Product managers are in a constant negotiation with engineers to decide what to do. There is a lot of back and forth and exchanges to arrive to a set of stuff that can then be built.

That’s what the agile routine is about.

[constantine42]

The company I work for has an interesting setup. Marketing drives what products we need via marketing research, Product Owners(PO) represent those products and further research the problem space, Product Managers(PM) are coupled with an engineering team and the PM negotiates with the team around estimations, priorities, and planning. But ultimately the team decides what it does, but they are held accountable for delivering business value.

As a team, we can't just go all vigilante, but we can push back and have at times gone over other people's heads to make sure the proper people understood the problem. Most of the time we got what we thought was best for the customer by going over people's heads, but there's been plenty of times that a middle ground was reached.

The main thing is to not just say "we can't". Our job is to deliver solutions, not products. If there is a problem with priorities, we find an acceptable way to make things "work". Maybe that's adjusting timelines, or features, or just asking the customer how important that timeline is to them. I can't tell you how many times I've been told about "deadlines" that the customer never actually said was a deadline.

Us: Yo cust, can we slide that project 2-4 weeks?

Them: Sure. Heck, move it back 2 months if you want, but we absolutely need to start testing on our end in 3 months.

[redisman]

I wish there was analysis on the number/size/market cap of software companies per country. That seems like a fairly likely driver of higher salaries because of increased competition

[seibelj]

If you can buy a finished product that is reliable, it doesn’t matter where it was made. But if you are trying to build the reliable product, it’s like telling a custom house builder how to precisely build your house, but you are never able to physically go to the job site. And that job site is in a foreign country, but you want it built in your local style that is unfamiliar to the builders. It can be done - and effectively - it’s just a lot more difficult.