Затронули про терпимость к коллегам, теперь пора рассказать про терпимость в разработке или багам.

То же самое.

Бывало ощущение, что хочется переписать с нуля проект, к которому только приступили? Что все неправильно реализовано?

За долгую каръеру наблюдал, как очень много опытных разрабов плевались на людей за незнание какого-то фреймворка, либо за нестандартный подход к чему-либо. Вастрик в своей статье уже упоминал подобное, когда везде во фронтенде таскали SPA. Рекомендую к прочтению, даже если вы не фронтендер. Автор очень остроумно прокомментировал вредный тренд во фронтенде на полную загрузку всего джаваскрипта перед непосредственной работой.

Здесь к примеру автор приводит размер только js файлов при первом открытии и там внушительные размеры в среднем ~20 Mb. Это без картинок и шрифтов, только код, который при этом еще и минифицирован. Статья на минуту чтения.

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

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

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

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

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

Стремительный тренд можно объяснить развитием интернета. Буквально 20 лет назад люди работали десятками лет в одной компании, в окружении одних людей, что вынуждало людей быть терпимее, так как мобильности не было. События последних пяти лет только подтолкнуло айтишников быть избирательнее к своему окружению, тем более что они могут себе это позволить. Инерция, которая набрала достаточную массу, имеет свойство только усиляться.

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

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

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

Разберу вчерашний пример.

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

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

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

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

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

Каждое новое раздражение наслаивается, а если вы еще и написали публичный пост на тысячную аудиторию, вы просто зафиксируете это раздражение, люди просто уже заранее к вам будут так относиться.

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

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

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

Попробовал пройти “кринж-собес” с ChatGPT. Оставляю на ваш суд. Промт будет в этом посте, а диалог в комментариях.

Привет!

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

Вот мой комментарий:
/* текст с поста выше */

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

Если кто хочет, чтобы я разобрал ваш “кринж-собес” с ChatGPT, отправляйте промт и ваш диалог как в комментариях в посту выше.

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

- Вопросы будут уместны, если нанимающий сам спросил, будут ли вопросы. Без такого запроса от него, обратное интервью ни к месту.

- Не надо представлять, что бы было если бы вы косяконули. В примере выше, когда ChatGPT задавал абсурдные вопросы, он рисовал несчастную картину работы. Если бы был оффер от компании, которое уважает свое рабочее место и проект, и не считает условия работы у себя унизительным для соискателя, последний бы скорее принял оффер от такой компании, даже с зарплатой поменьше.

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

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

- Ну и про тон с “мы вам перезвоним” наверное очевидно и не надо комментировать.

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

Хочу предложить вам пересмотреть взгляд на баги, если вы относились к ним крайне негативно. Довольно часто они были фичей раньше, контекст сменился, но привычный ход алгоритма менять сложно, особенно в сложной системе. Чем сложно менять алгоритм действий, тем сложней и исправлять баг, очевидно. Если эта сложность превышает сложность абстрактного мышления разработчика в каждый момент, баг не исправится.

Для наглядности возьмем для привычные нам баги из нашей жизни вместо проекта, так как мы с вами, читатели, не делим общий IT проект.

У нас заложено искать самый которкий путь решения задач. Те предки, что так не делали, реже приносили потомство. Но из-за этой прошивки сейчас мы встречаемся с различными проблемами: переедание, малоподвижный образ жизни, кредиты, скам, использование ChatGPT для написания письма вместо самостоятельного мышления. Как личность, в нашей ответственности этот баг фиксить.

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

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

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

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

Мы видим, что работа развивается и усложняется. К примеру требования к джуну 10 лет назад и сейчас совсем другие. Теперь же простых прокачек хард и софт скиллов недостаточно. Это разные полюса, противоположности. Теперь хочу представить понятие перпендикулярные им - hot и cold скиллы.

Под хард скиллами мы скорее представляем умение работать в одиночку и найти решение, а под софт скиллами умение разговаривать с коллегами и формулировать задачу, договариваится. Если дело предстоит с хард скиллами, мы можем обращаться грубо, ломать код, чтобы разобраться, убедиться, что все работает бесперебойно и возможно даже обратиться к С++ для оптимизации; то когда нам предстоит работать с софт скиллами, нам нужно быть тактичными, возможно даже откладывать иногда вопрос и не спешить, убедить команду и тим-лида переписать старый Java на Kotlin и Objective C на Swift.

Скилл в компоненте работы может быть 4-х видов: hot-hard, cold-hard, hot-soft и cold-soft. Важно еще учесть, что скилл ваш должен из одного состояния переходить на другое, и так же не путаться там, где ему быть не стоит.

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

Все баги появляются от того, что вы используете не тот скилл, который требует того проблема.

При оптимизации или отлова бага нельзя опираться на hot-soft скиллы, так вы только увеличите количество багов либо сломаете то, что работает.

Cold-hard скиллы - уровень дисциплины и расчетов, объективность и числа. Hot-soft скиллы - уровень идей, фантазий, рассуждений и субъективности.

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

Зная это, как вы ответите на этот вопрос теперь? А менторство, это какой скилл из четырех? Почему компании стали чаще требовать выход в офис?

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

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

Еще раз поговорим о софт-скиллах.

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

Проблема тут в том, что та самая “токсичность”, от которого вы хотите отгородиться навсегда - никогда не исчезнет из вашей жизни. Это значит то, что раньше было для вас нетоксичным - скоро станет таковым.

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

Точно так же у нас есть ментальный иммунитет. Что-то нам нравится и иммунитет это впускает, а что-то раздражает и иммунитет противится этому.

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

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

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

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

Конечно исключение - опасность жизни. Но тут уже не до прокачки софт скиллов.

Скиллы - способность удовлетворять потребность. На основе популярной работы Маслоу предлагаю разобраться, как нам это может пригодиться в работе.

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

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

Разделим хард скиллы и разберемся что к чему. ⬇️

⬆️ Иногда разрабы решение ценностных проблем сводят к хард скиллам, как и удовлетворение физических. Так и есть, но они решаются разными способами и бывает одно конфликтует с другим. Физические потребности проекта - решать текущие насущные его задачи, либо формулировать те задачи, которые насущны сейчас. Грубо говоря - потребности юзеров. Ценностные потребности проектов - решать вопросы будущего, то есть удовлетворять потребность разработчиков. Если первое - дисциплина, второе - пассионарность.

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

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

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

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

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

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

Или к примеру замыкание в ментальном плане, когда вы чересчур много вопросами задаетесь и не делаете ничего, только дергаете коллег.

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

Разобраться с потребностями и скиллами сейчас еще важней, чем было раньше. Из-за распространения AI.

Думаю читателям очевидно, что AI нужен как раз для удовлетворения потребностей, тех, что разрабы (в частности) не смогли утолить. И тут неумелые люди могут подложить себе свинью. AI максимум может закрыть потребности физического плана, но у него нет (пока) навыков планов выше. Неумелые же люди могут решить, что AI закроет все потребности, от чего велик соблазн полениться и забить на эмоциональные, ментальные и ценностные планы. Когда вы самостоятельно решаете задачи физического плана, хотите вы или нет, вы заметите и другие потребности со временем. Если вы хотите развиваться конечно. Такое внимание будет стимулировать вас развиваться и на уровнях выше. Чересчур эксплуатируя AI вы ненароком можете отрезать от себя каналы мотивации. Типа как отрезать руку, чтобы робот за вас все сделал.

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

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

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

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

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

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

Вот этим интересным видео хочу поделиться на тему скиллов коммуникации и попробовать посмотреть с перспективы потребностей. Видео как раз основном на тему работы.

Автор делит людей на 4 цвета и утверждает, что секрет успеха в общении разговаривать на их языке:
- Красные - для читателей этого канала это пассионарные, нацеленные на результат и цель.
- Желтые - общительные, нацеленные на веселие и энтузиазм.
- Зеленые - эмоциональные (Прим. автора канала: должны быть синими), нацеленные на комфорт и спокойствие.
- Синие - дисциплинированные (прим. - должны быть зелеными), нацеленные на порядок, структуру и логику.

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

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

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

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