In Spain, all programmers are seniors

My current position and the outsourcing of the last five years were 90% in Western gamedev studios, so my communication was mostly with non-Russian colleagues. And when you get torn away from Slavic dev teams for a long time, the differences start to show very clearly, from the team-management model to the development culture. Though I wouldn't call it culture — more like the dance of half-Indian barbarians on the ruins of the American software-building empire. Indians have nothing to do with it, but the practices and the very process of writing code reek of the inhabitants of that semi-mythical land of Hindustan. There are quite a few books on the history of the game industry and the successes and failures of various studios, mostly Western; I'll leave a list of the most interesting and gripping ones in the article in case you decide to dig into the history (for those interested, it'll be under a spoiler).

One of the latest is "Not All Fairy Tales Have Happy Endings" (Ken Williams), the memoirs of one of the founders of Sierra On-Line, read about a year ago and liked more than the others — probably because, reading the book, I finally understood most of the decisions and reasons that led to one outcome or another. I definitely didn't have that understanding ten years ago; it's hard to explain unless you've personally worked for a long time with people of a different mindset, a different cultural code, as it's fashionable to say now. My current team is 95% Franco-Spanish-English — Australians, a few Europeans and Americans. Three people in the studio speak Russian, including me. Before that my career was mostly still Russian studios with the familiar mentality, even if managed by those same Americans, but management smoothed over all the rough edges and took the "talking the right way" upon itself, while we got only technical tasks, certificates and occasionally bonuses. Ten years ago, when I came into the game-making industry, I didn't ask myself how my tasks, my code, my ideas differed from the tasks, code and ideas of John from Campbellville near San Jose, because everyone around was "one of us." Now everyone is "one of us" too, but those "us" differ from these "us" by — pretty much everything.

The main difference I see: our folks work great in overdrive. Bringing a crashed prod back up on a Friday, under a triple surge of players — that's for us. Tearing out the last of your hair where it still remains, because there was a release yesterday, fixing bugs with hourly updates and manual fixes on live databases — sure, easy. And they do bring it back up and fix it, so well that users barely even notice. But on a Wednesday, in a calm setting, I have to nag support to prepare a couple of backup servers, otherwise they won't think of it and will forget, because it's not Friday and not a release. And it's like that with everything. This isn't just a cultural detail — it's the foundation of the mindset on which approaches to work, interaction between colleagues and one's sense of self within the team are formed.

What else really stands out and hasn't yet become the familiar routine of "now it's here" and "still over there."

Snitching is fine!?

In Europe or the States, especially in the States, if you messed up, made a mistake, introduced a bug, they'll tell you with a smile that everything's ok, it's all fixable. And after the call they'll go to the manager without a shred of regret and report exactly what's NOT ok and who's to blame. And everyone expects the same behavior from you.

Did that happen often with us? I don't recall. Only if a person really, really pushed it — like literally "doing absolutely nothing for two weeks." And even then we tried to spread the tasks around the department and cover for the guy, despite the fact that our own tasks and often personal time suffered for it. Apparently this is left over from childhood, when at school we'd catch "snitches" and explain to them in plain terms that doing that is wrong. Afterwards we'd of course get called onto the carpet at the principal's office and chewed out properly for unbecoming behavior, but "no one saw anything." Yet even now I cover for "my own" until the very last call — maybe it'll count in my favor somewhere.

Don't touch other people's tasks!

My American colleague botched one task after another, and I once had to send one back for review for the tenth time already: he'd forget the tests, or write nonsense, or not handle the cases. I got tired of it and rewrote the task myself, closed it with detailed comments and a description in the commit. The next morning the guy simply complained about me to my boss, that I was taking the bread out of his mouth; I was also CC'd, as were the PM and the lead. Say I was in shock? Uh, well, yeah. The day before we'd talked normally and he'd agreed that I'd quickly close the tasks blocking us, and then he wrote an offended email.

And that's normal — for him it's been normal since childhood, for me it's been maybe the last couple of years: people have a job and they work it; don't take someone else's work, just work your own.

All communication through the manager or PM

In Western game studios, especially large ones, there's an approach where most communication goes through managers or the project manager (PM). This interaction style is laid down from childhood. It's an upbringing — it's instilled from the cradle, from kindergarten, from school — I see it now in my own child.

From an early age, starting in kindergarten and school, children are taught to solve problems through their elders. If a child runs into a difficulty, they go to the teacher, who's aware of everything happening in the class and reacts promptly. Copying isn't done, but they're in no hurry to help directly either. If help is given, it's in the form of instruction: "Here's how to do it. Now go figure it out yourself." If a dev has a question or problem, they don't go straight to another developer but turn to the manager or PM. The manager acts as a mediator who distributes tasks, resolves conflicts and tracks progress. The manager always knows what's happening in the team and can step in promptly. This reduces the likelihood of misunderstandings and duplicated work — a sort of teacher in the classroom. I can't say it's bad — at first it's very, very unfamiliar.

In Russian studios, on the other hand, the manager usually gets informed when the house has already burned down and the shed has caught a bit too. But here too I don't see anything bad: in my teams many issues were resolved directly within the department, bypassing the manager. It was faster but carried some risk of losing the overall vision of the project, which was partly delegated to the lead, and problems were often solved "on the fly," without prior discussion or coordination with management. And everyone considered this normal, and the team felt responsible for the decisions made, which I don't see here — where a programmer just does the tasks handed down from above.

Politeness over the top

I was never afraid to tell a colleague "this code is cr...p" in Russian teams, it was normal and it was acceptable. Do it well right away — badly will happen on its own. And I also expected code and solutions to be assessed immediately and directly, from junior up to PM. My current colleagues find it hard to accept; I've been told more than once that I'm too rude and harsh: everyone's used to polite phrases and "could you maybe do this a little differently?" At the same time, if I immediately say how to do it (which, by the way, also offends people), the others limit themselves to hints like "do it a bit differently," and how exactly — figure it out yourself.

And this politeness is in everything — on one of the calls our Australian colleague was driving and forgot to turn off the radio, well, it happens, the guy didn't make it to the office in time, and the radio was loudly broadcasting the weather. Everyone listened, winced, but kept quiet and periodically muted the forgetful fellow. At some point I just had to write in the chat: "John, turn off the radio already." John sent a sad smiley and apologies, and after the call the PM spent fifteen minutes lecturing that I'd acted very rudely, that maybe the guy was waiting for something important on the radio. What? We're in a meeting, supposedly — what radio...

This excessive politeness is exhausting: instead of explaining in five minutes what I don't like about the code or architecture, I have to ramble for half an hour, beating around the bush trying to politely convey how it should be done — and there's no guarantee they'll even do it. In this respect Russian dev studios bond faster and reach the plateau of productive work: in my experience, in two or three months a new colleague joins the team and starts delivering results, or doesn't fit in — that happened more than once too. The time it takes a European team to reach coordinated work is half a year or more. During the run-in period our folks have conflicts much more often and we have to part with people before their first year, although Europeans also don't drag it out if it's clear a person doesn't fit or can't keep up with tasks.

Respect

My former colleagues always solved tasks themselves — with bugs, incompletely, not always well — but themselves. Hand a person a task and you could be sure it would get solved. There were, of course, authorities like tech leads or rockstars, whose word carried a lot of weight in decision-making and to whom people turned if they couldn't reach agreement on their own, but they'd already proven their knowledge. Want respect? Solve the tasks others can't handle. Until you've personally closed a six-month-long crash, well, ok, you're just a good coder, and it doesn't matter how many projects you have behind you. The result is a situation where decisions are made by the one who's proven their competence through solved tasks, by direct example. It's convenient and clear to many; it's always easier to follow a leader, a rockstar who sees three moves ahead. I'm not saying it's bad or good, it's just how it was in all the Russian studios where I happened to work. It's a mental trait: want to rise — prove that you can.

Unfortunately, this leads to developers from our parts being less loyal to their company than European colleagues. Here you'd have to seriously mess up in your decisions: break promises, neglect professional interests, be very rude, for them to decide to leave the studio. And as a rule (judging by smoking-room conversations), they perceive the company as a partner and trust it — this really doesn't apply to the matter of money and salary. Anthony earns below market? Figure the studio has half a year to a year before he leaves, but getting a raise inside the studio is much harder than at the place next door — such a paradox.

"Just because. Here everything is just because, except money." (c)

It's important to understand that in the game industry, probably even more than in any other, the actions of leaders play a key role for the whole studio, regardless of their cultural background. But for our developers words, promises and presentations mean nothing if they aren't followed by real actions.

A team is not just any team

In Europe and the States, especially in the States, collaborative work and collective decision-making in a team are considered the standard, the gold standard, not up for discussion. European teams, of course, are more motley, especially if there are French people on board. If a true d'Artagnan has appeared among you, be ready for ten-minute debates on any question, up to slamming the door and turning off the camera. Honestly, I expected that more from hot-blooded Spaniards or sunny Italians than from lovers of bouillabaisse (the Marseille fish soup).

Okay, the French are just part of the picture. If you work with Spaniards, get ready for a completely different dynamic — they're known for their easy attitude toward deadlines and, conversely, are fairly unemotional at work; it's in the evening at the bar that he lights up and sparks. In a meeting the emotions are very restrained, although gestures take center stage — words without gestures mean the day was lived in vain. Despite the general chaos, Spaniards often show a surprising ability to quickly pull together and find solutions, especially if there are more than two of them on the team and they shift into fifth gear of conversation. Personal connections also matter to them, so don't be surprised if work matters are discussed mostly in private chats.

At first this was annoying: 60 separate chats, and you have to answer each one without too much delay so as not to come off as rude. Now I just ask people to duplicate the question in the shared chat, citing insufficient awareness; sometimes it helps not to be a game of broken telephone across three or four chats.

Show up for calls?

Being late for calls is practically the norm for Italians and Spaniards, and it's rarely treated as anything serious; showing up to a call 10–15 minutes late is the order of the day. Being up to half an hour late to a personal meeting isn't being late, the most you can expect is scusi-scusami, there was traffic. Spanish and Italian teams generally pick a leader and quickly delegate decision-making to him, and he shows up before the others, only about five minutes late. This really annoys both Russians and Americans: the former arrive a touch early, the latter right on the dot, barring force majeure. Our American PM has been around a long time, so for the first 10 minutes or so we discuss non-critical tasks and questions from the floor with whoever showed up, while everyone gathers. But they try to keep the calls themselves to no more than 30 minutes, which in practice works out to only 15 with real substance. Before this, hour- or two-hour calls were quite the norm, with detailed bug breakdowns and sometimes pair coding on the whiteboard.

Context != task

Game development is the work of a very small team (not counting the absolute monsters, the average studio size is under 100 people), and every element of the project, from game mechanics to visuals, is tightly tied to a specific person or group. This group develops a context of communication where everyone knows who's doing what, and some words hang "in the air." This communication style is called high-context — when the parties assume a large amount of shared data. It can manifest as short messages like "Done" or "Check it" plus a screenshot. What's done? Check what? The answers will be obvious only to those immersed in the current process or who recently discussed the task in the hallway, the kitchen, the chat.

When you start communicating out of context, it leads to problems:

Context: "Fixed the textures on the third hub with pcf"
Meaning: "Fixed the bug where the character's textures didn't show up on level 3 when the lighting changed. The problem was in the shader."

Context: "Look at why the player doesn't jump"
Meaning: "Please look at the file PlayerMovement.cpp. There seems to be an error in the jump-speed calculation."

Context: "The chest doesn't work"
Meaning: "The functionality that lets the player open the inventory by pressing I and displays the current items in a grid is broken."

So, it's mainly Eastern European developers who communicate in context (Russia, Belarus, Poland, Serbia, Slovakia, Hungary). Americans and Europeans from Austria-Germany onward rarely conduct communication with context and prefer to spell everything out in detail, as if for someone who joined the project yesterday. And it's slow, really slow.

This shows up in all communication: detailed emails, clear instructions and thorough comments in tasks. And it's not just a style, it's the natural flow of thoughts in tasks and heads. Here they genuinely believe (don't laugh, I asked) that detailed communication saves time and reduces the risk of errors — I'd argue with both the first and the second. And naturally they expect the same behavior from others, and at first it's irritating.

"Hi! I've finished work on build version 1.2.3 with the fix in CL123456. Please check whether the inventory bug fix works.
… A description of the bug and the actions to fix it follows
… A description of the tests performed and a conclusion follows
If there are any problems, let me know."

And the review on the task has to be written the same way, specifying the details, what was done, and a conclusion. The French are about the only exception — they too prefer to communicate in context.

At first it seemed to me that colleagues simply treated me like a newbie or (oh horror!) doubted my skills altogether; it's very unfamiliar to see in correspondence when you're told over and over what to do to reproduce (repro) a bug. I'm used to working in context, and even now I sometimes find it hard to handle this format: tasks that used to be solved with a single phrase have to be described in detail, and instead of working work and fixing fixes, I spend half an hour describing in the task things that are "obvious anyway" from the description.

But on the other hand, there are far more advantages now — practically no misunderstandings or miscommunication, fewer pointless questions and greater transparency of all the work on the task. At least in the long run development has become less "Friday-ish" and more predictable, even if it takes longer.

The language barrier and anchor phrases

The language barrier isn't only about knowing words, it's about the subtleties of the language and the semantic load and the gaps in the semantic load of what's said to you and what you say. And Americans speak fast, sometimes faster than Spaniards, and half the words simply get lost or dropped. The American culture of communication, which they carried over into the entire game-development industry (and maybe not only games), assumes that confirmation of knowledge is followed by confirmation of action.

If you answered that you'd seen the bug, that means you understand the scope of the task, its specifics and the deadline. And if you simply said "Yes" to the question:

"Do you know that the inventory system have to fixed this week?"

That means you'll fix the bug by the end of the week, add tests if needed, notify the adjacent teams and so on — everything else tied to this task.

But if you answer something like:

"Yes, I know. The core functionality will be ready by midweek, but I'll need extra time for testing, UI dependencies and bug fixes. Let's discuss if we can shift the testing phase or adjust priorities."

That's what's actually expected of you. That's the very meaning/low context communication, where the details are spelled out. It's also worth separating off-work communication from an assigned task: when we're chatting among ourselves, you can sort things out with a wink, but if there's a task, it has to be formalized so that someone who joined the studio yesterday — maybe more than one person — will understand it. The expectation is usually that different people will later do, review and test this task.

Or another example — anchor phrases, which I bumped into out of ignorance at first. "Let's discuss this later / talk later" for Europeans means that you'll "really" come back to the discussion later. They won't remind you too often, or won't remind you at all, of the promise made, but its deadline is usually one or two weeks. And later they won't fail to remind you of the failure or complain to the bosses about the dropped task.

For a Russian developer, though, "Let's discuss later" is a polite way of saying the topic isn't interesting right now and can be put off or not done at all. And trying to transfer the meaning literally often ends in misunderstanding. In the non-Russian understanding this phrase belongs more to informal communication between acquaintances when they don't want to discuss something — but you start noticing such little things slowly.

The bottom line

Working with Europeans/Americans can be hard because of the trolling and "funny" comments that aren't always understandable due to differences in perception. But there's an upside to it: I always see what colleagues really think, even if they express it in a convoluted way. Our folks' directness and frankness, on the other hand, often looks rough in the others' opinion. Americans always strive for a positive atmosphere, even if they dislike something. Europeans avoid conflicts, preferring a neutral tone in discussions and their own local "jokes." But smiles and compliments mean nothing and are rather formal, to support the team and the general atmosphere. If someone smiles at you, it doesn't mean they're actually glad to see you — that's just how it's customary to communicate, so as not to offend anyone.