Рефлексия – штука любопытная. Еще интересней, если она базируется на многолетнем опыте. Под катом рассказ о судьбе программиста устами директора по разработке Parallels RAS Игоря Марната от первого лица. Enjoy!
«Если вы не двигаетесь вперёд, то вы не стоите на месте. Мир движется вперёд, а вы - нет. Тем самым, вы двигаетесь назад!». © (Кто-то очень умный)
Эпиграф
Для меня программирование до сих пор не стало рутиной, хотя я занимаюсь разработкой больше двадцати лет. Думаю, это связано с тем, что я предпринимал определённые действия до того, как мой запал окончательно иссяк.
Если программирование стало для вас рутиной, то, возможно, мой опыт будет вам полезен. Хотите, чтобы что-то изменилось? Надо хотя бы что-то менять (глубокая мысль, не правда ли?). Надо куда-то двигаться. И вот, в разное время, я пробовал движение вглубь, движение вбок и движение вширь.
Движение вглубь
Особенность нашей работы в том, что каждый разработчик должен быть специалистом в двух областях — программировании, как таковом, и в той предметной области, для которой он создает программное обеспечение. Чем лучше и глубже разработчик разбирается в этих двух сферах, тем более интересные задачи он сможет решать. Чем интереснее и масштабнее задачи, тем более заметный получается результат.
Программисты, в большинстве своем, черпают мотивацию в верхних уровнях пирамиды Маслоу — познание, самореализация, потребность в уважении. Для этого необходимо, чтобы, во-первых, результат их работы был заметен. Во-вторых, этот результат должен увидеть свет, им должны пользоваться люди. Видимость результата, очевидно, тесно связана с размером этого результата, с его значением, весом.
Во времена разработки программного обеспечения для телекома, я вложил много времени и сил в изучение новой для себя предметной области: устройство процессоров общего назначения и DSP, памяти, систем хранения, сетевых протоколов, видов сигнализации, алгоритмов обработки сигналов, в общем, кучу разных интересных вещей из телефонии, схемотехники, сетей.
На это ушло несколько лет (в течение которых я работал заметно больше восьми часов в день). Лет через пять я работал на уровне архитектора, участвуя в создании структуры программного обеспечения новых телефонных станций, архитектуры их компонент. Кода я писал меньше, занимаясь разработкой спецификаций для команды, ревью сложного кода, работой над некоторыми критическими компонентами, протоколами и драйверами. Хорошее понимание устройства каждого компонента, принципов его работы, связи с остальными позволяет заниматься разработкой архитектуры продукта, протоколов связи, внешних интерфейсов.
Очевидно, любой программный продукт — результат работы всей команды, но при своем уровне участия в проекте я чувствовал себя причастным к созданию не отдельных компонентов, а продукта целиком. Драйв при этом получаешь неимоверный, ответственности тоже больше.
В общем, чем глубже программист погружен в предметную область, с которой он работает, чем лучше владеет контекстом, чем шире его кругозор, тем интереснее он может сделать свою работу.
Это относится не только к внутреннему устройству компонентов продукта. Чем лучше вы будете знать своих пользователей, то, как они используют продукт, почему так, а не иначе, какие у них бывают проблемы, как устроены продукты конкурентов, тем интереснее вам будет работать.
Узнать всё это просто — нужно больше общаться с командами поддержки, тестирования, внедрения, с конечными пользователями продукта. Если удастся наладить рабочее взаимодействие, порешать для них какие-то задачи, поучаствовать в совместной работе – то вообще супер.
Кстати, тут есть еще одно замечание по поводу организации самого рабочего процесса, которого придерживаются, в частности, философия DevOps и подход к разработке и operations известный как SRE, изначально пришедший из Google. Необходимо стремиться устранить разделение между командами разработки, внедрения и поддержки, движение к совместной работе.
На всякий случай, отмечу, что RFC, книги с животными на обложке, документация производителей, переписка в большинстве сообществ open source используют английский язык в качестве стандартного средства общения. Информации в переводах меньше, она зачастую искажается и почти всегда запаздывает. Многие производители вообще не заморачиваются переводами документации. Поэтому, как минимум, способность читать книги на английском языке — довольно базовое, так сказать, санитарно-гигиеническое требование к разработчику, который хочет развиваться.
Движение вбок
Во многом интерес программиста к его деятельности определяется интересом к предметной области, в которой он работает. Например, вам может быть скучно работать с финансовыми приложениями, но будет интересно работать над инфраструктурой для работы таких приложений.
Параллельно с разработкой встраиваемого ПО для телефонии я работал над распределённой системой сбора информации и выставления счетов пользователям – и это совершенно другой мир, другие языки, другие платформы. Рядом — автоматизация развёртывания, конфигурирования и тестирования, это уже третий мир, всё снова другое.
Возможно, для оживления вашей заинтересованности вам стоит поговорить с коллегой или начальником, посмотреть, чем занимаются команды рядом. Даже небольшой шаг в сторону от привычной деятельности может многое изменить в вашей работе, дать вам иной взгляд на вещи. Как говорится, точка местонахождения определяет угол зрения
Движение вширь
По мере погружения в телефонию оказалось, что я не успеваю уделять достаточно времени и внимания другим проектам, над которыми я работал. Выход был очевиден — я стал работать еще больше. Но масштабируется это не сильно. При долгой работе по ночам и выходным через какое-то время и работать уже не хочется, и жить некогда. Мы с шефом приняли решение — нанять еще одного программиста в нашу команду. Я довольно самонадеянно провёл пару собеседований с наскока (первых в своей жизни по другую сторону стола), и понял, что взять толкового человека к себе в команду не так просто, как кажется.
Как понять незнакомого человека за короткое время? Как оценить его профессионализм и личные качества? Они вообще важны, эти личные качества? Или важен только профессионализм? На что вообще нужно обращать внимание при найме? И как именно его обращать? Сейчас всё это кажется довольно очевидным, но при найме первого инженера для меня - это был для меня настоящий тёмный лес.
Как обычно, я начал с Google. Нашёл несколько статей Джоэла Спольски, проглотил их, прочитал книги, на которые он ссылался, затем ссылки из этих книг, пошёл учиться более системно, и так, постепенно, начал погружение в новую предметную область — управление проектами, командой, управление cамим процессом разработки.
Процесс разработки программного обеспечения, как и любой другой производственный процесс, имеет своих исследователей, историю развития, лучшие практики, подходы к организации. Многие его аспекты, связанные непосредственно с разработкой, лучшими инженерными практиками, достаточно молоды.
Например, agile появился сравнительно недавно, меньше двадцати лет назад, CI — около тридцати, классической книге Фредерика Брукса уже около пятидесяти лет. Другие же аспекты, связанные с управлением командой, психологией, мотивацией, управлением процессами в организации в целом, организацией коммуникаций - универсальны, пришли из других предметных областей уже много лет назад, и отлично применимы и в области разработки.
Я читал довольно много литературы на тему управления командой. Мне кажется, наиболее детально и глубоко эта тема изучена в Америке и Японии. Помимо классических книг о разработке, инженерном процессе, менеджменте, я бы рекомендовал книги советских и российских авиаконструкторов и конструкторов ракет. Кроме того, NASA, NAVY, Toyota — эти организации и компании вкладывают огромные средства в оптимизацию своих процессов, проводят внутренние конференции для своих менеджеров, материалы по ним доступны в сети, есть много интересных художественных книг от них и о них. Кроме того, помимо отличной информации о процессах управлении, выстроенных в этих компаниях, читать об автомобилях, самолётах, ракетах, кораблях и их разработке просто очень интересно.
В общем, простор для повышения своей компетенции в области управления огромный, задачи тоже очень разные. Начать можно с организации своей собственной работы, с внедрения лучших инженерных практик типа unit-тестов, ревью кода, continuous integration и continuous delivery, остановиться можно очень далеко. А лучше и не останавливаться:)
Заключение
Практика показывает, что если вы начнёте активно двигаться хотя бы в одном из вышеупомянутых направлений, через некоторое время неизбежно произойдет и еще одно движение — вверх по иерархической лестнице. Если такое желание есть, то это тоже очень интересный вариант. Главное при этом - не забывать о необходимом балансе между организационной и технической работой, который вы бы хотели сохранить.
Разработка софта — марафон, который длится всю жизнь. Всегда есть дедлайны, сроки, всё время надо еще чуть-чуть поднажать. Чтобы сохранить энергию и мотивацию, защитить себя от выгорания, нужно обязательно переключаться, поднимать голову над рутиной, оглядываться по сторонам и смотреть на себя и свою работу со стороны. Театры, музыка, концерты, хорошие книги и фильмы — обязательны к периодическому применению. Или дача. Или походы. В общем, что-то, кроме работы. Иначе через два-три года работа в любом случае перестанет быть в радость.
Что же касается работы, никто не позаботится о вашей мотивации и карьере лучше, чем вы сами. Честно говоря, не то, что никто не позаботится лучше — просто вообще никто не позаботится. Книги по специальности, смежным областям, конференции, общение с коллегами, митапы — движение, которое, как известно, есть жизнь.
Если вы чувствуете, что пора что-то изменить — начать можно с небольших шагов. Для этого не нужно разрешение сверху, бюджет или работа в большой организации. Все шаги, о которых я написал, выше я прошёл в маленькой компании, в командах от двух до десяти человек.
Несколько хороших книг, много желания и немного движения могут всё сильно изменить в лучшую сторону. Удачи!
З.Ы. Делитесь своим опытом и лайфхаками в комментариях. К сожалению, Игоря пока нет на Хабре, качаю карму для того, чтобы можно было его пригласить. А пока переадресую ему ваши вопросы, если такие возникнут. Спасибо за проявленный интерес.
Автор: Дмитрий Смиркин
