"Мне не нравится программирование, но я работаю программистом" | SHIFU.IO
Переводы
"Мне не нравится программирование, но я работаю программистом"
Перевод 28.01.2018
Да, вы прочитали заголовок верно. Я – программист, но мне действительно не очень нравится программирование.

Источник: Kari McMahon

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

Я точно не тот человек, который мог когда-либо подумать в свой выходной:

«Дай-ка я возьму свой ноутбук и немного попрограммирую».

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

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

Зачем я пишу об этом?

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

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

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

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

1. Программист-эксперт.

Обожает программирование, живёт программированием, поэтому сообщество возлагает на него большие надежды.

2. «Сделай это»-разработчик.

Решает проблемы. Упорный и целеустремленный.

3. «Не думаю, что хочу быть программистом»-программист.

Заинтересован в IT, но само программирование ему не особо нравится. Не склонен к решению проблем.

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

«Сделай это»-программист

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

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

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

Если вы руководите таким типом разработчика:

  • Попробуйте найти для него возможность развиваться внутри отдела с другими программистами, если такой возможности нет – за его пределами.
  • Открыто поговорите с ним о его интересах и попробуйте выкроить время, когда он мог бы выполнять какие-то обязанности в соответствии со своими потребностями. В другое время он всё так же может продолжать работать программистом, а это значит, что вы не потеряете ценного сотрудника.
  • Не давайте обещаний, которых вы не можете сдержать. В этом случае, сотрудник найдёт другую работу, отвечающую его индивидуальным потребностям и интересам.

Будучи менеджером, учитывайте то, что у разработчика могут быть другие интересы, помимо программирования. Поэтому, если вы заинтересованы в обучении и развитии своих сотрудников, учтите, что им могли бы быть интересны не только IT-курсы, но, возможно, они хотели бы изучить digital-маркетинг, UX-дизайн, продакт-менеджмент, графический дизайн.

Программист-эксперт и его отношения со «Сделай это»-разработчиками

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

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

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

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

«Не думаю, что хочу быть программистом»-разработчик

И наконец, «Не думаю, что хочу этим заниматься»-программист.

Этот программист схож со «Сделай это»-типом программиста. Ему не особо нравится программирование, но несмотря на это, он оказался в вашей команде разработчиков. Вероятно, эти программисты не были уверены, в чём они сильны и что им интересно. Они просто выбрали наиболее доступный для них карьерный путь. В университете им могло не очень нравиться, но они думали, что могли бы попробовать стать разработчиком. На работе же они могут обнаружить, что им это нравится ещё меньше. Скорее всего, они сообщат об этом в течение 3-6 месяцев, особенно, если работают в большой компании с программой ротации персонала.

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

Итак, что же делать, если вы понимаете, что сотрудник не создан для программирования?

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

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

Перевод 28.01.2018