Ежедневные сложности сениор-разработчика

Автор оригинала: Gerard van der Put
  • Перевод


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

1. Планёрки


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

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

Однако митинги и сосредоточенность — настоящие враги. Я уже сбился со счёту, сколько раз мой планировщик отвлекал меня, сообщая, что через 15 минут мне нужно явиться на планёрку, пока я пытался разобраться в сложной концепции, которую недавно придумал. Разумеется, я заранее знал, что будет планёрка. Когда я смотрел своё расписание в понедельник, чтобы оценить время, которое у меня будет на написание кода на этой неделе, у меня не было никаких сомнений: мои рабочие дни заполнены совещаниями.

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

И знаете что? Эти знания в основном передаются на совещаниях. Поймите меня правильно, само по себе это хорошо.

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

Настала пора ещё одного совещания.

2. Огромная машина


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

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

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

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

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

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

Есть странная двойственность — с одной стороны, ты хочешь быть частью механизма, с другой стороны, остаётся какая-то горечь.

Огромная машина — это довольно странная вещь.


3. Качество кода и срок поставки


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

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

Срок сдачи проектов. Дедлайны.

Несложно понять, что качество кода и сроки сдачи не очень хорошо дружат.

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

Потому что над всеми нами нависает большая рука.

4. Проверка кода


Сразу признаю, что проверка кода (code review) является критически важной частью каждого отдела разработки. Я знаю это и соглашаюсь с этим.

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

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

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

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

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

5. Коллеги


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

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

Те, кто нам не нравится, или те, «с кем у нас не очень хорошее взаимопонимание», могут писать красивый и качественный код. А некоторые из моих друзей — не самые лучшие из разработчиков.

Но такова неизбежность при общении с людьми, с коллегами.

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

Экстравертов это может порадовать, но я не экстраверт.

Заключение


У меня есть один коллега, назовём его Ларри.

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

Дело в противостоянии его и мира. Ларри против Огромной Машины.

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

Руководство не часто спрашивает, чем он занят.

Он создаёт самые невероятные решения и алгоритмы. Одно совершенное решение за другим.

Иногда я хочу быть как Ларри. Находиться на пустынном острове посередине океана. Только я и мой ноутбук.



На правах рекламы


Эпичные серверы — это надёжные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 22

    +10
    Я часто встречал таких «Ларри» в разных компаниях. Как правило их не ценило начальство (за конфликтность), не повышали по службе и по ЗП, увольняли без особого сожаления, хотя они делали действительно крутые и уникальные вещи, которые приносили компании немалые деньги.
      +5
      хм, я видел обратное, когда разумное руководство выстраивало рабочую экосистему вокруг таких людей, прекрасно понимая, что Ларри не оценивает себя ы должной степени.
      К тому же подобные люди обычно редко меняют работу, что позволяет спокойнее спать.
      Когда вижу на собеседованиях таких «странных» людей — всегда присматриваюсь внимательнее, и часто это именно тот человек, которого мы искали.
        0
        В IT другое отношение к людям, чем в других сферах деятельности. Я раньше работал в промышленности и там таких «Ларри» руководство ненавидело — ведь ими невозможно манипулировать — они не ведутся ни на угрозы, ни на денежные посулы, ни на предложения развития, ни на другие новомодные манипуляции.
        Я, когда был молодой и глупый, тоже думал стать таким незаменимым супер-специалистом, но когда на моих глазах уволили реального крутого супер-инженера на котором держалось полкомпании делавшей мультимиллионные обороты, только потому, что он посмел попросить повышение ЗП, розовые очки спали с глаз. И я по мудрому совету Господина Дракона — «перестал думать, и стал соображать»)))
          0
          Что значит «манипулировать»? Поставьте себя на место начальства — у вас есть человек, который не масштабируется, не готов обьяснять ничего «недостойным» и от которого неизвестно чего ждать. Я работал с десятком таких «незаменимых» и это неизменно заканчивалось каким-то взрывом на ровном месте — а один раз человек буквально пытался выйти в окно, к счастью оказавшееся пластиковым и ведущим в коридор а не на улицу.
        +3
        Как правило их не ценило начальство (за конфликтность), не повышали по службе и по ЗП, увольняли без особого сожаления, хотя они делали действительно крутые и уникальные вещи, которые приносили компании немалые деньги


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

        Я например знаю случаи, когда вокруг такого «Ларри» сконцентрировалась вся работа, руководство его боготворит, зарплата выше чем у многих разработчиков, руководство идет на любые уступки, любые условия, но работать с ним сложно, у человека раздутое ЧСВ, да он приносит много денег компании, но другим сотрудникам от этого не легче.

        Для меня кажется хорошим вариантом, когда нет таких «гениев-мудаков», а есть нормальные адекватные люди, которые хорошо выполняют поставленные задачи, не придумывая каждый раз сложный алгоритм при решении обычной задачи, я не говорю, что это плохо, но иногда нужно просто решить задачу быстро и способом, которым после тебя смогут воспользоваться другие.
        +36
        Синдром несамозванца — когда ты думаешь, что ты Ларри, а ты не Ларри, а просто сыч
          0

          Вроде как есть распространённая аббревиатура: ЧСВ :-)

          +13
          Самое худшее зло синьора это местная политика. Все эти выяснения отношений, кто там на ком стоит, кто кому что обещал на словах до меня, у кого какое ЧСВ, зачем там все эти странные люди и почему они всё ещё здесь, какую дичь в системе нельзя трогать потому что кто-то там обидится, список людей с родовыми травмами на работе — вот это вот всё. Этому не учат в школах 42/21.
            +1

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

              +17

              Примерно везде.

                +1
                Встречается. Вот например разговор из жизни. Недавно пришедший синьер спрашивает у тим-лида:
                — Слушай, есть вероятность, что вот этот подход, возможно, имеет потенциал привести к дичи. Я это проходил уже однажды. Может обсудим?
                — По твоему мы это уже не обсуждали в команде?
                — Ок.
                — Но если ты конечно считаешь нужным. то обсуди это с… (дальше следует имя уважаемого синьера, давно работающего в компании), это он эти правила ввел.

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

                +6

                так это же софт скиллз, сеньоры должны иметь /sarcasm

                  +3
                  кто там на ком стоит, кто кому что обещал на словах до меня, у кого какое ЧСВ, зачем там все эти странные люди и почему они всё ещё здесь, какую дичь в системе нельзя трогать потому что кто-то там обидится, список людей с родовыми травмами на работе — вот это вот всё

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

                  Так вот. В нормальных коллективах работают правила этикета. Да, не уровня королевских семей. Но минимальный набор присутствует. Но этот минимальный набор позволяет свести проблемы общения на минимум.
                  И в таком коллектике тебя никто не оскорбит шуткой. Почему? Потому что никто не будет шутить над коллегкой, с которым не знаком достаточно близко.
                    0
                    Это точно. Когда работа начинается в обед — потому что 3/4 фирмы ночью бухали вместе и раньше просто не приползают — а тут вы такой с семьей или учебой, из коллектива выбиваетесь.
                  0
                  Я не сеньор, но постоянные митинги достают… Обычно они случаются невовремя и отвлекают от работы. А потом вообще трудно вспомнить, что делала и на чем закончила
                    +2
                    Ну, не знаю, такие люди как «Ларри» мне встречались, но редко, один или два раза. Работал у нас один разработчик, который за неделю соорудил парсер проприетарного языка программирования, использовавшегося в компании, и еще за неделю соорудил самопальный отладчик над этим хозяйством. Оно парсило исходник, после каждого оператора ";" вставляло вызов из его DLL, и это он как-то присоединил к IDE, которой он привык пользоваться. При этом в компании работало 50 или 100 программистов, по 5-7 лет, и никто ничего подобного не соорудил, всем (включая меня) хватало «отладки в стиле printf». То есть чел выдал реально крутое инженерное решение. И что? Думаете, в компании его все моментально восприняли, стали использовать, а автора повысили до старшего архитектора? Вот именно, что нет. Все покрутили головой, сказали «а, вроде интересно, но мы привыкли по-старинке», а автору продолжали выдавать текущие задачи компании, вроде 3-way merge конфигурационных XML-ок. Ему было не очень интересно заниматься этой рутиной, и он потом уволился.
                      0
                      Митинги и другие подобные мероприятия по большей части бесполезны для сеньор разработчика и ниже, если он пришёл писать код и ничего больше. Мудрое руководство не будет загружать таких кадров бесполезными для них делами. Что бы снять срез состояния проекта — достаточно задать этот вопрос тим лиду или менеджеру проекта.

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

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

                        Мне кажется, что лид несет не глас и боль народа, а собственное желание внедрить очередную управленческую пургу, о которой он недавно прочитал в рамках своего саморазвития. Это как находить в коде нафиг не нужные (и только тут запиленные) вложенные функции — «ага, Вася недавно читал whats new” очередного релиза Котлин :)

                          0
                          Бывают разные подходы, но чаще тех. лиды отвечают за чисто технические решения. А за управленческую пургу отвечают продакт менеджеры и/или скрам-мастера.
                          +1
                          Митинги и другие подобные мероприятия по большей части бесполезны для сеньор разработчика и ниже, если он пришёл писать код и ничего больше.

                          Я как-то до сих пор не встречал ни одной фирмы где от сениора ожидалось «писать код и ничего больше».

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

                          А, похоже опять разное понимание термина «сениор» :)
                            +1
                            для сеньор разработчика и ниже, если он пришёл писать код и ничего больше


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

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

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

                          Самое читаемое