> Being smart and being thought how to be a programmer seems to be the main prerequisite of being a good programmer.
I assume that's a typo for "taught" but maybe it's one of those Freudian slips. I'd say being at least medium-clever and being thought of as a programmer is the prerequisite for getting paid loads of money as a "good" programmer.
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.
(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.
> 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.
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.
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.
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).
> 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
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.
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)
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.
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.
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.
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.
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
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.
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.
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."
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.
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.
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.
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.
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
Yeah, I was expecting this to be about untapped market opportunities; i.e. software is eating the world, but not fast enough, and there is a lot of money to be made in applying software to various industries.
“ Doctors in the US and UK are very expensive, that's not because nobody has noticed there are equally skilled doctors in other countries that charge 1/5th the price (or even algorithms that can do most of it for pennies). It's because practicing medicine in those countries requires to go through a regulatory gauntlet that would make Kafka feel like an unimaginative fraud.”
Ouch. Yeah some US/UK doctors are overpaid but the liability is not addressed. Also not sure what algorithms they are referring to. I don’t know any even in radiology/pathology that can rival a physician.
From my friends who work with outsourced programmers, this is also an issue in the coding world right? Who’s held responsible if something is not working or delivered?
A lot of people like to point to regulations and licensing as a source of inefficiency, but in reality the lack of any sort of professional licensing around programming drives all sorts of alternate inefficiency: with no objective standard to measure applicants against, employers are stuck trying to make up their own, usually broken standards.
The lack of violently enforced standards doesn’t mean there are “no objective standards”, nor does violently enforcing a standard like they do in medicine make it an objective standard (see: how careless and dogmatic your typical MD is)
Agreed. For better or for worse there is a "standard of care" that is a solid legal basis for lawsuits and a lot of decision making stems from it. "It's what's in the textbooks and established, and I can't be sued for doing it."
But the flip side, using newer research, may fix incorrect/suboptimal diagnosis or treatment, but can also fail.
I'm of course sidestepping the "I'm an MD and am right, and you're a layperson and don't know medicine" mentality, but to be fair, there are fewer of these in the newer generation of MD/DO/healthcare providers.
Most people cite liability as the main reason but I also haven't seen any algorithm that reads chest radiographs better than radiologists. To be fair, rads look at images, correlate with the patient chart and symptoms, and that info is not provided to the algorithms. But also, humans need only one or two examples of a weird diagnosis to find it again and that still can't be tackled by one-shot/few shot learning algorithms (yet!).
I don't know enough about A.I or radiology but if A.I can drive cars or make investment decisions better than humans I can't see why something as technical as reading photos and recognising patterns can't be done by A.I.
Good luck with your research!
The largest system in the human brain is the one responsible for vision. There's a scary amount of computational power involved in a human completing simple-seeming visual tasks, and that's not always easy to reproduce with computer models.
Great! Then you're the ideal person to ask something I've been wondering: We see the occasional headline about machine learning algorithms outperforming human radiologists. What's the catch? I'm prepared to believe they aren't really outperforming humans once you take all the unstated factors into account, just wondering what the unstated factors are.
Really interesting article! I agree with the thesis 'wage gap with skill + tax irregularities + immigration = gap' but wonder if more remote working will impact this.
I think a large driver is hyothesis 3: in low income countries lots of people become programmers not because they like programming but to get away and/or earn lots of money.
The reason this doesn't show up in the data is that hypothesis 3 assumes that people want to do remote work from their country. What I actually observe is lots of programmers from the Middle East and Asia coming to Germany, the US and probably other high income countries. Obviously emigration is easier for more capable programmers, lowering the average skill of those left behind.
It seems to be missing a very big factor: culture.
If your goal is to implement some code for, say, healthcare, it is a lot easier to explain the business process to someone who is already familiar with how stuff is done on a higher level. Whenever you hire someone from a different culture / country, you need to start from the basics by explaining the very core of your society.
An American programmer might not be too concerned if a body temperature measurement returns 45 degrees Celcius. Similarly, a patient height of 95in probably wouldn't immediately raise alarm bells for a European developer.
Your offshore developer team might be perfectly capable of writing the code once they understand what to write, but getting them to understand it is a hell of a lot more difficult.
Add to that the possibility that English is the second language for both sides, and things get messy pretty quickly. Not to mention a time zone difference making communication even harder.
Another aspect of culture: how one-sided the communication is.
Silicon Valley and Scandinavian cultures are very flat, so it is possible for "the man on the floor" to tell management that it doesn't work to put diesel into a gasoline car.
In authoritarian cultures this would be a mistake as it's seen as embarrassing the management by saying they made a mistake. If you want to continue being employed then it is much better to pretend there is no problem.
Catching problems early saves a lot of money in software development, so a non-authoritarian culture can save a lot of time and thus have a lot higher wage.
An authoritarian culture, however, can get work done much quicker while staying with a razor-sharp focus. The whole "democratic" decision-making process takes time and leads to a sequence of decisions spread throughout the time domain, which, taken together, might lead to a suboptimal result compared to what might be achieved by following the steps of an "enlightened benevolent dictator".
I disagree, China seems to fit right into the pattern.
Mao became undisputed leader. His purges were bad enough that the party decided to implement a 10 year term limit.
Xi removed that limit, and now China is swinging slowly towards authoritarianism. We're still in the early years of his rule at this point. Wait till he makes a mistake and his grip starts slipping, then he will see enemies everywhere.
When someone makes themselves ruler for life, it tells you that their character is not suitable for that position, because they lack the humility to hand over their work to a successor. Because they've decided they can't trust other people's motives and competence.
While this is certainly true, I've felt for a long time that the Peter principle is missing something very important:
"Doing the work," "managing the people doing the work," and "making the decisions about what work should be done" are not simply three ascending levels of expertise in one domain. They are three completely different domains. All good so far; the Peter principle takes this into account. Someone who's good at "doing" gets promoted to "managing", and doesn't have that skillset, and gets stuck there.
But it's also true in reverse. Just because a particular person is not good (or, more generally, less good than the best) at "doing", that doesn't mean they'd be bad at "managing". And just because someone is not good at "managing" doesn't mean they'd be bad at "deciding".
So you've got people who are good at working being promoted to manager, people who are good at working and managing being promoted to decider (which, I admit, is a bit more likely to work out than the others)—or, in many cases, people who were simply hired as managers being promoted to deciders—and then people who are good at managing or deciding, but only OK at working stuck at the worker level forever, unable to use their skills to help make things better.
There is certainly a reason many cultures gravitate towards authoritarianism, focus is an important quality of productive teams and authoritarianism increases focus.
However, too much focus relative to the complexity of the task at hand is never good, because focus requires ignoring some things. I would theorize that the more complex the task a team is working on, the less authoritarian it can afford its culture to be.
I have experience as a programmer in both worlds, and there are certainly pros and cons with each culture.
In an Eastern-European "authoritarian" (Bulgarian) setting, you are given tasks with not much room for interpretation and are expected to deliver a tangible "no-bullshit" result within a reasonable time frame. Not much time is spent on meetings, you don't want to ask too many questions, praise is won by delivering a technically-efficient solution which doesn't question the business intents and preconceptions of management.
In a North-Western European setting, everything is questionable and debatable, sometimes at irritating levels. Fairly incompetent people are raising their voice on insignificant matters and the decision-making debate changes direction quite sporadically. By everyone focusing too much on the business side, what you get is a technically-mediocre product which solves many problems to many people, but doesn't have much value as an integral part.
"An authoritarian culture, however, can get work done much quicker while staying with a razor-sharp focus."
Disagree. A team can be coached to commit to a common goal.
A dysfunctional authoritarian culture is probably faster than a dysfunctional democracy, for sure. But then you are comparing which broken system is less broken, not what would be the optimal setup.
Take a sports team. They are not micromanaged. They are given a common task, a common strategy, guidance, but in the field they are alone.
> Take a sports team. They are not micromanaged. They are given a common task, a common strategy, guidance, but in the field they are alone.
They are more and more micromanaged.
* Training has become the land of measuring and controlling each detail, and has expanded into controlling your whole life as much as possible.
* Before the game, with more and more accurate and often static tactics. Don't you act another way or it means disobeying and the bench is near.
* During the game. Hardly 15 seconds go by without the coach (or the coaches) yelling orders at 1 or 2 players. Now there are even real-time data collecting and analyses, sometimes from sensors.
Perhaps the worst example of micro-management is cycling, where I am pretty sure that the only directeur sportif's dream not yet fulfilled is to be able to radio-command electrodes implanted in riders' muscles. They already get the position of almost everybody in the pack in almost real-time, they get radio-communicated real-time speed, power, heartbeat sensors measurements and two-way audio communication with each rider of the team. For now they have to do with giving imperative orders through each rider's earpiece (so the reaction can be delayed or the order not quite obeyed), otherwise managers would be computer game players. And silly (sometimes collective) punishments for those who dared disobey when they felt the orders were stupid are not uncommon: even though it means losing chances on that day or the next, the manager has one priority: showing who the boss is.
> An authoritarian culture, however, can get work done much quicker while staying with a razor-sharp focus
Only for relatively simple situations with a relatively known process for solving - which is the opposite of most software dev, although that seems to be changing in some ways.
"An authoritarian culture, however, can get work done much quicker while staying with a razor-sharp focus."
Only in the extreme short term. In the medium term, the dictator inevitably ends up severed from reality by the inability of (true) data to flow back up to the authority, which results in their decisions becoming increasingly suboptimal over time.
This is the pragmatic argument in favor of free speech, really. If for the sake of argument we ignore moral and philosophical issues, the reason why free speech is important is that in its absence information does not properly flow back up to the authorities. Free information flow does not guarantee proper functioning of the system, but impeded information flow guarantees improper functioning. If your authority dictates the use of 4-inch long bolts in a place where there's only 2 inches of clearance, and nobody in the organization has the ability to feed back to the authority that information, the only possible outcomes are bad ones. This all compounds, too; the next dictate from the authority won't be able to take into account the fact that in order to fit the 4-inch bolt in, a new hole was cut in some vital structure that shouldn't be there, and some new bad decision will be made to add load to this structure, which will cause other effects. The authority ends up living in a fantasy land.
Note how this toy example seated entirely in engineering-space doesn't have any moral or philosophical component, and yet it is already sufficient to cause a bad outcome even in pure engineering terms. Moral and philosophical issues can cause yet more problems, but they'll be arriving to a space already broken.
It also doesn't matter for my purposes why the information can't flow back up to the authority. Even a well-meaning, "enlightened" dictator can end up in this situation by sheer inability to process the incoming information. The dictator may be the nicest, most well-meaning person in human history full of compassion and love and every other virtue you care to name, and they'll still break things if they insist on authoritarianism.
> In the medium term, the dictator inevitably ends up severed from reality by the inability of (true) data to flow back up to the authority, which results in their decisions becoming increasingly suboptimal over time.
You're conflating the "do what they say" aspect of authority with the "drive them off a cliff without saying anything, when they tell you to drive forwards" aspect of authoritarianism. Too many times have I heard people say, "yes we know this isn't what he wants, and yes, we know that he would change his orders if we provided him with the information only we have, but he told us to do this and nobody will be able to blame us for the resulting fallout."
Only certain types of work and usually very mundane work can be done with authoritarian culture. Note that creative people do not enjoy working in an authoritarian regime. Universities are an example of an anti authoritarian organization where creativity often flourishes.
Another aspect of culture: how one-sided the
communication is.
Yes, absolutely this! I worked at a company where the engineering culture was IMO very dysfunctional.
We had a lot of fulltime employees working in other countries. The company paid pretty well, and we were essentially paying US salaries to folks living in countries where that would be considered very, very good money.
This, combined with the cultural issues you mentioned, resulted in management mistakenly thinking it was doing a good job -- privately, the foreign engineers shared my concerns, but they were not willing to "rock the boat" and bring those concerns to leadership.
From an European perspective, this has not exactly been my experience working with an international team.
The US collective mentality is sometime overly optimistic specially in public. This is sometimes a positive since it removes almost any inhibition regarding challenges, but it can lead to things blowing-up spectacularly, and then having to put in place hacks and brute force to make it kind of work relatively inefficiently and inelegantly.
But it also leads to great successes (biggest economy in the world, lots of major companies, very attractive country for talents) and innovations never seen before.
This positivism is prevalent in public statement but in private cracks start to appear. It gives me the impression that this positivism is pretty much a cultural obligation, so while not authoritarian, the group mentality is geared toward not talking to much about possible difficulties out of fear of being seen as too negative by the group.
In my experience Americans are pretty blunt, and will not hesitate to point out flaws and make cynical jokes about them openly in the presence of their team.
Cynical or sarcastic jokes are arguably the opposite of blunt. They're a way to acknowledge or broach a subject which the person, and most often the group, is uncomfortable or incapable of articulating more clearly. For example, because they're being forced to do the impossible, or because the character, cause, or resolution of an issue is poorly understood.
People from cultures where sarcasm isn't common don't understand this nuance and seem to find this kind of dialogue abrasive and unconstructive. Perhaps the sentiment is that if you can't articulate it clearly, then the issue is non-existent, for better or worse, or you're just being lazy and unhelpful.
I think cynical and sarcastic jokes are blunt, and are something that arises when the culture is open about discussing problems but people don't have the agency to solve them.
As I have discovered direction and attitude make a huge difference in the understanding and comfort of sarcasm to persons with no familiarity of the concept. If the target of the sarcasm is a third party the communication comes out clearly absurd but both the speaker and listener can understand and appreciate the absurdity together, which is less confusing. If the direction of the sarcasm is something about the listener it can come out as a clever rhetorical hostility that takes getting used to. If the sarcasm is approached with an uplifting tone and positive body language it is much more likely to be take as a joke even if the content of the communication doesn’t immediately parse as a joke and even though the content may be completely disparaging.
What also helps, counter intuitively, is providing multiple sarcastic statements in quick succession. People listen to spoken words at set rate but the nonverbal parts of communication are instantly clear. This allows the listener the opportunity to consider the extended thought in a single context allowing for a richer sample of sarcastic communication to think over.
Sarcasm + empathy for those around you dealing with the problem = powerful form of communication.
Sarcasm + being an asshole = being an asshole.
(Note: This is from my Australian background/culture/point-of-view, and I don't for a moment think it applies cross culturally - we are the culture where calling someone a cunt can be either a sign of deep profound friendship, or a reason to be punched in the face. When in the US, I need to be careful with that sort of instinctive interaction/language...)
It must be said that there has been a counter-culture that has been militant in trying to get rid of this. They're enforcing speach codes via code of conducts. (I.e. look at some of the recent examples including Linus Torvald (and the number of people who piled on), donglegate guys, etc)
To be fair, Linus has admitted to and shown himself capable of being an asshole, and the donglegate guys are people I would not want working with my sister.
You can be cynical and sarcastic without being personally abusive or a sexist troglodyte.
The "militant counter culture" you speak of definitely does exist. But codes of conduct didn't start appearing out of thin air, they exist because they need to exist. Anyone who doesn't recognise that is almost certainly coming from a place of oblivious privilege. (Hell, I admit to being obliviously privileged a lot of the time, and _I_ can see the very real need for codes of conduct to exist so that assholes and troglodytes can't continue saying "It's a joke, calm down", or "I'm just being blunt, you can't handle the truth" or all the other gaslighting bullshit they so often get away with...)
Your sister can't handle nsfw language? I don't think that should be endorsed in the work place. (That was at a conference function between 2 people).
They exist because projects have been bullied into doing that. On top of that the conditions were pushed in. Do you really need to have a thing to say "don't deadname"?
Expectations of conduct have, and continued to, existe(d) before that and they were enforced. The only thing this does is to try to give people who don't like how a group is run room to bully the people running it.
Can confirm this is a problematic aspect of our culture. I'm one of the people who's entire professional niche is being the counterweight to this positivism. Endemic to the way things are done is the understanding that forgiveness is often easier to attain than permission, and unfortunately putting your foot down and holding otherwise is rather frowned upon, or at least gets you marked as needing to be handled delicately. This leads to, if left unchecked, potential efforts to perception manage away obstacles to keep awareness of the problem suppressed such that it never gets dealt with until the inevitable blowing up down the road with the hope things have progressed far enough, sunk cost will keep you going forward.
It is an infuriating challenge to deal with, especially when you're faced withacompletely passivebusiness interface only committed to answering exactly the question you ask, not taking the question and doing the bit of contextual fill-in and translation one would expect. As a result, to cope with that, you have to ask heavily qualified, context bearing questions to Get to the bottom of anything; which after a certain point becomes unintelligible if you don't have someone actively willing to follow along, which manydon'tsee the value of, because they don't see it as doing anything of value.
I've spent my entire career being told that pointing out problems doesn't help the situation, having these problems blow up and having the same people say they wish they had listened... and being told that pointing out problems doesn't help the situation.
I had a real heart-to-heart with the CTO where I worked since he only gets along with one of the managers and doesn't like his directors. He said the only reason he approved my promotion was because he was tired of hearing Yes Men telling him things were fine right until they blew up in his face. He's a tech guy, not a business guy so probably outside the norm.
That's the first step. Proposing a complete solution that takes in the needs of the various stakeholders and doesn't just move the problem and does so in a way that makes the whole situation easier is the hard part.
If you've done that and nobody is listening, it's time to change the culture or leave.
> Proposing a complete solution that takes in the needs of the various stakeholders and doesn't just move the problem and does so in a way that makes the whole situation easier
There's a fine line between being thorough, and doing the job of several other people for them. The latter isn't what you're being paid for, and in some companies isn't appreciated if it risks some of them losing face.
True, but on the other hand it is unpleasant to have a problem, be fully aware of the problem, and have every passerby point it out to you as if you are a team of idiots who can't see the obvious.
The hard truth is that (1) people are not stupid and are usually keenly aware of the issues but (2a) many are just warming seats and don't care or (2b) lost the will to fight the company's culture but are unwilling to leave the cosy job.
I used to work for an American semi-conductor company that no longer exists in its original form in (at that time) MCUs. MCUs are essentially CPUs with an internal bus, and some modules (PWM, A/D converter, math co-processor, what not) and that bus connects to the outside (often at a different speed) where it connects to various RAM and serial and/or parallel devices and analog innies or outies.
The systems engineer (who was a friend, but maybe not the smartest tool in the shed) spec'd a system, and (high level verilog) simulated the system, and gave the output to the circuit guys (led by (also a friend) one of the most talented mixed-signal circuit designers I know - but abrasive as hell), said: "It won't work. Too much power draw on on modules off the bus. And besided is you power them through the bus, you're going to get a lot of noise and chop and brown-outs".
The manager - who was not an idiot - but to your point (1) above, was NOT aware of the issue and didn't want to believe it was issue and was NOT keenly aware of the issue (he was in denial), so they ran the wafers.
Chips come back - they don't work. Power draw issues.
My circuit designer friend (remember the abrasive part?) - gloated and mocked them for being idiots that did not know how to listen. (He was right - but he didn't have many friends in management).
They said: "OK. Make the changes. We'll do another run.". He said: Give me a couple of die. He went back to the lab - laser snipped a couple of traces - and voila! It now worked! (He had designed in a way to solve the problem as if they had originally decided to do it his way)
He cut 3 months off the schedule - saved millions of dollars - but were mad as hell. I think they wanted to fire him.
I learned a couple of things from all of that:
- Sometimes smart people don't know about problems because they don't want to know
- Pride is a horrible sin - I would have been grateful to have my bacon saved - they were not
- Nobody ever gets a bonus or promotion for putting out a fire that never actually gets started.
- Being excellent becomes a baseline expectation if you do it long enough so it's best you never put out your best possible work in the office?
Pretty interesting story, thank you for it! Seriously though, my main takeaway is that you can be a genius and not an ass -- at the same time. But in your particular example the guy was completely in his right to mock them.
And sadly yes, pride overrides a lot of other, supposedly much more important, factors. Learned that over my career as well and it's not one of the lessons that I enjoyed receiving.
Business culture in the US is also quite authoritarian. There have been decades of strategic peeling away of labor rights to put labor in a more leveraged situation, leading to restricted freedoms. Sure, you can tell your manager/director/CIO/CTO their choice is idiotic but the fact is, you'll be fired instantly and depending on circumstances, you may be in a bad situation financially and future career wise. The very hierarchical structure is authoritarian with layers of authority built in.
Most people are very hesitant about giving honest feedback even in US businesses because of these pressuring forces. If your manager wants to put diesel in a gasoline car, you often have to agree, then have a sidebar conversation directly with that person so their negligence, ignorant mistake, or intentional malice isn't put on a large group or public display.
Very few US workers are in positions to give blunt feedback. This was pretty common in software development due to leverage developers had but it's, IMHO, been on decline.
>> you often have to agree, then have a sidebar conversation directly with that person so their negligence, ignorant mistake, or intentional malice isn't put on a large group or public display.
That should be obvious. Most people I've worked for can be challenged in private if you've actually got a point - even if you're shot down in the end. The ones who are still assholes when handled correctly are usually not worth working for. The best ones can handle a public challenge on the merits of course.
That's exactly what different cultures look like: it's absolutely not obvious in Eastern Europe where I live. We call each other out on our BS freely and directly, and almost nobody ever gets offended.
It is quite the cultural shock for many of us when we suddenly have to sugar-coat and positive-tone-first every work criticism we express. It can feel like a huge waste of time and energy while if somebody tells me "Dimi, your code in module X sucks!" and I'll just laugh and say "dude, I had only a day to finish that, sorry -- if you don't like it, talk to the boss to give me one more week on it and it's going to be swell".
So no, such things as the one you quoted aren't obvious at all for many. I'd even argue they are only prevalent in the USA but I've seen evidence in both directions so I can't claim anything absolute there.
Man I wish it was more like that in the west, it's great to not glorify people being assholes, but when coworker X pushes a security fix on all production servers at the same time on a Friday afternoon, crashes the entire thing and somehow my manager talks about "the importance to avoid fingerpointing" in the post-mortem.
What I've heard VPs of Engineering and team leads saying to justify this over-protectiveness when screwing up was along the lines of:
"He/she knows they screwed up. No need to pour salt on the wound."
Which is completely fair. But I've also seen fairly clueless people in responsible positions screwing up again and again and again and never being called out -- and those scenarios are not okay.
> my manager talks about "the importance to avoid fingerpointing" in the post-mortem.
I sometime am, and will continue to be that guy.
At least partly because it's the right way to handle post mortems, but partly because coworker X is only a symptom of the problem - and the underlying problem here is a manager who hasn't got a process in place to ensure Friday afternoon rush fixes on production don't happen. That's a process problem which is neither your nor coworker X's fault. That's my fault. Sorry...
(And maybe coworker X is a serial offender for this type of fuckup. Also my fault.)
> That's a process problem which is neither your nor coworker X's fault. That's my fault. Sorry...
I wouldn't rush to blame you if you were my manager. It's not the manager's job to breathe down everyone's neck -- they have to make sure to foster the right culture (like don't push potentially breaking changes to production at Friday afternoon) and ensure that the people hired are actually able and motivated.
From then on though, all bets should be off. Maybe the guy/girl had an awful day and is otherwise excellent. Maybe they felt pressured due to miscommunication (or a coworker being an ass and they took it personally and figured they'll speed through the task), or maybe they simply were novice in that particular problem or technology.
It puzzles me whenever a thread like this comes up on HN, how I either always had reasonable managers or people are exaggerating a lot.
When something is obviously not going to work akin to diesel in a gas car, I have never met someone who wasn't willing to at least take a second look at their "solution".
On the other hand, Japanese or Korean boss would not spit some random bullshit, because he/she would emabarass themselves and will have to leave. Never happens with an American boss.
> On the other hand, Japanese or Korean boss would not spit some random bullshit, because he/she would emabarass themselves and will have to leave.
Then you have limited experience with Japanese bosses.
Under most circumstances, they simply avoid trying to commit to ANYTHING. They will never give you a definite yes or no and will move glacially slowly.
However, when driven to against a wall in which they must make a decision, it is fairly common that they can, and will, spew some of the most jaw-droppingly stupid things, and nobody will ever contradict them--certainly not publicly.
Yes, when things go really bad, they will have to apologize and fall on their sword. However, the failure has to reach epic proportions before that will happen--normally they just shovel the blame onto subordinates exactly like US bosses.
I agree. I worked in some American companies (in US) and did not like the oppressive environment. Now I am back in Central Asia, where I was born, and the employers are way more relaxed here.
As a part time military officer (extreme authoritarian culture) and a corporate software guy (no interpersonal structures to be heard of) I find that this is a common assumption but it’s actually quite wrong.
First a little background:
The military is a highly confrontational culture, which isn’t necessarily a bad thing. In that kind of culture you tell people the disagreement immediately without tripping over pleasantries. It also means people are not easily offended until you try to waste their time or bullshit them with cleverness.
In the military people have to certify to do anything (super bureaucratic) so you generally know who your actual experts are without guessing and without a bunch of lying Dunning-Kruger insanity. It also means people are generally better about knowing their limitations and staying in their lane.
That being said, in the military I have no trouble or reservations about telling a superior they are wrong and why when it comes to an area I am well qualified. Knowing that the superior can immediately reconsider before making the authoritarian decisions of an iron fisted dictator. Superiors are generally better about considering the advise of their experts because the decision maker owns all risks and consequences.
In the corporate world you have to employ tact and really be careful how you deliver the message if the topic is not something already extremely objective. There is a lot of noise in the corporate world and far less interpersonal structure leaving everything open to interpretation. I find when I am at the day job communicating anything comprising more than two steps I go far beyond normal to be precise in my wording just to be clear.
There also exists a common phrase being thrown under the bus or more commonly known as a scapegoat. This does exist in the military but there are many conventions in place to catch those kinds of failures. Once that is identified it is a major reputation destroyer, which results in a huge occupational risk. It seems to more commonly apply in the corporate world when people are pushed into a corner and risks associated with that behavior are minor.
In most of my corporate employers there generally isn’t a central authority that owns any significant business risk or job terminating consequence when things go sideways (except maybe some senior management), which is certainly different from an authoritarian culture. In the corporate world there is plenty of room to blame external factors when things fall apart.
> Superiors are generally better about considering the advise of their experts because the decision maker owns all risks and consequences.
Even though it still does not literally happen anymore, there is still the tradition of the captain going down with the ship. The captain's authority was unchallenged on board the ship. But, if the ship sank, the captain paid for it with his life. This would inherently cut a lot of the bullshit. If you are the captain, your life depends on your people telling you the facts, not just what you want to hear.
What does literally happen still in the US Navy, I heard, is that if a warship sinks, the ship's commanding officer's Naval career is over even if everyone involved knows that the sinking was not actually the officer's fault.
I think this is a massive problem, and it produces just bizarre situations. Flat cultures produce weird side effects (you can have a stalemate that shouldn't exist) but extreme-status-hierarchy cultures just produce an entirely different level of crazy.
Years ago (not my current employer), there was a big offshore team that was a huge pain in the neck because their entire development culture was one of deception and defensiveness - they'd deliver garbage but then spend enormous amounts of energy managing up and propagandizing to their reporting chain and executives that everything was finished, high-quality, etc.
One of the security teams practically begged for someone to help get this team to fix the bugs they were filing. The other team was straight up closing pretty much anything they could as "incorrect" reports or classifying all the bugs as ultra-low severity (which is basically "will not fix") so that their metrics stayed perfect. Lots of issues like this. When they were challenged on it from the outside, by one of the guys who didn't have a sense for the political situation, the best way to describe the reaction goes way beyond "circling the wagons" - they went full nuclear, politically, on that guy. No holds barred, a total nest of vipers. For engineers who have never experienced companies with deep and vicious politics, it's hard for them to understand what it's like at companies like that.
Then one day, one of the best executives at the top of the chain decided that he was going to re-organize his directs and fold these teams together, under someone from the side of the house into which the security team reported.
Now, cultures of managing up are good at reading the waters and so you'd expect that they'd change their tune anyway, and they did, but the part that was shocking to all involved is, as a side effect of the exec shuffle, the security guy above was given an important-sounding but meaningless title, and suddenly the interactions between that organization and the security guy went from a one of subversion, political smearing, etc. to one of absolute and total deference overnight.
The offshore team wasn't any _better_, they were still marginal and you couldn't trust a single thing they said, but the instant attitude change from "defiant, we-are-power-adjacent, you'd better watch yourself" to "oh XXX, we're helpless, nothing can be done, yes we will try but.." due to what was essentially the change of a string in a database somewhere was just crazy to observe. Everything went from "that guy is terrible, that guy doesn't know, blah blah' to "yes, oh, XXX is great, we love XXX, he is helping, ..."
It's ironic that as someone from a similar "shy" culture, I do not dare to tell my manager that our outsourced programmers in a low-cost country sometimes don't write a single line of code in a day, and one of them is not even familiar with programming beyond a "hello world".
This remind me of the recent Microsoft AI that can write code demo.
You give the AI instruction and explanation in English, preferably as clear and as detailed as possible and you get back code.
Essentially its very similar workflow when working with offshore developer, in the future you could in theory replace the offshore dev with AI, except with much less latency.
The issues we have with any code development; whether through on-site employees, offsite employees, contract shops, or integrated contractors, would also apply to AI.
Those of us that have been doing it a while, know that the single biggest issue in any commercial code project is bad input to the process; otherwise known as Requirements. No one knows what they want, or, even worse, they know what they want, and what they want, sucks.
Steve McConnell wrote about how projects mess up, and how much the damage can propagate throughout a project lifecycle; with bad requirements being the nightmare scenario. This was about a quarter century ago. It is not new (https://stevemcconnell.com/articles/software-quality-at-top-...).
The best requirements for a software project is code. Even an AI will need extremely high-quality, detailed, and well-considered requirements that are likely to require their own language (so AI requirement-generation will look a heck of a lot like "coding").
What AI gives us, is (maybe) speed between requirements and executable, so, theoretically, we could have a really high-power, effective iterative process, where bad input results in bad output, and we see that quickly, then refine the input; much like we already do with code, and run the build again, to see how that results in executable.
I learned development back in the "big iron" days, where CPU time was the most expensive part of the process, and we were required to debug our code in the design phase. If we borked during our slice, we were penalized.
Nowadays, I tend to just write some junky "strawman" code, fire up the debugger, and step through until it breaks.
Working with separate contractors, whether domestic or offshore, needs really good requirements, and some kind of fast feedback and a flexible, iterative lifecycle process; which is frog-fur rare.
If we don't have a fast feedback cycle, then we can't iterate effectively. In-office staff helps to make feedback fast, but it's quite possible to have fast feedback in a distributed environment (I used to work for a Japanese corporation, so I can tell you about "feedback lag"). It's just that we then need some kind of process to afford and regulate that feedback loop.
I think that the process of software development is fundamentally broken, and that the industry is still thrashing around, trying out all sorts of "silver bullets" (See Brooks, Fred).
Unfortunately, if we want to reduce "tribal knowledge," and treat our engineers like interchangeable LEGO blocks, then we need a pretty heavy process. It's still a heavy process, even if we call it "agile."
"Tribal knowledge" is a bad term in the software development industry, but it is the most effective way to have a light-touch process.
It also requires treating engineers well (not just paying them well), so they stay around. I'm not sure that foozball tables and on-site beer are doing the trick, as the average stay at a corporation seems to be less than 2 years.
I do not have the answer. If I did, I would own a private jet for every day of the week. I have my own personal process that works quite well for me, but I don't think it scales particularly well to others.
It's amazing how we have, and used to have, all this great knowledge about process and methodology. (McConnell and Brooks) but yet the industry would rather throw their hands up and micromanage projects into the ground. (Agile).
The books that are published feel like they're targeting entry developers and it's a lot of stuff you'd learn on the job. It feels like we're over-promoting way too quickly and demanding delivery over experience or quality.
Interviews: You have developers that refused to learn this skill and they just skim a few leetcode problems and expect the interviewee to solve it in 15 minutes.
Best practices: What happened to developing standards and demanding/expecting tests (and their appropriate categories unit, integeration, smoke, feature/functional, etc)
I'd argue that "precise and clear enough description" means using a subset of English that's more complicated and much, much more verbose than python.
Have you read laws? That is the style of language that tries to make a "precise and clear enough description" in English, but it does not go far enough, it's still not sufficiently precise to be applied directly, you would have to use something like 'super-legalese' for that.
So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English, and easier to do so in Python or some other programming language; and in any case, the difficult part of programming is thinking up the precise and clear enough descriptions.
This comes up in writing specifications for outsourced programmers. Writing a specification in English that's clear and actually precise enough takes more work than
just writing the code directly - since you have to do all the hard part anyway, and then have to express it in a language that's poorly suited to do so. And a reasonable specification is very much not precise enough to be executed, it relies on the programmer putting in a lot of the details based on their domain understanding and common sense, leading to very different implementations as that domain understanding and common sense varies.
>So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English
Yes but in the future this can be solved by the smarter AI.
Essentially that what a lot of developer do, they turn other people idea or english description into working code.
We had a similar technology for a long time. You give the computer instructions and explanation in a language, as clear as detailed as possible and you get back machine code.
This has been my experience over my career. Developers tend to forget they're ultimately developing tools for humans. Very few care about the underlying technology, complexity, how clean your code is... they just want something they can use to reach a goal reliably, with manageable complexity, and at reasonable cost.
Once you really understand that, you'll understand why it's difficult for those in other cultures, using other primary languages, and sometimes even remote employees to develop effective software without difficulty.
Much of software development assumes that specifications are perfectly understood, translated, and captured. This is rarely if ever the case. Developers are very frequently inferring and making microdecisions within the context of what they're developing using their personal knowledge. When they don't do this, you often get products that just don't solve the target problem.
One factor businesses really shot themselves in the foot when they butchered agile into a micromanagement time pressuring system to squeeze work out is that it made localized workers even more of a necessity because it has to be done (and interpreted) fairly quickly. This, IMHO, puts remote workers, especially those in other cultures, at a huge disadvantage as well as the systems/tools they're developing.
I don't doubt for a second talent can be distributed world wide but I do doubt that there's enough talent that can understand the context of the systems they're building to make project managers, businesses, clients, etc. happy.
The best markets for selling software are the wealthy countries with their cultures. You need people in those countries that are part of those cultures to develop that software. So your employment market is limited by people within that culture that have that skill, which is why there is still a software development skills shortage.
For purely technical things like kernel, database, network or driver development the job market is much smaller but it's also much easier to move those jobs to lower income countries, which is very common.
But most software development jobs are at the application level where having a matching language and culture with your users is essential.
Something as trivial as a signup form that asks for firstname and lastname and then refers to the user by their firstname later in the application is something you wouldn't even need to spec out for an English speaking programmer. They would just implement it like that by default because that's the culture.
But by this hypothesis, countries that have a different culture, but have similarly good programmers, would be able to produce a product suited to their own culture and thus out-compete the imported english version.
But this rarely happens, if at all. So there's something that's still amiss.
And this seems to be fairly consistently true although there are other factors (e.g. does your culture attract talented people to technology or do they work elsewhere? Is there a consumer market for software in your country, etc.).
Other countries tend to use communication applications and platforms developed at or near their country (WhatsApp seems to be one of the bigger international exceptions from my experience).
There are a few exceptions to this where massive US companies have the scale to setup native teams in markets that understand culture well. Outside of that, it tends to fall apart. Some examples come to mind:
Taobao, QQ, Baidu, Yahoo Japan, Weibo, VK, Aliexpress, Line, TikTok, etc.
(Note not all of these examples may be good because I'm not intimately familiar with all of them--since I too tend to use systems developed in my country).
Facebook, Google... they seem to span cultures probably due to providing services people fundamentally want to have across cultures. Large businesses typically have the capital to invest in addressing the cultural barriers and developing solutions.
Apple has a massive share world wide but when you look at Samsung in South Korea or Huawei in China, you'll see more adoption. Some of it may be nationalistic preference but I argue much of it is due to developing products/services that properly address demands in the market (which is tightly tied to culture).
This is exactly how it works in Japan. The country lies in the sweet spot where software development will likely never be able to compete globally, but local talent is good enough and the cultural divide big enough that local players almost always dominate the global competitor (e.g. Yahoo vs Google).
It is much more lucrative to make the version for Americans. The other country ends up with whatever's cheapest to make, which is more likely to be a localization than a parallel effort (the better cultural fit for an independent product would not be worth the cost).
This does indeed happen and the biggest example is probably China. Wechat with its super-app concept has done something that didn't really have a Western analog. Didi replaced Uber in China, Alipay and TikTok and a lot of other apps constitute an entirely different, domestic ecosystem.
It's also starting to happen with banking / finance apps. Nubank is growing very fast in Latin America, Africa is starting to have a domestic ecommerce sector, and so on. The internet is new and many countries, particular developing ones that have a sufficiently distinct culture to not just adopt Anglophone products are only now starting to have the talent and infrastructure in place.
It's also happening in messaging. Telegram is overwhelmingly more popular in Europe/Russia than it is in the US. LINE is the most popular app in Japan and Thailand, Facebook Messenger and SMS still dominate in the US.
China is not a free market, but your other examples are mostly on point. Except that Telegram (and Viber) are really popular only in a few countries. Most of Europe (and the world) uses WhatsApp.
For niche markets this does happen, and for mass consumer markets the economy of scale comes into play, as the local market is so much smaller than the global market, or the English market, or even the local market of California (I mean, the state of California is economically larger than many countries, and doubly so for the premium market targeted at wealth individuals) that the local adjustments aren't sufficient to outcompete the much larger investment available due to a larger market. But for the larger markets this definitely does happen.
Whenever you hire someone from a different culture / country, you
need to start from the basics by explaining the very core of your society.
An American programmer might not be too concerned if a body temperature
measurement returns 45 degrees Celcius. Similarly, a patient height of
95in probably wouldn't immediately raise alarm bells for a European
developer.
This is so key and has been overlooked for decades.
In addition to what you wrote, I think it may actually go beyond that?
There's a certain "team unity" that binds good teams together. It's that extra "something" that helps you get through those tough moments and really work together.
I've worked on remote, international teams that HAVE had that kind of esprit de corps. And I've worked on local teams inside the same building that haven't.
But, overall?
In my experience that kind of unity and teamwork is MUCH harder to build across cultures and/or remote work arrangements. And the difficulty is often multiplied by the "mercenary" nature of consulting work in which consultants obviously aren't really incentivized to worry about that sort of thing - in fact you kind of need to form emotional armor and avoid it to an extent.
It can be done, and is absolutely worth doing. (And, in my opinion, it's a form o institutional racism not to...)
In my experience it's often as simple as giving employees some space to banter and chitchat and get to know each other. Can be as simple as a #random or a #chitchat IRC/Slack channel sometimes and/or a company culture that allows for some chitchat and getting-to-know-eachother during daily standups. And if you are working cross-culture, at an absolute bare minimum, do some homework to at least understand each others' holidays and intangibles like differences in etiquette and so forth.
Thing is, in typical offshoring arrangements, much of this is impossible.
> Thing is, in typical offshoring arrangements, much of this is impossible.
I am quite the outgoing and easily sociable guy but I'll agree this is impossible and will tell you why it's impossible for me:
What you propose happens on the company time. Remote contractors always have this anxiety about "am I spending my time being focused enough on the work I am paid for?"
Shortly before I was laid off from my last job I realized that I constantly postponed getting to know the team better because of that.
It's hard to let yourself be looser if don't have the status of an employee (vs. being a contractor) and/or if you aren't shown you are a valued member of the team.
I am curious as to what is the benefit of having employees chit-chat with each other, or become friends. I have never personally worked in a dev team that has the `esprit de corps` but as long as you give me a good design, I will implement and release it, and I will work with others to help them in their work.
But I am absolutely not interested in their political opinions, what they had for lunch or what their girlfriend told them last weekend.
I don't know the answer, but to give a counter thesis:
- with higher "programming literacy" in a country they might have more top class programmers, top class programmers where able to optimize their career early by moving to western countries.
Worked in healthcare IT in the USA. Beans counters were utterly determined to send our work overseas. Old story of training our replacements.
We could teach them programming, testing, our stack.
But we couldn't teach them our healthcare system. Stupid small stuff that challenged us were completely opaque to our colleagues. Stuff like definitions of "visit" vs "episodes of care" and how each customer had different rules. (Made worse by sharing data between orgs.)
(My billion dollar idea was to help our counterparts adapt our stack for their local markets. India, Malaysia, and Vietnam have healthcare too, right? Get in on the ground floor of those emerging markets. Alas.)
Wait, hold on. Won't this be easily mitigated by a native programmer tech lead working overseas?
Say I was born in X (low income) and raised there, and then move to Y (high income) and work there as a programmer for several years, then it should be easy for me to hire programmers from X and be the bridge to management at Y?
And still has its challenges. Another man in the middle doesn't make information flow easier and it's often hard enough to explain between parties within the office.
> you need to start from the basics by explaining the very core of your society.
Well, that's task-dependent. For healthcare billing software, certainly.
But if you're hiring someone to implement the SVG spec in a web browser? Bézier curves are the same no matter where you are in the world.
Indeed, if knowledge of culture was the key wouldn't comparative advantage lead to low-cost-of-living countries' developers dominating technically pure, well-specified work like web browser design?
I try to explain this to people all the time. People discount tribal knowledge. I always use the analogy what if we where hired to build an app for Islamic banking, and ask them do you know anything about Islamic banking usually the answer is no. I know one thing about Islamic banking, they are not allowed to charge usury and I think they charge an upfront fee. I don't know how it is paid or if it is rolled into a loan, but the point is, someone who is from an Islamic country would know this, just like I know a US loan is going to be amortized with compounding interest that does not compound. Though I am not a banker, I have tribal knowledge of this contract. This filters down to very simple things that people take for granted.
A programmer from the US won't know the nuances of US banking either. I agree that someone has to know and write the specs. Does it have to be the programmers?
I agree that domain knowledge is invaluable. But in the examples given, the difference in domain knowledge between local talent vs remote may not justify the 5x salary.
The problem with any outsourced companies is they live and die by acceptance criteria. Many times it takes longer to write out all of the criteria to the level of detail that I need than to just do it myself because natural language is horrible for such technical details and trying to explain to someone "What" and "why" is too time consuming.
It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy.
On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use.
To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".
I've worked on banking software development, and we definitely expect programmers to know nuances of banking.
Perhaps not all the nuances, and many aspects are arbitrary choices and only the spec would reveal what the business unit chose, but there's a lot of domain knowledge required to be productive.
If we need to outsource stuff, that has to be to some outfit that has developers experienced with banking nuances, and often times they are more experienced than internal devs (because they have worked on this parictular tricky corner of banking for multiple different institutions), and if we hire devs from outside the industry, we expect the first 6 months to need a lot of handholding because they don't know the nuances of banking and they can't be productive at all until they learn at least most of them, because no realistic spec will be sufficient for a programmer without a domain knowledge, at least not in the financial domain.
> An American programmer might not be too concerned if a body temperature measurement returns 45 degrees Celcius.
I'm baffled by this statement... I worked in the medical device industry for years at a company of 10k people and you would be hard pressed to find a sw engineer that didn't default to Celsius. Almost all sw engineers there either had EE, CpE or Biomedical Engineering degrees; Celsius is not remotely foreign to these types of engineers. I would be incredibly surprised if it was different at any medical device company.
> It seems to be missing a very big factor: culture.
This. The value a programmer brings to the table is almost entirely their cultural knowledge. It's the same reason why rarely do chart topping hip hop albums in the U.S. come from India or wherever.
Seems dubious, since the cultural difference between people in the same country is huge and can be much larger than the difference between countries.
The average programmer at Instagram in California probably doesn't have much more in common with the average Instagram influencer or feed-scroller than the average programmer in India (both programmers tend to spend most of their time thinking about computing and abstract math/CS concepts, while the influencer spends it thinking about marketing, social relationships, travelling, etc. and the feed-scroller is all about instant gratification and pop culture).
To add to this a bit, one thing that I haven’t noticed anyone talk about is that to a huge degree, programmers are supposed to manage themselves. It may not seem like it to those who have worked in tech for a while, but as someone who is in a different field where it’s not the norm (Academia), it makes a big difference in efficiency.
In my corner of academia, programming is almost always seen as grunt work and delegates to undergrads and junior grad students. Of course students aren’t trusted to actually manage the project so usually mid-level scientists or post-grads are assigned to oversee and manage them. The managers usually have no idea how to program or what it entails, nor do they have any interest in the project. At most they’ll want to use the software after its finished. If agile/waterfall programming annoys anyone, just be thankful you have a methodology for software development at all. Since literally everyone is senior to the programmer, but nobody else knows how to program, everyone just justifies their time by suggesting new features. Since no one knows how long anything should take, all new features are accepted into spec at anytime. Eventually, the project starts to run long, and since nobody knows why, management responds by adding more layers of management. Finally, the programmer either quits or graduates and the grant for the project runs out. The final product usually either has no resemblance to the proposal or only works on sample data. If it’s a website, no one bothers maintaining the server. If it’s a package, all dependencies go out of date within a year of release. The PI, or a PI down the hall gets a new grant to do basically the same project again, and the cycle repeats itself.
IMHO, it's much much more likely that the issue is the geography of skills, and we're entering a very interesting period where we may do an experiment to see if geography is the answer.
There are a number of technology-specific hubs around the world and even just in the united states. Silicon Valley is one of the most obvious ones, but Raleigh is another one, as are Nashua, Boston and Salt Lake City (there are others).
What all of these have in common is that each of them had, at some time in the past there was a massive company with out-sized returns. In the Valley were were _several_ - Intel, HP, ... and many more. NCR (and others) in Raleigh, Westford, Petaluma (optics), Boston as a geography absolutely dominated storage until Netapp, and so on.
When you have companies like this, they produce a lasting geographic concentration of talent, especially early in a given sector's life. Think Michigan and especially Detroit for automakers or California for aerospace.
The experiment we're doing with the work-from-home thing will be interesting if it goes forward, because as a few locations in Canada demonstrated, a very active de-centralization of a given kind of expertise (in that case, the network element management software) can render a given tech hub a memory at best. If history is anything to go by, disassembling Silicon Valley, if possible, will not result in more uniform distribution, it will just move from one concentrated area to another.
That would contradict the fact that so many immigrants from very different cultures work so well in the US academia and tech
The one thing about culture that matters is the work ethic, which indeed is hard to reproduce in many countries, but other facets of culture aren't really significant.
> An American programmer might not be too concerned if a body temperature measurement returns 45 degrees Celcius. Similarly, a patient height of 95in probably wouldn't immediately raise alarm bells for a European developer.
I would be questioning professional qualities of these programmers at this point. That’s just a common sense and base knowledge about the world you live in and people you write code for.
I’ll add one to the list: cultural understanding. There are products that are either not common in a specific culture or unavailable due to socioeconomic factors. It can be difficult to meaningful contribute to a product someone may not understand or have access to.
> Programming jobs are silly easy to move around and most of them can be done remotely.
As long as you start with this hypothesis whatever analysis you do will be wrong.
We do have problem coordinate between teams that share the same hall and the same boss, I cannot even imagine what would happen with complete remote team in Vietnam to save money. It would be just better to stop develop software ourselves.
Now with COVID-19 things are changing, but we must wait a full cycles of hires (read 10 years) before we can really tell. At the moment we are all remote, but the conditions are the same of when we left the office. And on-boarding people seems though now...
Yes, and unlike Slack, in-person communication implements a Mutex where someone will see that someone else is talking to you and come back later without requiring any explanation or indeed awareness on your part.
That doesn't sound like a problem that remote work will either solve or cause. That sounds like a problem with staffing and management—hardly an uncommon one—that needs to be solved by either reducing the team's responsibilities, or increasing staffing.
(Personally, I'm pretty damn sick of management, of any level, insisting that these are the responsibilities, these are the tasks, if you can't get them done it's your fault, even in the face of their team telling them, repeatedly, that they're overworked. That's abusive management, period. Hire more damn people.)
> The reality I see, is that all of us are overworked / with a lot of responsibilities.
The bigger the company, the less this is true (although there are also a whole host of smaller companies where this isn't true either). My last 3 companies are not filled with people who are overworked AND have little responsibility. Remote-only has exacerbated the slack.
I agree that’s the current state, but someone is going to crack it sooner or later. As the article implies, there’s a trillion dollars riding on it. Programming is my only skill, so after that happens I guess I’ll just go live in the forest.
Put another way, the converse hypothesis "programming jobs are not easy to move around and most of them can not be done remotely" resisted falsification, increasing our confidence in its truth.
Another thing is that a lot of people do not want to be remote and enjoy being part of a group they can actually meet.
For example I find pinging off ideas off each other and explaining things much harder on remote due to a lack of a whiteboard or a notepad. No collaboration tool I tried was even remotely a good substitue.
I like the conversations I can have while taking a coffee. And going out for drinks with colleagues from time to time.
I hate working alone in my bubble all day long. I like having the possibility to do so from time to time, but not all the time.
As it was already mentioned in other comments time proximity is important. Managing things like pull requests or user tests over large time differences makes thing considerably slower.
The whole premise of full remote is only valid for a subset of projects and team compositions.
Labor costs, labor costs, labor costs. They dictate everything. Companies will find ways to drive them down. All this remote stuff, the first thought you have should be “labor costs”. Same with “learn to code”
>3. Most "good" programmers move to the high-income countries
Your example of Germany and Switzerland in this case is less illustrative than say India and US - the poorest places automatically lose the best talent because the standard of living is not comparable even if you were earning the same remotely and had 1/10 living expenses. And then you factor in the quality of education available, projects available, etc. Juniors have a hard time getting remote jobs - so they are limited to local job market - and if most projects in your country are low end outsourcing jobs you get experienced in those vs. more demanding work.
Consider the opportunities for your children growing up in a developed country with an above average income vs. staying back home. It's the same networking effects you would benefit from by moving, but multiplied since they get them from the start.
I'm talking about the more extreme cases like India and US, but if you want to take it there I'd say compared to the US the opportunities for you and your children will be better when you're in the top income bracket.
I used to talk to my wife about moving to the US. It would be good for my career I'm sure.
Then there was a school shooting. And my wife said "We are not moving to the US". And I didn't really have anything to say in response. And then there was another shooting, and another one. And each time she said the same thing, and each time I couldn't really manage a response.
Eventually, I stopped talking about moving to the US. And now, when there is a mass shooting in the US, my wife doesn't say "We are not moving to the US" any more.
There are good things there of course, first and foremost the salaries and the nice suburban houses. It's a good place to consume things I guess.
But there are many illnesses as well, what's happening now could be just a preview if things go sour economically.
Also you will work more and probably experience more stress for that money than you would in Europe. On average North Europe is way happier than the U.S but not as many people wanna move there (can be partly explained by the language barriers but I think it's simply people thinking that more money = more happiness).
> There are good things there of course, first and foremost the salaries and the nice suburban houses
Australia has lots of nice suburban houses too. But they are expensive, and you'll struggle to get paid enough to afford one. One advantage the US has over Australia – while it has really expensive areas like the Bay Area or Manhattan, it also has lots of medium-sized cities with affordable housing and plenty of jobs – Australia's population distribution is much more lopsided, and the parts of the country with affordable housing tend to have quite limited employment opportunities, especially in fields like IT. (Remote work can help there, but Australian corporate culture is behind the US in acceptance of remote work, although COVID is helping to change that.)
> On average North Europe is way happier than the U.S but not as many people wanna move there (can be partly explained by the language barriers but I think it's simply people thinking that more money = more happiness).
I wonder if the weather is also a factor? The US – even just counting the 48 states – offers a wide variety in climates – Michigan in winter is colder than Copenhagen, Florida's winter is quite pleasant. Not everyone likes snow.
I think Australia offers a better life for the average person than the U.S but that's just my opinion (though I've never been there). At the same time it's so far from anywhere else, if you're Indian or Bulgarian you better stick to Europe if you want to keep in touch with your family and friends.
As for North Europe: I think it's several factors keeping people moving there en masse, the language + familiar culture are very important for immigrants.
It's just harder to fit in in a place like Sweden when you don't know the language or the local culture. Even if you never set foot in the U.S you know it. You know Trump, Thanks Giving, 4th of July, New York City etc etc. It may be really superficial knowledge and isn't really gonna help you to make friends there, but it's a big part of why people still want to move there.
At the lower end of income, pay is definitely better in AU than US. (At higher ends of income, it tends to be the other way around.)
Housing affordability is on the whole a lot worse. The majority of the US population lives in areas with relatively affordable housing. In Australia, the majority of the population lives in areas with low housing affordability. There are a number of contributing factors – US had a big real estate crash in 2008, Australian property prices only experienced modest falls. I think one of the factors behind the more modest crash is that in US most residential mortgages are no-recourse, in Australia full-recourse is the norm, so it is much easier for US homeowners to walk away if their asset is underwater. US foreclosure laws tend to be much more borrower-friendly than Australian laws as well. Differences in population distribution (Australia's population is much more centralised than the US's) is another factor. Yet another factor is that Australia has mortgage interest tax deductions for property investors but not for owner-occupiers (unlike the US where owner-occupiers get mortgage interest deductions) – which I think changes the occupier-vs-investor balance in property ownership in a way which disadvantages the asset-poor majority of the population (while benefiting the asset-rich minority) – and also contributes to the heated Australian property market.
The theoretical benefits of offshoring are obvious: get the same thing for less. The same goes for juniorization, find a young guy who can do the same thing for less (this worked out great one time in an HFT I worked for).
Your problem is there's a chance -whether you offshored or not- that not only do you not get the same thing, you get a steaming pile that your boss will not appreciate. And it's not like a 80% working software solution is worth 80% of the money, it's worth maybe 20%.
So how do we compensate? Fall back on crutches like "we only hire Ivy League or Oxbridge grads". Or make sure whoever it is had a roughly similar culture to yourself (comms style, language), is available in a similar time zone, or has done similar work in the past. It's not that these will ensure you have good programmers, it's more that you can say to your boss, "I acted conservatively but even then sometimes you don't get the right hire".
All of which point towards advantaging programmers in the West. Either you have all these qualities (culture, tz, experience), or you have to discount quite a bit.
Naturally this isn't universal. You are gonna find people in Asia who somehow make a Western salary, and good on them.
Good point, I touched on that in another comment. Both ends of the spectrum are extremes, but one cannot deny that when you look to reduce costs that dramatically you are gambling. Why is something 80% cheaper?
‘Oh it’s because their country sucks’
Ah ok, and you found 30 geniuses in this crappy country?
‘Yep, these particular guys are all the cream of the crop’
Got it. Okay, let’s give it a gamble. I’m not making a real point, so don’t beat up my straw man, this is just my gut feeling.
> One could argue a huge inefficiency still exists if you assume that offices are not useful and companies should always work&hire remotely (thus removing the cost of living from the picture).
> But in that case, I would at least expect office working to go away before we see any dent in the wage gap. However, a lot of companies seem to be set on office work. Whether or not this is a good thing, I don't know, I lean strongly towards "no" but that's a post for another time.
I've been a full-time telecommuter for 6 years: Offices aren't going away anytime soon. So many people need face-to-face communication with their colleagues. Even I need to travel to the office from time to time. I've always had a technical role; when the opportunity came to be a "manager" I rejected it because I just couldn't envision myself as a manager without being physically in the office at least 1-2 times a week.
So, if you ask me, the reason for the salary difference is because we need regular face-to-face contact with our peers.
Is it just me, or does the link lead to a different article, "Imaginary Problems Are the Root of Bad Software" sometimes? I tried opening the link and it sometimes goes to the one titled like this post, sometimes to the other one - for the same URL.
This seems like a very ironic problem when considering the content of the "alternate" article being presented... Example of an excerpt:
"The problem is that you thought you requested a core product with a couple of extra features, if they were easy enough to implement. Meanwhile, the dev team heard something else. They heard about some exciting challenges they could tackle… and a slew of boring, basic features they couldn’t be bothered to test properly or care about."
> 3. Most "good" programmers move to the high-income countries
> Again, fairly hard to find data on this
I'm surprised it's hard to find data, but yes, this consistently matches my observation over the past 30 years and four different geographic locations: very few American programmers are American at all. When I did my master's in CS 15 years ago, I was almost always the only person in the room born in the United States, and besides the (either Indian or Chinese-born) professor, the only US citizen as well.
The american public education system is abysmal. But the ones in russia, china or india is pretty good, if you're smart. And the smart ones then immigrate to the highest paid country they can.
That's definitely what I see - I would think it would be easy to find hard data to back that up (although poking around, I haven't been able to find it myself).
A master's degree from an American university is a huge benefit when trying to get a visa. That means there are plenty of international students who want to get master's degrees from American universities because it helps them get into the country.
Americans don't need visas, so most of them don't bother getting a master's degree, because there is not as much benefit relative to the opportunity cost.
This fits. It is called "brain drain", where the smart people leave low-income areas to go somewhere they will be paid more. And why shouldn't they, if a company will pay them so they have more in savings in the rich area than they would have even earned in the poorer area?
However this should push down the salaries in the higher income areas and push up the salaries in the lower income areas due to lack of workers. That doesn't seem to happen much.
If it was average Joe's moving, sure. It's the cream of the crop though, the opportunity makers. It grows the economy where they go and shrinks it where they leave.
Yeah, this. Most people I’ve worked with aren’t American (although Canadians+Americans together are a plurality or maybe even a majority). It makes sense that if you want to make money and are OK with living in the US, you would move here to take advantage of the significant pay arbitrage.
Although CS masters in the US are glorified paid immigration programs so it’s not a perfect comparison. But this also holds up in industry.
One angle on that: American programmers may not do master's degrees as much, for less need. You can usually get hired in industry without a master's, if you can speak well and demonstrate your experience and portfolio enough. I'm American, with only a bachelor's in CS, but I've never felt like a master's is needed for anything in industry, only academia. A foreign-born programmer without the experience and portfolio would likely feel more need for a master's degree to demonstrate qualifications.
As an example, Finland has a population of 5.5M, US has a population of 328M. If you would outsource 10.000 coding jobs to Finland, it would equal outsourcing 10.000 coding jobs to Minnesota. So it does not make sense to compare country vs. country.
If you outsource talent pool from Finland, the cost is not so much different on paying salary in US.
I do think, that in future it is the norm to have a remote community in all companies to control cost and to access best talent. It will be an accepted fact that people are paid differently based by location.
Absolutely not. Offshore labor is worth objectively less because of different people who are in the game there. Market is absurdly efficient, there is no arbitrage. Some kinds of work is better outsourced - repeatable maintenance work, some better done locally such as product development.
To my knowledge - as an US immigrant, who has worked both in India and US - decisions everywhere are made by Managers (Non-Developer Ones) and Executives - they have weird power dynamics that they need to see their subordinates physically to ascertain their power or influence in the company...thats it - that is what is stopping every programmer being remote
This seems like it has a anti engineering bias written by a product manager who views himself as visionary and others as less. As if to say miscommunication is one sided. Nevermind the business over expecting and over selling, under paying, changing its mind radically, not respecting recommendations and just in general shitting on engineers.
With all of the talk about companies going remote lately, I worry that the logical next step to this might be management saying "well, we are already hiring remote developers, why don't we just outsource to cheaper countries while we're at it?".
Sure, they tried and failed at this in the 90's and early 2000's but heck, people forget quickly.
One of the things that I like about working in an office is that the non-engineers see me there and get a better appreciation of what I do.
349 comments
[ 1.1 ms ] story [ 489 ms ] threadI assume that's a typo for "taught" but maybe it's one of those Freudian slips. I'd say being at least medium-clever and being thought of as a programmer is the prerequisite for getting paid loads of money as a "good" programmer.
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.
The rest is cheap in comparison, whether done in SF or Bangalore.
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.
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.
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).
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
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.
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)
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.
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.
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
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.
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.
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.
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.
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.
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.
Ouch. Yeah some US/UK doctors are overpaid but the liability is not addressed. Also not sure what algorithms they are referring to. I don’t know any even in radiology/pathology that can rival a physician.
From my friends who work with outsourced programmers, this is also an issue in the coding world right? Who’s held responsible if something is not working or delivered?
A lot of people like to point to regulations and licensing as a source of inefficiency, but in reality the lack of any sort of professional licensing around programming drives all sorts of alternate inefficiency: with no objective standard to measure applicants against, employers are stuck trying to make up their own, usually broken standards.
But the flip side, using newer research, may fix incorrect/suboptimal diagnosis or treatment, but can also fail.
I'm of course sidestepping the "I'm an MD and am right, and you're a layperson and don't know medicine" mentality, but to be fair, there are fewer of these in the newer generation of MD/DO/healthcare providers.
You're saying this based on..?
https://towardsdatascience.com/why-ai-will-not-replace-radio...
This covers some points, but "never?" I'm not so sure about that... That's why if I can't beat 'em I'm trying to join em
The reason this doesn't show up in the data is that hypothesis 3 assumes that people want to do remote work from their country. What I actually observe is lots of programmers from the Middle East and Asia coming to Germany, the US and probably other high income countries. Obviously emigration is easier for more capable programmers, lowering the average skill of those left behind.
If your goal is to implement some code for, say, healthcare, it is a lot easier to explain the business process to someone who is already familiar with how stuff is done on a higher level. Whenever you hire someone from a different culture / country, you need to start from the basics by explaining the very core of your society.
An American programmer might not be too concerned if a body temperature measurement returns 45 degrees Celcius. Similarly, a patient height of 95in probably wouldn't immediately raise alarm bells for a European developer.
Your offshore developer team might be perfectly capable of writing the code once they understand what to write, but getting them to understand it is a hell of a lot more difficult.
Add to that the possibility that English is the second language for both sides, and things get messy pretty quickly. Not to mention a time zone difference making communication even harder.
Silicon Valley and Scandinavian cultures are very flat, so it is possible for "the man on the floor" to tell management that it doesn't work to put diesel into a gasoline car.
In authoritarian cultures this would be a mistake as it's seen as embarrassing the management by saying they made a mistake. If you want to continue being employed then it is much better to pretend there is no problem.
Catching problems early saves a lot of money in software development, so a non-authoritarian culture can save a lot of time and thus have a lot higher wage.
Mao became undisputed leader. His purges were bad enough that the party decided to implement a 10 year term limit.
Xi removed that limit, and now China is swinging slowly towards authoritarianism. We're still in the early years of his rule at this point. Wait till he makes a mistake and his grip starts slipping, then he will see enemies everywhere.
When someone makes themselves ruler for life, it tells you that their character is not suitable for that position, because they lack the humility to hand over their work to a successor. Because they've decided they can't trust other people's motives and competence.
These are extremely hard to find, and anyone who thinks of themselves as one is missing at least one of those properties.
"Doing the work," "managing the people doing the work," and "making the decisions about what work should be done" are not simply three ascending levels of expertise in one domain. They are three completely different domains. All good so far; the Peter principle takes this into account. Someone who's good at "doing" gets promoted to "managing", and doesn't have that skillset, and gets stuck there.
But it's also true in reverse. Just because a particular person is not good (or, more generally, less good than the best) at "doing", that doesn't mean they'd be bad at "managing". And just because someone is not good at "managing" doesn't mean they'd be bad at "deciding".
So you've got people who are good at working being promoted to manager, people who are good at working and managing being promoted to decider (which, I admit, is a bit more likely to work out than the others)—or, in many cases, people who were simply hired as managers being promoted to deciders—and then people who are good at managing or deciding, but only OK at working stuck at the worker level forever, unable to use their skills to help make things better.
However, too much focus relative to the complexity of the task at hand is never good, because focus requires ignoring some things. I would theorize that the more complex the task a team is working on, the less authoritarian it can afford its culture to be.
In an Eastern-European "authoritarian" (Bulgarian) setting, you are given tasks with not much room for interpretation and are expected to deliver a tangible "no-bullshit" result within a reasonable time frame. Not much time is spent on meetings, you don't want to ask too many questions, praise is won by delivering a technically-efficient solution which doesn't question the business intents and preconceptions of management.
In a North-Western European setting, everything is questionable and debatable, sometimes at irritating levels. Fairly incompetent people are raising their voice on insignificant matters and the decision-making debate changes direction quite sporadically. By everyone focusing too much on the business side, what you get is a technically-mediocre product which solves many problems to many people, but doesn't have much value as an integral part.
Disagree. A team can be coached to commit to a common goal.
A dysfunctional authoritarian culture is probably faster than a dysfunctional democracy, for sure. But then you are comparing which broken system is less broken, not what would be the optimal setup.
Take a sports team. They are not micromanaged. They are given a common task, a common strategy, guidance, but in the field they are alone.
They are more and more micromanaged.
* Training has become the land of measuring and controlling each detail, and has expanded into controlling your whole life as much as possible.
* Before the game, with more and more accurate and often static tactics. Don't you act another way or it means disobeying and the bench is near.
* During the game. Hardly 15 seconds go by without the coach (or the coaches) yelling orders at 1 or 2 players. Now there are even real-time data collecting and analyses, sometimes from sensors.
Perhaps the worst example of micro-management is cycling, where I am pretty sure that the only directeur sportif's dream not yet fulfilled is to be able to radio-command electrodes implanted in riders' muscles. They already get the position of almost everybody in the pack in almost real-time, they get radio-communicated real-time speed, power, heartbeat sensors measurements and two-way audio communication with each rider of the team. For now they have to do with giving imperative orders through each rider's earpiece (so the reaction can be delayed or the order not quite obeyed), otherwise managers would be computer game players. And silly (sometimes collective) punishments for those who dared disobey when they felt the orders were stupid are not uncommon: even though it means losing chances on that day or the next, the manager has one priority: showing who the boss is.
Only for relatively simple situations with a relatively known process for solving - which is the opposite of most software dev, although that seems to be changing in some ways.
Only in the extreme short term. In the medium term, the dictator inevitably ends up severed from reality by the inability of (true) data to flow back up to the authority, which results in their decisions becoming increasingly suboptimal over time.
This is the pragmatic argument in favor of free speech, really. If for the sake of argument we ignore moral and philosophical issues, the reason why free speech is important is that in its absence information does not properly flow back up to the authorities. Free information flow does not guarantee proper functioning of the system, but impeded information flow guarantees improper functioning. If your authority dictates the use of 4-inch long bolts in a place where there's only 2 inches of clearance, and nobody in the organization has the ability to feed back to the authority that information, the only possible outcomes are bad ones. This all compounds, too; the next dictate from the authority won't be able to take into account the fact that in order to fit the 4-inch bolt in, a new hole was cut in some vital structure that shouldn't be there, and some new bad decision will be made to add load to this structure, which will cause other effects. The authority ends up living in a fantasy land.
Note how this toy example seated entirely in engineering-space doesn't have any moral or philosophical component, and yet it is already sufficient to cause a bad outcome even in pure engineering terms. Moral and philosophical issues can cause yet more problems, but they'll be arriving to a space already broken.
It also doesn't matter for my purposes why the information can't flow back up to the authority. Even a well-meaning, "enlightened" dictator can end up in this situation by sheer inability to process the incoming information. The dictator may be the nicest, most well-meaning person in human history full of compassion and love and every other virtue you care to name, and they'll still break things if they insist on authoritarianism.
https://en.wikipedia.org/wiki/SNAFU_Principle
We had a lot of fulltime employees working in other countries. The company paid pretty well, and we were essentially paying US salaries to folks living in countries where that would be considered very, very good money.
This, combined with the cultural issues you mentioned, resulted in management mistakenly thinking it was doing a good job -- privately, the foreign engineers shared my concerns, but they were not willing to "rock the boat" and bring those concerns to leadership.
The US collective mentality is sometime overly optimistic specially in public. This is sometimes a positive since it removes almost any inhibition regarding challenges, but it can lead to things blowing-up spectacularly, and then having to put in place hacks and brute force to make it kind of work relatively inefficiently and inelegantly.
But it also leads to great successes (biggest economy in the world, lots of major companies, very attractive country for talents) and innovations never seen before.
This positivism is prevalent in public statement but in private cracks start to appear. It gives me the impression that this positivism is pretty much a cultural obligation, so while not authoritarian, the group mentality is geared toward not talking to much about possible difficulties out of fear of being seen as too negative by the group.
People from cultures where sarcasm isn't common don't understand this nuance and seem to find this kind of dialogue abrasive and unconstructive. Perhaps the sentiment is that if you can't articulate it clearly, then the issue is non-existent, for better or worse, or you're just being lazy and unhelpful.
What also helps, counter intuitively, is providing multiple sarcastic statements in quick succession. People listen to spoken words at set rate but the nonverbal parts of communication are instantly clear. This allows the listener the opportunity to consider the extended thought in a single context allowing for a richer sample of sarcastic communication to think over.
Sarcasm + empathy for those around you dealing with the problem = powerful form of communication.
Sarcasm + being an asshole = being an asshole.
(Note: This is from my Australian background/culture/point-of-view, and I don't for a moment think it applies cross culturally - we are the culture where calling someone a cunt can be either a sign of deep profound friendship, or a reason to be punched in the face. When in the US, I need to be careful with that sort of instinctive interaction/language...)
You can be cynical and sarcastic without being personally abusive or a sexist troglodyte.
The "militant counter culture" you speak of definitely does exist. But codes of conduct didn't start appearing out of thin air, they exist because they need to exist. Anyone who doesn't recognise that is almost certainly coming from a place of oblivious privilege. (Hell, I admit to being obliviously privileged a lot of the time, and _I_ can see the very real need for codes of conduct to exist so that assholes and troglodytes can't continue saying "It's a joke, calm down", or "I'm just being blunt, you can't handle the truth" or all the other gaslighting bullshit they so often get away with...)
They exist because projects have been bullied into doing that. On top of that the conditions were pushed in. Do you really need to have a thing to say "don't deadname"?
Expectations of conduct have, and continued to, existe(d) before that and they were enforced. The only thing this does is to try to give people who don't like how a group is run room to bully the people running it.
It is an infuriating challenge to deal with, especially when you're faced withacompletely passivebusiness interface only committed to answering exactly the question you ask, not taking the question and doing the bit of contextual fill-in and translation one would expect. As a result, to cope with that, you have to ask heavily qualified, context bearing questions to Get to the bottom of anything; which after a certain point becomes unintelligible if you don't have someone actively willing to follow along, which manydon'tsee the value of, because they don't see it as doing anything of value.
It's a vicious cycle really.
I had a real heart-to-heart with the CTO where I worked since he only gets along with one of the managers and doesn't like his directors. He said the only reason he approved my promotion was because he was tired of hearing Yes Men telling him things were fine right until they blew up in his face. He's a tech guy, not a business guy so probably outside the norm.
That's the first step. Proposing a complete solution that takes in the needs of the various stakeholders and doesn't just move the problem and does so in a way that makes the whole situation easier is the hard part.
If you've done that and nobody is listening, it's time to change the culture or leave.
There's a fine line between being thorough, and doing the job of several other people for them. The latter isn't what you're being paid for, and in some companies isn't appreciated if it risks some of them losing face.
The systems engineer (who was a friend, but maybe not the smartest tool in the shed) spec'd a system, and (high level verilog) simulated the system, and gave the output to the circuit guys (led by (also a friend) one of the most talented mixed-signal circuit designers I know - but abrasive as hell), said: "It won't work. Too much power draw on on modules off the bus. And besided is you power them through the bus, you're going to get a lot of noise and chop and brown-outs".
The manager - who was not an idiot - but to your point (1) above, was NOT aware of the issue and didn't want to believe it was issue and was NOT keenly aware of the issue (he was in denial), so they ran the wafers.
Chips come back - they don't work. Power draw issues.
My circuit designer friend (remember the abrasive part?) - gloated and mocked them for being idiots that did not know how to listen. (He was right - but he didn't have many friends in management).
They said: "OK. Make the changes. We'll do another run.". He said: Give me a couple of die. He went back to the lab - laser snipped a couple of traces - and voila! It now worked! (He had designed in a way to solve the problem as if they had originally decided to do it his way)
He cut 3 months off the schedule - saved millions of dollars - but were mad as hell. I think they wanted to fire him.
I learned a couple of things from all of that:
- Sometimes smart people don't know about problems because they don't want to know
- Pride is a horrible sin - I would have been grateful to have my bacon saved - they were not
- Nobody ever gets a bonus or promotion for putting out a fire that never actually gets started.
EDIT: Formatting. It's stil not great.
- Being excellent becomes a baseline expectation if you do it long enough so it's best you never put out your best possible work in the office?
Pretty interesting story, thank you for it! Seriously though, my main takeaway is that you can be a genius and not an ass -- at the same time. But in your particular example the guy was completely in his right to mock them.
And sadly yes, pride overrides a lot of other, supposedly much more important, factors. Learned that over my career as well and it's not one of the lessons that I enjoyed receiving.
Last weekend Elon Musk put a couple of people in space at a fraction of the costs NASA originally spent.
I think and hope many industries can still be disrupted in a similar way.
You seem to be comparing the cost of doing something the first time with doing it 40 years of technology later
Perhaps it’s wording and I’m sure private companies are more cost effective compared to government
Most people are very hesitant about giving honest feedback even in US businesses because of these pressuring forces. If your manager wants to put diesel in a gasoline car, you often have to agree, then have a sidebar conversation directly with that person so their negligence, ignorant mistake, or intentional malice isn't put on a large group or public display.
Very few US workers are in positions to give blunt feedback. This was pretty common in software development due to leverage developers had but it's, IMHO, been on decline.
That should be obvious. Most people I've worked for can be challenged in private if you've actually got a point - even if you're shot down in the end. The ones who are still assholes when handled correctly are usually not worth working for. The best ones can handle a public challenge on the merits of course.
That's exactly what different cultures look like: it's absolutely not obvious in Eastern Europe where I live. We call each other out on our BS freely and directly, and almost nobody ever gets offended.
It is quite the cultural shock for many of us when we suddenly have to sugar-coat and positive-tone-first every work criticism we express. It can feel like a huge waste of time and energy while if somebody tells me "Dimi, your code in module X sucks!" and I'll just laugh and say "dude, I had only a day to finish that, sorry -- if you don't like it, talk to the boss to give me one more week on it and it's going to be swell".
So no, such things as the one you quoted aren't obvious at all for many. I'd even argue they are only prevalent in the USA but I've seen evidence in both directions so I can't claim anything absolute there.
"He/she knows they screwed up. No need to pour salt on the wound."
Which is completely fair. But I've also seen fairly clueless people in responsible positions screwing up again and again and again and never being called out -- and those scenarios are not okay.
I sometime am, and will continue to be that guy.
At least partly because it's the right way to handle post mortems, but partly because coworker X is only a symptom of the problem - and the underlying problem here is a manager who hasn't got a process in place to ensure Friday afternoon rush fixes on production don't happen. That's a process problem which is neither your nor coworker X's fault. That's my fault. Sorry...
(And maybe coworker X is a serial offender for this type of fuckup. Also my fault.)
I wouldn't rush to blame you if you were my manager. It's not the manager's job to breathe down everyone's neck -- they have to make sure to foster the right culture (like don't push potentially breaking changes to production at Friday afternoon) and ensure that the people hired are actually able and motivated.
From then on though, all bets should be off. Maybe the guy/girl had an awful day and is otherwise excellent. Maybe they felt pressured due to miscommunication (or a coworker being an ass and they took it personally and figured they'll speed through the task), or maybe they simply were novice in that particular problem or technology.
None of that would be your fault.
If you are using this as a metaphor for a decision you personally consider stupid, then maybe.
If it's actually putting diesel in a gas car, then no, I can't imagine any case in which an intern couldn't safely tell that to their director or CEO.
When something is obviously not going to work akin to diesel in a gas car, I have never met someone who wasn't willing to at least take a second look at their "solution".
One kind of employer only retains crappy employees.
The other gets all the good ones.
Health care industry coding seems to along the lines. Solve the immediate issue. A few years later the complexity is off the chart.
You ain't seen nothin' then.
Try challenging an elder boss in Japan (or China or South Korea, but Japan is especially bad) and watch what happens, for example.
I find that very few cultures allow challenging authority like the US does.
Then you have limited experience with Japanese bosses.
Under most circumstances, they simply avoid trying to commit to ANYTHING. They will never give you a definite yes or no and will move glacially slowly.
However, when driven to against a wall in which they must make a decision, it is fairly common that they can, and will, spew some of the most jaw-droppingly stupid things, and nobody will ever contradict them--certainly not publicly.
Yes, when things go really bad, they will have to apologize and fall on their sword. However, the failure has to reach epic proportions before that will happen--normally they just shovel the blame onto subordinates exactly like US bosses.
First a little background:
The military is a highly confrontational culture, which isn’t necessarily a bad thing. In that kind of culture you tell people the disagreement immediately without tripping over pleasantries. It also means people are not easily offended until you try to waste their time or bullshit them with cleverness.
In the military people have to certify to do anything (super bureaucratic) so you generally know who your actual experts are without guessing and without a bunch of lying Dunning-Kruger insanity. It also means people are generally better about knowing their limitations and staying in their lane.
That being said, in the military I have no trouble or reservations about telling a superior they are wrong and why when it comes to an area I am well qualified. Knowing that the superior can immediately reconsider before making the authoritarian decisions of an iron fisted dictator. Superiors are generally better about considering the advise of their experts because the decision maker owns all risks and consequences.
In the corporate world you have to employ tact and really be careful how you deliver the message if the topic is not something already extremely objective. There is a lot of noise in the corporate world and far less interpersonal structure leaving everything open to interpretation. I find when I am at the day job communicating anything comprising more than two steps I go far beyond normal to be precise in my wording just to be clear.
There also exists a common phrase being thrown under the bus or more commonly known as a scapegoat. This does exist in the military but there are many conventions in place to catch those kinds of failures. Once that is identified it is a major reputation destroyer, which results in a huge occupational risk. It seems to more commonly apply in the corporate world when people are pushed into a corner and risks associated with that behavior are minor.
In most of my corporate employers there generally isn’t a central authority that owns any significant business risk or job terminating consequence when things go sideways (except maybe some senior management), which is certainly different from an authoritarian culture. In the corporate world there is plenty of room to blame external factors when things fall apart.
Even though it still does not literally happen anymore, there is still the tradition of the captain going down with the ship. The captain's authority was unchallenged on board the ship. But, if the ship sank, the captain paid for it with his life. This would inherently cut a lot of the bullshit. If you are the captain, your life depends on your people telling you the facts, not just what you want to hear.
Scandinavians communicate more directly. At the moment of giving feedback, Americans lack initiative, communicate vaguely and avoid confrontations.
Years ago (not my current employer), there was a big offshore team that was a huge pain in the neck because their entire development culture was one of deception and defensiveness - they'd deliver garbage but then spend enormous amounts of energy managing up and propagandizing to their reporting chain and executives that everything was finished, high-quality, etc.
One of the security teams practically begged for someone to help get this team to fix the bugs they were filing. The other team was straight up closing pretty much anything they could as "incorrect" reports or classifying all the bugs as ultra-low severity (which is basically "will not fix") so that their metrics stayed perfect. Lots of issues like this. When they were challenged on it from the outside, by one of the guys who didn't have a sense for the political situation, the best way to describe the reaction goes way beyond "circling the wagons" - they went full nuclear, politically, on that guy. No holds barred, a total nest of vipers. For engineers who have never experienced companies with deep and vicious politics, it's hard for them to understand what it's like at companies like that.
Then one day, one of the best executives at the top of the chain decided that he was going to re-organize his directs and fold these teams together, under someone from the side of the house into which the security team reported.
Now, cultures of managing up are good at reading the waters and so you'd expect that they'd change their tune anyway, and they did, but the part that was shocking to all involved is, as a side effect of the exec shuffle, the security guy above was given an important-sounding but meaningless title, and suddenly the interactions between that organization and the security guy went from a one of subversion, political smearing, etc. to one of absolute and total deference overnight.
The offshore team wasn't any _better_, they were still marginal and you couldn't trust a single thing they said, but the instant attitude change from "defiant, we-are-power-adjacent, you'd better watch yourself" to "oh XXX, we're helpless, nothing can be done, yes we will try but.." due to what was essentially the change of a string in a database somewhere was just crazy to observe. Everything went from "that guy is terrible, that guy doesn't know, blah blah' to "yes, oh, XXX is great, we love XXX, he is helping, ..."
You give the AI instruction and explanation in English, preferably as clear and as detailed as possible and you get back code.
Essentially its very similar workflow when working with offshore developer, in the future you could in theory replace the offshore dev with AI, except with much less latency.
Those of us that have been doing it a while, know that the single biggest issue in any commercial code project is bad input to the process; otherwise known as Requirements. No one knows what they want, or, even worse, they know what they want, and what they want, sucks.
Steve McConnell wrote about how projects mess up, and how much the damage can propagate throughout a project lifecycle; with bad requirements being the nightmare scenario. This was about a quarter century ago. It is not new (https://stevemcconnell.com/articles/software-quality-at-top-...).
The best requirements for a software project is code. Even an AI will need extremely high-quality, detailed, and well-considered requirements that are likely to require their own language (so AI requirement-generation will look a heck of a lot like "coding").
What AI gives us, is (maybe) speed between requirements and executable, so, theoretically, we could have a really high-power, effective iterative process, where bad input results in bad output, and we see that quickly, then refine the input; much like we already do with code, and run the build again, to see how that results in executable.
I learned development back in the "big iron" days, where CPU time was the most expensive part of the process, and we were required to debug our code in the design phase. If we borked during our slice, we were penalized.
Nowadays, I tend to just write some junky "strawman" code, fire up the debugger, and step through until it breaks.
Working with separate contractors, whether domestic or offshore, needs really good requirements, and some kind of fast feedback and a flexible, iterative lifecycle process; which is frog-fur rare.
If we don't have a fast feedback cycle, then we can't iterate effectively. In-office staff helps to make feedback fast, but it's quite possible to have fast feedback in a distributed environment (I used to work for a Japanese corporation, so I can tell you about "feedback lag"). It's just that we then need some kind of process to afford and regulate that feedback loop.
I think that the process of software development is fundamentally broken, and that the industry is still thrashing around, trying out all sorts of "silver bullets" (See Brooks, Fred).
I also believe that overbuilt process is an enormous issue. I call it "Concrete Galoshes" (https://medium.com/chrismarshallny/concrete-galoshes-a5798a5...), and it affects new-fangled, agile shops, as much as it does old-fashioned waterfalliers.
Unfortunately, if we want to reduce "tribal knowledge," and treat our engineers like interchangeable LEGO blocks, then we need a pretty heavy process. It's still a heavy process, even if we call it "agile."
"Tribal knowledge" is a bad term in the software development industry, but it is the most effective way to have a light-touch process.
It also requires treating engineers well (not just paying them well), so they stay around. I'm not sure that foozball tables and on-site beer are doing the trick, as the average stay at a corporation seems to be less than 2 years.
I do not have the answer. If I did, I would own a private jet for every day of the week. I have my own personal process that works quite well for me, but I don't think it scales particularly well to others.
The books that are published feel like they're targeting entry developers and it's a lot of stuff you'd learn on the job. It feels like we're over-promoting way too quickly and demanding delivery over experience or quality.
Interviews: You have developers that refused to learn this skill and they just skim a few leetcode problems and expect the interviewee to solve it in 15 minutes.
Best practices: What happened to developing standards and demanding/expecting tests (and their appropriate categories unit, integeration, smoke, feature/functional, etc)
Though things could get fun if AI can enable more flexible declarative programming.
Have you read laws? That is the style of language that tries to make a "precise and clear enough description" in English, but it does not go far enough, it's still not sufficiently precise to be applied directly, you would have to use something like 'super-legalese' for that.
So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English, and easier to do so in Python or some other programming language; and in any case, the difficult part of programming is thinking up the precise and clear enough descriptions.
This comes up in writing specifications for outsourced programmers. Writing a specification in English that's clear and actually precise enough takes more work than just writing the code directly - since you have to do all the hard part anyway, and then have to express it in a language that's poorly suited to do so. And a reasonable specification is very much not precise enough to be executed, it relies on the programmer putting in a lot of the details based on their domain understanding and common sense, leading to very different implementations as that domain understanding and common sense varies.
Yes but in the future this can be solved by the smarter AI.
Essentially that what a lot of developer do, they turn other people idea or english description into working code.
It's called a compiler.
I specifically referring to English though, not computer language.
Once you really understand that, you'll understand why it's difficult for those in other cultures, using other primary languages, and sometimes even remote employees to develop effective software without difficulty.
Much of software development assumes that specifications are perfectly understood, translated, and captured. This is rarely if ever the case. Developers are very frequently inferring and making microdecisions within the context of what they're developing using their personal knowledge. When they don't do this, you often get products that just don't solve the target problem.
One factor businesses really shot themselves in the foot when they butchered agile into a micromanagement time pressuring system to squeeze work out is that it made localized workers even more of a necessity because it has to be done (and interpreted) fairly quickly. This, IMHO, puts remote workers, especially those in other cultures, at a huge disadvantage as well as the systems/tools they're developing.
I don't doubt for a second talent can be distributed world wide but I do doubt that there's enough talent that can understand the context of the systems they're building to make project managers, businesses, clients, etc. happy.
The best markets for selling software are the wealthy countries with their cultures. You need people in those countries that are part of those cultures to develop that software. So your employment market is limited by people within that culture that have that skill, which is why there is still a software development skills shortage.
For purely technical things like kernel, database, network or driver development the job market is much smaller but it's also much easier to move those jobs to lower income countries, which is very common.
But most software development jobs are at the application level where having a matching language and culture with your users is essential.
Something as trivial as a signup form that asks for firstname and lastname and then refers to the user by their firstname later in the application is something you wouldn't even need to spec out for an English speaking programmer. They would just implement it like that by default because that's the culture.
But this rarely happens, if at all. So there's something that's still amiss.
And the best US companies have developed an internal culture that might not be easy to develop.
Other countries tend to use communication applications and platforms developed at or near their country (WhatsApp seems to be one of the bigger international exceptions from my experience).
There are a few exceptions to this where massive US companies have the scale to setup native teams in markets that understand culture well. Outside of that, it tends to fall apart. Some examples come to mind: Taobao, QQ, Baidu, Yahoo Japan, Weibo, VK, Aliexpress, Line, TikTok, etc.
(Note not all of these examples may be good because I'm not intimately familiar with all of them--since I too tend to use systems developed in my country).
Facebook, Google... they seem to span cultures probably due to providing services people fundamentally want to have across cultures. Large businesses typically have the capital to invest in addressing the cultural barriers and developing solutions.
Apple has a massive share world wide but when you look at Samsung in South Korea or Huawei in China, you'll see more adoption. Some of it may be nationalistic preference but I argue much of it is due to developing products/services that properly address demands in the market (which is tightly tied to culture).
It's also starting to happen with banking / finance apps. Nubank is growing very fast in Latin America, Africa is starting to have a domestic ecommerce sector, and so on. The internet is new and many countries, particular developing ones that have a sufficiently distinct culture to not just adopt Anglophone products are only now starting to have the talent and infrastructure in place.
It's also happening in messaging. Telegram is overwhelmingly more popular in Europe/Russia than it is in the US. LINE is the most popular app in Japan and Thailand, Facebook Messenger and SMS still dominate in the US.
In addition to what you wrote, I think it may actually go beyond that?
There's a certain "team unity" that binds good teams together. It's that extra "something" that helps you get through those tough moments and really work together.
I've worked on remote, international teams that HAVE had that kind of esprit de corps. And I've worked on local teams inside the same building that haven't.
But, overall?
In my experience that kind of unity and teamwork is MUCH harder to build across cultures and/or remote work arrangements. And the difficulty is often multiplied by the "mercenary" nature of consulting work in which consultants obviously aren't really incentivized to worry about that sort of thing - in fact you kind of need to form emotional armor and avoid it to an extent.
It can be done, and is absolutely worth doing. (And, in my opinion, it's a form o institutional racism not to...)
In my experience it's often as simple as giving employees some space to banter and chitchat and get to know each other. Can be as simple as a #random or a #chitchat IRC/Slack channel sometimes and/or a company culture that allows for some chitchat and getting-to-know-eachother during daily standups. And if you are working cross-culture, at an absolute bare minimum, do some homework to at least understand each others' holidays and intangibles like differences in etiquette and so forth.
Thing is, in typical offshoring arrangements, much of this is impossible.
I am quite the outgoing and easily sociable guy but I'll agree this is impossible and will tell you why it's impossible for me:
What you propose happens on the company time. Remote contractors always have this anxiety about "am I spending my time being focused enough on the work I am paid for?"
Shortly before I was laid off from my last job I realized that I constantly postponed getting to know the team better because of that.
It's hard to let yourself be looser if don't have the status of an employee (vs. being a contractor) and/or if you aren't shown you are a valued member of the team.
But I am absolutely not interested in their political opinions, what they had for lunch or what their girlfriend told them last weekend.
except the vast majority of FAANgs work force are immigrants.
- with higher "programming literacy" in a country they might have more top class programmers, top class programmers where able to optimize their career early by moving to western countries.
Worked in healthcare IT in the USA. Beans counters were utterly determined to send our work overseas. Old story of training our replacements.
We could teach them programming, testing, our stack.
But we couldn't teach them our healthcare system. Stupid small stuff that challenged us were completely opaque to our colleagues. Stuff like definitions of "visit" vs "episodes of care" and how each customer had different rules. (Made worse by sharing data between orgs.)
(My billion dollar idea was to help our counterparts adapt our stack for their local markets. India, Malaysia, and Vietnam have healthcare too, right? Get in on the ground floor of those emerging markets. Alas.)
Say I was born in X (low income) and raised there, and then move to Y (high income) and work there as a programmer for several years, then it should be easy for me to hire programmers from X and be the bridge to management at Y?
Well, that's task-dependent. For healthcare billing software, certainly.
But if you're hiring someone to implement the SVG spec in a web browser? Bézier curves are the same no matter where you are in the world.
Indeed, if knowledge of culture was the key wouldn't comparative advantage lead to low-cost-of-living countries' developers dominating technically pure, well-specified work like web browser design?
I agree that domain knowledge is invaluable. But in the examples given, the difference in domain knowledge between local talent vs remote may not justify the 5x salary.
It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy.
On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use.
To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".
Perhaps not all the nuances, and many aspects are arbitrary choices and only the spec would reveal what the business unit chose, but there's a lot of domain knowledge required to be productive.
If we need to outsource stuff, that has to be to some outfit that has developers experienced with banking nuances, and often times they are more experienced than internal devs (because they have worked on this parictular tricky corner of banking for multiple different institutions), and if we hire devs from outside the industry, we expect the first 6 months to need a lot of handholding because they don't know the nuances of banking and they can't be productive at all until they learn at least most of them, because no realistic spec will be sufficient for a programmer without a domain knowledge, at least not in the financial domain.
I'm baffled by this statement... I worked in the medical device industry for years at a company of 10k people and you would be hard pressed to find a sw engineer that didn't default to Celsius. Almost all sw engineers there either had EE, CpE or Biomedical Engineering degrees; Celsius is not remotely foreign to these types of engineers. I would be incredibly surprised if it was different at any medical device company.
This. The value a programmer brings to the table is almost entirely their cultural knowledge. It's the same reason why rarely do chart topping hip hop albums in the U.S. come from India or wherever.
The average programmer at Instagram in California probably doesn't have much more in common with the average Instagram influencer or feed-scroller than the average programmer in India (both programmers tend to spend most of their time thinking about computing and abstract math/CS concepts, while the influencer spends it thinking about marketing, social relationships, travelling, etc. and the feed-scroller is all about instant gratification and pop culture).
In my corner of academia, programming is almost always seen as grunt work and delegates to undergrads and junior grad students. Of course students aren’t trusted to actually manage the project so usually mid-level scientists or post-grads are assigned to oversee and manage them. The managers usually have no idea how to program or what it entails, nor do they have any interest in the project. At most they’ll want to use the software after its finished. If agile/waterfall programming annoys anyone, just be thankful you have a methodology for software development at all. Since literally everyone is senior to the programmer, but nobody else knows how to program, everyone just justifies their time by suggesting new features. Since no one knows how long anything should take, all new features are accepted into spec at anytime. Eventually, the project starts to run long, and since nobody knows why, management responds by adding more layers of management. Finally, the programmer either quits or graduates and the grant for the project runs out. The final product usually either has no resemblance to the proposal or only works on sample data. If it’s a website, no one bothers maintaining the server. If it’s a package, all dependencies go out of date within a year of release. The PI, or a PI down the hall gets a new grant to do basically the same project again, and the cycle repeats itself.
There are a number of technology-specific hubs around the world and even just in the united states. Silicon Valley is one of the most obvious ones, but Raleigh is another one, as are Nashua, Boston and Salt Lake City (there are others).
What all of these have in common is that each of them had, at some time in the past there was a massive company with out-sized returns. In the Valley were were _several_ - Intel, HP, ... and many more. NCR (and others) in Raleigh, Westford, Petaluma (optics), Boston as a geography absolutely dominated storage until Netapp, and so on.
When you have companies like this, they produce a lasting geographic concentration of talent, especially early in a given sector's life. Think Michigan and especially Detroit for automakers or California for aerospace.
The experiment we're doing with the work-from-home thing will be interesting if it goes forward, because as a few locations in Canada demonstrated, a very active de-centralization of a given kind of expertise (in that case, the network element management software) can render a given tech hub a memory at best. If history is anything to go by, disassembling Silicon Valley, if possible, will not result in more uniform distribution, it will just move from one concentrated area to another.
The one thing about culture that matters is the work ethic, which indeed is hard to reproduce in many countries, but other facets of culture aren't really significant.
I would be questioning professional qualities of these programmers at this point. That’s just a common sense and base knowledge about the world you live in and people you write code for.
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_...
As long as you start with this hypothesis whatever analysis you do will be wrong.
We do have problem coordinate between teams that share the same hall and the same boss, I cannot even imagine what would happen with complete remote team in Vietnam to save money. It would be just better to stop develop software ourselves.
Now with COVID-19 things are changing, but we must wait a full cycles of hires (read 10 years) before we can really tell. At the moment we are all remote, but the conditions are the same of when we left the office. And on-boarding people seems though now...
So perhaps proximity is not the issue?
As long as we are close to each other, very important things don't get lost.
The problem is, you can have 10-20 people tapping you on the shoulder all at once.
Just show a "talking to user @X"/"talking in channel @Y" status the same way Discord shows everyone the game you're playing.
Butts in Seats 2.0!
[0] https://news.ycombinator.com/item?id=23405722
(Personally, I'm pretty damn sick of management, of any level, insisting that these are the responsibilities, these are the tasks, if you can't get them done it's your fault, even in the face of their team telling them, repeatedly, that they're overworked. That's abusive management, period. Hire more damn people.)
The bigger the company, the less this is true (although there are also a whole host of smaller companies where this isn't true either). My last 3 companies are not filled with people who are overworked AND have little responsibility. Remote-only has exacerbated the slack.
For example I find pinging off ideas off each other and explaining things much harder on remote due to a lack of a whiteboard or a notepad. No collaboration tool I tried was even remotely a good substitue.
I like the conversations I can have while taking a coffee. And going out for drinks with colleagues from time to time.
I hate working alone in my bubble all day long. I like having the possibility to do so from time to time, but not all the time.
As it was already mentioned in other comments time proximity is important. Managing things like pull requests or user tests over large time differences makes thing considerably slower.
The whole premise of full remote is only valid for a subset of projects and team compositions.
Your example of Germany and Switzerland in this case is less illustrative than say India and US - the poorest places automatically lose the best talent because the standard of living is not comparable even if you were earning the same remotely and had 1/10 living expenses. And then you factor in the quality of education available, projects available, etc. Juniors have a hard time getting remote jobs - so they are limited to local job market - and if most projects in your country are low end outsourcing jobs you get experienced in those vs. more demanding work.
Surely it's easy from Germany to Switzerland or Canada to the US, when you're moving to a different continent it's a whole different experience.
Then there was a school shooting. And my wife said "We are not moving to the US". And I didn't really have anything to say in response. And then there was another shooting, and another one. And each time she said the same thing, and each time I couldn't really manage a response.
Eventually, I stopped talking about moving to the US. And now, when there is a mass shooting in the US, my wife doesn't say "We are not moving to the US" any more.
Australia has lots of nice suburban houses too. But they are expensive, and you'll struggle to get paid enough to afford one. One advantage the US has over Australia – while it has really expensive areas like the Bay Area or Manhattan, it also has lots of medium-sized cities with affordable housing and plenty of jobs – Australia's population distribution is much more lopsided, and the parts of the country with affordable housing tend to have quite limited employment opportunities, especially in fields like IT. (Remote work can help there, but Australian corporate culture is behind the US in acceptance of remote work, although COVID is helping to change that.)
> On average North Europe is way happier than the U.S but not as many people wanna move there (can be partly explained by the language barriers but I think it's simply people thinking that more money = more happiness).
I wonder if the weather is also a factor? The US – even just counting the 48 states – offers a wide variety in climates – Michigan in winter is colder than Copenhagen, Florida's winter is quite pleasant. Not everyone likes snow.
As for North Europe: I think it's several factors keeping people moving there en masse, the language + familiar culture are very important for immigrants. It's just harder to fit in in a place like Sweden when you don't know the language or the local culture. Even if you never set foot in the U.S you know it. You know Trump, Thanks Giving, 4th of July, New York City etc etc. It may be really superficial knowledge and isn't really gonna help you to make friends there, but it's a big part of why people still want to move there.
Housing affordability is on the whole a lot worse. The majority of the US population lives in areas with relatively affordable housing. In Australia, the majority of the population lives in areas with low housing affordability. There are a number of contributing factors – US had a big real estate crash in 2008, Australian property prices only experienced modest falls. I think one of the factors behind the more modest crash is that in US most residential mortgages are no-recourse, in Australia full-recourse is the norm, so it is much easier for US homeowners to walk away if their asset is underwater. US foreclosure laws tend to be much more borrower-friendly than Australian laws as well. Differences in population distribution (Australia's population is much more centralised than the US's) is another factor. Yet another factor is that Australia has mortgage interest tax deductions for property investors but not for owner-occupiers (unlike the US where owner-occupiers get mortgage interest deductions) – which I think changes the occupier-vs-investor balance in property ownership in a way which disadvantages the asset-poor majority of the population (while benefiting the asset-rich minority) – and also contributes to the heated Australian property market.
The theoretical benefits of offshoring are obvious: get the same thing for less. The same goes for juniorization, find a young guy who can do the same thing for less (this worked out great one time in an HFT I worked for).
Your problem is there's a chance -whether you offshored or not- that not only do you not get the same thing, you get a steaming pile that your boss will not appreciate. And it's not like a 80% working software solution is worth 80% of the money, it's worth maybe 20%.
So how do we compensate? Fall back on crutches like "we only hire Ivy League or Oxbridge grads". Or make sure whoever it is had a roughly similar culture to yourself (comms style, language), is available in a similar time zone, or has done similar work in the past. It's not that these will ensure you have good programmers, it's more that you can say to your boss, "I acted conservatively but even then sometimes you don't get the right hire".
All of which point towards advantaging programmers in the West. Either you have all these qualities (culture, tz, experience), or you have to discount quite a bit.
Naturally this isn't universal. You are gonna find people in Asia who somehow make a Western salary, and good on them.
‘Oh it’s because their country sucks’
Ah ok, and you found 30 geniuses in this crappy country?
‘Yep, these particular guys are all the cream of the crop’
Got it. Okay, let’s give it a gamble. I’m not making a real point, so don’t beat up my straw man, this is just my gut feeling.
> One could argue a huge inefficiency still exists if you assume that offices are not useful and companies should always work&hire remotely (thus removing the cost of living from the picture).
> But in that case, I would at least expect office working to go away before we see any dent in the wage gap. However, a lot of companies seem to be set on office work. Whether or not this is a good thing, I don't know, I lean strongly towards "no" but that's a post for another time.
I've been a full-time telecommuter for 6 years: Offices aren't going away anytime soon. So many people need face-to-face communication with their colleagues. Even I need to travel to the office from time to time. I've always had a technical role; when the opportunity came to be a "manager" I rejected it because I just couldn't envision myself as a manager without being physically in the office at least 1-2 times a week.
So, if you ask me, the reason for the salary difference is because we need regular face-to-face contact with our peers.
This seems like a very ironic problem when considering the content of the "alternate" article being presented... Example of an excerpt: "The problem is that you thought you requested a core product with a couple of extra features, if they were easy enough to implement. Meanwhile, the dev team heard something else. They heard about some exciting challenges they could tackle… and a slew of boring, basic features they couldn’t be bothered to test properly or care about."
> Again, fairly hard to find data on this
I'm surprised it's hard to find data, but yes, this consistently matches my observation over the past 30 years and four different geographic locations: very few American programmers are American at all. When I did my master's in CS 15 years ago, I was almost always the only person in the room born in the United States, and besides the (either Indian or Chinese-born) professor, the only US citizen as well.
At most schools the CS master's program is overwhelmingly international students. That's not the case for undergrad.
A master's degree from an American university is a huge benefit when trying to get a visa. That means there are plenty of international students who want to get master's degrees from American universities because it helps them get into the country.
Americans don't need visas, so most of them don't bother getting a master's degree, because there is not as much benefit relative to the opportunity cost.
Although CS masters in the US are glorified paid immigration programs so it’s not a perfect comparison. But this also holds up in industry.
If you outsource talent pool from Finland, the cost is not so much different on paying salary in US.
I do think, that in future it is the norm to have a remote community in all companies to control cost and to access best talent. It will be an accepted fact that people are paid differently based by location.
Sure, they tried and failed at this in the 90's and early 2000's but heck, people forget quickly.
One of the things that I like about working in an office is that the non-engineers see me there and get a better appreciation of what I do.