Столкновение культур на код-ревью, Россия против США

Пожалуй, заголовок слишком драматичен, на самом деле имел место небольшой спор на код-ревью, в котором мы с коллегой из США обсуждали выбранный мной подход. Обычно дело, так ведь? В процессе обсуждения меня постоянно раздражало, что коллега переводит разговор на какие-то детали, и как будто не слышит, что я говорю. Я объяснял, что моё решение концептуально лучше, изолирует логику от данных, и делает функцию чистой. Но вместо того, чтобы опровергать мою концепцию, или выдвигать свою альтернативную, коллега указывал на конкретные куски кода со словами: “во тут, тут и тут мы просто можем воткнуть уже имеющееся решение и всё заработает”. Я ему про Фому, а он мне про Ерёму!

В общем, несмотря на то, что аргументы моего оппонента были вполне логичны, меня бесило, что он рассуждает о каких-то мелких деталях, когда мы еще не обсудили общую концепцию. А потом мне попалась в интернете любопытная схема.


Обратите внимание на последнюю строку, подход к убеждению (Persuading).

Столкновение культур на код-ревью, Россия против США Программирование, Культура, Россия, США, Межкультурные коммуникации

США и Россия находятся на совершенно противоположных концах этой оси. Причем Россия лежит на стороне “сначала принципы”, то есть нам чаще важны теоретические основы и методика, а частные случаи выводятся уже из них. В США наоборот, многие люди смотрят сначала на практическую пользу, а общие знания извлекаются из частных примеров. Разумеется, некоторые люди могут вести себя совсем не так, как свойственно большинству их соотечественников, н в нашем случае мы так точно попали в статистические средние для наших культур, что даже забавно. Для меня это был прямо момент прозрения.


Раньше я думал, что все инженеры-программисты имеют общий научный бэкграунд (хоть я и бросил университет в свое время) и стремятся писать максимально хороший код, поэтому, при соблюдении элементарной вежливости и логики, любая дискуссия обязательно будет конструктивной. По моему опыту, это до некоторой степени справедливо, и, общаясь с программистами из разных стран, я определенно чувствовал, что у нас много общего, но хватало и исключений.


В процессе изучения этого вопроса я нашел книгу Эрин Мейер “Карта культурных различий”. Я прочёл её, и могу с уверенностью рекомендовать, если вам интересно, что же конкретно означают все эти оси сравнений на схеме выше. Что-то более-менее “очевидно”, многие слышали про японскую вежливость и немецкую пунктуальность, но лично для меня было и несколько неожиданных наблюдений. Какие-то черты собственной культуры кажутся обычными и единственно возможными, но только пока их не сравниваешь с другими. Конечно, открытие в духе “интроверт вдруг заметил, как взаимодействуют люди”, но, например, я не осознавал, что русский стиль коммуникации довольно “высоко-контекстный”, и многое передаётся “между строк”, намёками и аллегориями. Возможно, поэтому в Германии не задаётся общение с местными (а немцы на схеме выше обозначены как люди, говорящие прямо и конкретно), оно кажется каким-то пресным. Я списывал это на языковой барьер и собственную нелюдимость, но, вероятно, в этом есть и культурный аспект.


Подводя итог, скажу, что в том ревью обошлось без взаимных обид, логика и простота кода победили, а своё раздражение я держал при себе. Но если бы я заранее знал про эти культурные отличия, разговор получился бы намного проще и спокойнее.

Лига программистов

1.5K постов11.4K подписчиков

Добавить пост

Правила сообщества

- Будьте взаимовежливы, аргументируйте критику

- Приветствуются любые посты по тематике программирования

- Если ваш пост содержит ссылки на внешние ресурсы - он должен быть самодостаточным. Вариации на тему "далее читайте в моей телеге" будут удаляться из сообщества

Вы смотрите срез комментариев. Показать все
Автор поста оценил этот комментарий

Вообще изначально надо понимать суть проекта. Если проект терпит по времени, то можно продумать над принципами и архитектурой. Если высококонкурентный, то надо занять нишу, создать проект с функционалом и продать быстро, а потом доделывать. Можно выбрать архитектуру из стандартных, паттерны, выбрать движок, языки, технологии и инструменты, набрать команду и начать программировать в стиле экстремального программирования или devops ci/cd. Но для ci/cd нужен девопс инженер с опытом и команда с опытом. Для экстремального программирования уровень ниже.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Понимать всегда хорошо :) Я бы еще добавил, что если нет обоснованных требований о высокой нагрузке, то надо всегда выбирать наиболее простые решения - монолит, распространённый язык программирования, реляционная БД (хотя это, конечно, зависит от природы данных в проекте, а может, она вообще не нужна). Потом важный фактор - это ожидаемое время жизни проекта. Если это скрипт, или одноразовая утилита, то вообще пофиг, как писать. В принципе, год-два проект может жить с какой угодно архитектурой. Если планируется дольше, тогда стоит следить за архитектурой с самого начала.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку