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

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

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

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

В конечном итоге вы рационализируете работу только с такими людьми, как вы, чтобы избежать любого дискомфорта из-за того, как вы делаете что-то.

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

Процесс защиты своей точки зрения сам по себе является обучающим опытом.

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

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

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

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

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

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

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

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

Нам ВСЕМ нужно научиться не отвергать альтернативные точки зрения.

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

В последнее время ходит мнение, что для освоения предмета нужно 10 лет. Почему программирование отличается? Через два года мы достигли высшего уровня, а через 10 готовы к работе на клеевом заводе.

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

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

Стоит ли внедрение этой «функции» усилий по поддержке, отладке, расширению, документированию и т. д.?

Какую когнитивную нагрузку эта хитрость добавляет к рассуждениям о приложении?

Насколько усложнит эта дополнительная сложность настройку среды или адаптацию нового разработчика?»

Добавление этого пользовательского сценария сборки или DSL делает так, что разработчики не могут использовать уже имеющиеся у них знания о фреймворке для выполнения своей работы?

Требует ли это, чтобы кто-то обращался к нашей проприетарной документации, а не к легкодоступной документации?

Наши документы существуют?

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

От какой ценности для бизнеса мы отказываемся, чтобы сделать что-то более сложным?

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

Облегчает ли это нашу работу или это просто способ добавить новые крутые рамки в наши резюме?

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

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

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

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

Освободите свой разум.