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

Не всякая просьба есть выход из границ. Так можно дойти до абсурда, что мы выходим из границ, когда покупаем молоко в магазине. Но просить можно по-разному.

- Можешь поревьюить мой код?
... Проходит неделя, ответа нет
- Ау

Это полная дикость, и программист если и пишет так, то только первый и последний раз в карьере. Тем не менее, иногда встречаются такие люди в жизни.

- Можешь поревьюить мой код?
... Проходит неделя, ответа нет
- Пожалуйста

Попрошайка, даже может не попрошайка, а просто самоунижение.

- Можешь поревьюить мой код?
... Проходит неделя, ответа нет
- Что мы можем сделать, чтобы эта работа была закончена?

Самый нормальный вариант

Зачем же ты доебался к коллеге, да еще и из другого юр лица. У тебя разве прописано в должностной инструкции, что оы отвечаешь за ревью твоего кода кем-то еще? Адресуй проблему проджекту или начальнику. Ну или ищи коллегу со схожей проблемой.

Я прямым текстом пишу, что просьба о чем-то, чего у тебя нет. Обмен денег на молоко или денег на услуги это не просьба ни разу. Просьба это: продайте мне 1 грамм сыра и порежте, пожалуйста. В любом контексте можно выйти из границ.

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

Это ужасный вариант. Особенно если представить, например, что второму глубоко до лампочки, будет работа закончена или нет. Или он уверен, что он никак не пострадает, если ты зафейлишь свою часть.

Не все решается разговорным жанром, не нужно в схоластику впадать и подбирать словоформы там, где пооблема не в форме высказывания.

Третья форма это тоже выход из границ, но самый щадящий из возможных. Да, в этом проекте всем участникам постоянно приходится выходить из границ, чтобы делать какой-то прогресс в работе, такова его природа. Важно при этом постараться 1) не нажить врагов 2) сохранить самоуважение и спокойствие. Первый вариант наживает врага, второй - роняет самоуважение.

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

Вы как-то уж совсем гайки закрутили :)

Вполне стандартная ежедневная ситуация спрашивать о том, может ли коллега оказать тебе услугу в рамках работы.

В этом нет никакого нарушения границ, если вы их не нарушаете.

Всё, что нужно сделать, - это кратко озвучить то, что вам нужно, и спросить, есть ли у человека возможность помочь вам или подсказать, к кому можно обратиться за помощью.

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

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

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

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

"В своих границах" было бы уволиться с такой работы, где какие-то левые мудаки мешают твоей работе, но мир не идеален, увы.

Пожаловаться своему начальнику - детский сад.

Сделать все как хочет мудак - слив.

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

Сделать как говорит мудаг -- это не слив. Это зависит от того, конструктивна ли его критика или нет.
Я работал с неконструктивным мудаком. Это очень важно, прав он в профессиональном плане или нет.

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

Твой код может и не полностью твоя. А твои аргументы, почему ты так делаешь, а не как говорит мудаг -- полностью твоя. Можешь вообще никому урон не наносить, тогда они будут виноваты, если ты пилишь код рабочий, а они тебе палки в колеса.
Даже технически тебе скажу, что аргументировать чужое мудачество просто. Либо там реальные ошибки и косяки, которые делают все. Либо можно обвинить ревьювера в перфекционизме. Для менеджеров-технарей перфекционизм это не что-то прикольненькое, а страшное матерное слово.

Мудак с тобой ничего не обсуждает, ну и ты с ним не обсуждай.

Ну да, я по умолчанию исходил из того что мудак не прав) Если он прав, надо молча править свой код.

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

Второй момент - не все обсуждения на ревью упираются в конструктив/технику. Может быть просто вкусовщина, мол, не нравится ему, какую ты придумал архитектуру. Конечно, в таком проекте свои "нравится" желательно придерживать при себе, но мудак он на то и мудак

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

Посмотри на свою ситуацию в социальном ключе. Вот твои аргументы. Вот аргументы мудака. Чье весомей? Кого больше специалистов поддержало бы при разборе ситуации?

Поэтому нужно не приводить аргументы, а задавать вопросы.

Умение обсуждать и договариваться - это всё тоже в наших границах.

В "мирной жизни" выходить из границ не надо, но пикап это не норма, он за гранью нормальности

Обычному мужику, занятому работой, имеющему какие-то хобби помимо пикап не сдался даром. Ебать баб на количество настолько фантомное поле доминации, что хуже игр. Играми можно заработать денег, если очень сильно задрачивать -- пикапом нет.

Задача большинства соблазнить конкретную бабу, по которой они сохнут или сидят в френдзоне. Или просто поднять свою пртвлекательность до кпкого-то базового уровня, когда давать начнет хоть кто-то. Единственная польза от пикапа для первых -- это обратить их внимание на то, что любая незнакомая девушка для них гораздо лучше, чем та, которая не дает! Для вторых пикап может быть полезен. А может быть и вреден. Смотря кого они будут слушать и читать.