Статья Страх и ненависть в IT заставила меня грустить. Отнюдь не потому что я разделяю чувства автора, но потому что их разделяет множество хороших разработчиков, убивая себя, свои проекты, индустрию и человеческий прогресс в целом. Вот маханул, а?
Каким бы я ни был увлеченным футуристом и адептом автоматизации, эта статья о более приземленных, чем Светлое Будущее, вещах. Поэтому судьбу человечества оставлю на следующий раз. Сейчас я хочу наконец высказаться об огромных объемах негатива, боли, страха и ненависти, таящихся в глубинах IT-сообщества, прикрытых небольшим теплым слоем хайповых технологий и крутых инженерных решений.
Дисклеймер
Из собственного опыта я знаю, насколько сложно применять то, о чем пойдет речь, в аутсорсе, особенно на огромных проектах. Не хочу, чтобы большинство разработчиков сейчас подумали «ну понятно» и закрыли статью, но завлекать не умею, а обманывать тоже не хочу. Поэтому прошу вас: продолжайте, не всё так плохо.
Чрезмерная сложность
Автор исходной статьи подчеркнул очевидную вещь: разработчик больше не контролирует работу своего решения. Для многих это было очень комфортно, давало чувство спокойствия и контроля. И этот комфорт остается точкой отсчета: до сих пор, несмотря на переход из разряда творцов в разряд ремесленников, программист всё ещё пытается получить удовольствие от процесса сотворения чего-то из ничего. Используя чужие творения этого удовольствия не достичь, ты чувствуешь себя в лучшем случае мозаистом, удачно подобравшим камешки. (Но мозаика тоже искусство, что же здесь не так? Хмм...).
Примите неизбежное. Только избранные персонажи мифов могли создавать планеты из ничего. Использовав подходящие компоненты, применив известные подходы и как следует подумав, можно создать элегантную систему и получить удовольствие сравнимое с таковым от «чистого» творения. И это сработает на любом уровне: от нового enumeration'а до дизайна high-load системы.
Технически всё не так радужно. И виной тому две вещи: время и коллеги. Наши решения должны удовлетворять двум критериям: расходы должны быть ниже предполагаемой среднесрочной выгоды, а стоимость поддержки — ниже долгосрочной. Поэтому при существующих объемах разработки мы неизбежно приходим к решениям вроде «используем везде этот клиент»: это быстро, и вся команда умеет с ним работать. А если клиент достаточно популярный, то и будущие члены команды будут уметь. Ищите баланс между крайностями возвышенного созидания и бездушной конвейеризации, получайте удовольствие от его нахождения!
Слишком много всего и Собеседования
Выбрать идеальный компонент для текущего решения маловероятно. Даже если он существует — он один из тысячи. Каждый разработчик/команда/компания выбирает что-то под себя, учится обходить подводные камни… и начинает требовать этого же опыта от других. Это глупо. Так же глупо, как цепляться за утерянный контроль над своим творением.
Каждый раз, когда я читаю очередную историю боли от собеседования «они хотят знать полный список изменений в ES6», я грущу. Они хотят знать только одно: подойдете ли вы их команде. И «они» это мы же, лишь с другой стороны стола. Мы не умеем это спросить, и не умеем ответить.
Разрывайте этот замкнутый круг непонимания! Перестаньте проходить собеседования и начните искать работу под себя. Говорите что думаете. Примите, что подходящая вам команда — одна из двадцати. Найдите её.
Перестаньте искать человека, который знает то же самое, и начните искать того, кто даст вам что-то новое. Спрашивайте то, что для вас важно. Примите, что задавая вопросы на знания, вы просто составляете подробное резюме. Найдите того, кто будет говорить с вами на одном инженерном языке, разделять ваши принципы и подходы к разработке.
Айтишники
Тоже люди. Люди — разные, и при этом ксенофобы; вполне себе полезная черта с точки зрения естественного отбора. Она не помогает при работе в коллективе, и мало что можно с этим сделать: клетчатым будет интересно играть в свои игрушки вместе, хардкорные инженеры будут, перебрасываясь парой слов, создавать вместе вечные вещи.
Примите: люди разные. Если вам нужны люди — ищите «своих».
С менеджерами связано, наверное, максимальное количество ненависти. И здесь снова мы в замкнутом круге: менеджер не хочет или не может выполнять свою работу — и поэтому мы от него отворачиваемся и делаем всё сами. Он ведь всё равно бесполезный. Вот этот вопрос и переходит в
Бизнес
Много копий сломано на поле битвы Бизнеса с Технологиями. Не хочется повторяться, поэтому я опущу большой кусок контекста и перейду сразу к основной мысли.
Только разработчик в ответе за костыли в решениях. Только бизнес (в лице PO, PM, директора и т.д.) в ответе за провалы проектов. И здесь нужно много сил. Научитесь рассчитывать цену быстрых решений. Научитесь доказывать, что экономия месяца сейчас приведет к двум месяцам перерасхода уже завтра. Или не приведет. Примите, что хороший код не решает проблем сам по себе, но и бизнес не хочет хоронить себя в техническом долге!
Вы можете отказаться играть в булшит-бинго. Называйте вещи своими именами до того как они вас достанут и вы станете называть их прекрасными.ит именами. Разработчик может себе позволить быть честным — у него нет бюджета и нет ответственности. В крайнем случае разработчику легко найти новую работу, где честности боятся чуть меньше. Дайте свое честное экспертное мнение по поводу проблемы и решения, и позвольте бизнесу решать. И отличайте нежелание решать от поиска решения. Мы приучили бизнес к тому, что можно сделать быстрый хак. Они знают, что если немного надавить, мы дадим результат в пять раз быстрее. Это отказ от решения, и мы не должны потакать такому поведению. Менеджер в поисках решения будет декомпозировать и приоритизировать, пытаясь показать результат в свои сроки. И в этом мы обязаны помочь.
Разработчик должен разбираться в бизнесе ровно настолько, чтобы время на формулировку вопросов и понимание ответов было сравнимым со временем поиском технического решения. Мы больше не можем сказать «дайте мне спеку и я всё сделаю», такая спека и есть почти всё решение. Наша работа больше не в переставлении байтов вручную, у нас теперь намного больше времени на анализ всей картины. Но мы и не должны принимать «вот там пачка задач, разберитесь чего там и как». Бизнес очень часто экономит время на поиске бизнес решения, и задача разработчика увидеть, что разрабатывать-то и нечего, и указать на это бизнесу. Это тяжелый труд, и подойдет не каждому.
О себе
В 20 я кодил сутками и с удовольствием ходил на работу.
В 25 я видел как всё плохо и страдал, ожидая пятницу и пет-проект в котором всё хорошо.
В 30 я увлечен работой… с радостью встречая пятницу и выходные.
Я не знаю, что будет еще через 5 лет, но надеюсь что не разочаруюсь в текущих убеждениях.
Наша область дает нам очень многое — свободу самовыражения, развитие, знания, интересный опыт и приличные деньги. Наша область очень молода, это всё еще ремесло, и у нас нет за плечами династии ремесленников-предков. Мы пока не знаем как в ней работать. Поэтому мы злимся, страдаем и выгораем.
Мое решение — презумпция разумности. Я больше не делаю выводов о человеке по его коду, е-мейлам или таскам в джире. Даже больше, я стараюсь не думать плохо из-за того что он говорит или делает. Ведь пока мы работаем над общим делом, и пока он не сказал прямо «я хочу навредить проекту», он мой союзник, и вместе мы можем больше чем поодиночке.
Пока никто не сказал, хотя я иногда загоняю некоторых коллег в этот угол :)
Автор: DrFdooch
