Как я перестал ненавидеть и полюбил разработку

Статья Страх и ненависть в IT ^[1] заставила меня грустить. Отнюдь не потому что я разделяю чувства автора, но потому что их разделяет множество хороших разработчиков, убивая себя, свои проекты, индустрию и человеческий прогресс в целом. Вот маханул, а?

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

Дисклеймер

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

Чрезмерная сложность

Автор исходной статьи подчеркнул очевидную вещь: разработчик больше не контролирует работу своего решения. Для многих это было очень комфортно, давало чувство спокойствия и контроля. И этот комфорт остается точкой отсчета: до сих пор, несмотря на переход из разряда творцов в разряд ремесленников, программист всё ещё пытается получить удовольствие от процесса сотворения чего-то из ничего. Используя чужие творения этого удовольствия не достичь, ты чувствуешь себя в лучшем случае мозаистом ^[2], удачно подобравшим камешки. (Но мозаика тоже искусство, что же здесь не так? Хмм...).

Примите неизбежное. Только избранные персонажи мифов могли создавать планеты из ничего. Использовав подходящие компоненты, применив известные подходы и как следует подумав, можно создать элегантную систему и получить удовольствие сравнимое с таковым от «чистого» творения. И это сработает на любом уровне: от нового enumeration'а до дизайна high-load системы.

Технически всё не так радужно. И виной тому две вещи: время и коллеги. Наши решения должны удовлетворять двум критериям: расходы должны быть ниже предполагаемой среднесрочной выгоды, а стоимость поддержки — ниже долгосрочной. Поэтому при существующих объемах разработки мы неизбежно приходим к решениям вроде «используем везде этот клиент»: это быстро, и вся команда умеет с ним работать. А если клиент достаточно популярный, то и будущие члены команды будут уметь. Ищите баланс между крайностями возвышенного созидания и бездушной конвейеризации, получайте удовольствие от его нахождения!

Слишком много всего и Собеседования

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

Каждый раз, когда я читаю очередную историю боли от собеседования «они хотят знать полный список изменений в ES6», я грущу. Они хотят знать только одно: подойдете ли вы их команде. И «они» это мы же, лишь с другой стороны стола. Мы не умеем это спросить, и не умеем ответить.

Разрывайте этот замкнутый круг непонимания! Перестаньте проходить собеседования и начните искать работу под себя. Говорите что думаете. Примите, что подходящая вам команда — одна из двадцати. Найдите её.

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

Айтишники

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

Примите: люди разные. Если вам нужны люди — ищите «своих».

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

Бизнес

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

Только разработчик в ответе за костыли в решениях. Только бизнес (в лице PO, PM, директора и т.д.) в ответе за провалы проектов. И здесь нужно много сил. Научитесь рассчитывать цену быстрых решений. Научитесь доказывать, что экономия месяца сейчас приведет к двум месяцам перерасхода уже завтра. Или не приведет. Примите, что хороший код не решает проблем сам по себе, но и бизнес не хочет хоронить себя в техническом долге!

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

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

О себе

В 20 я кодил сутками и с удовольствием ходил на работу.
В 25 я видел как всё плохо и страдал, ожидая пятницу и пет-проект в котором всё хорошо.
В 30 я увлечен работой… с радостью встречая пятницу и выходные.

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

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

Пока никто не сказал, хотя я иногда загоняю некоторых коллег в этот угол :)

Автор: DrFdooch

Источник ^[3]