Когда меня спрашивают про мой опыт работы программистом, в частности про время потраченное от первого до последнего рабочего куска кода, я привык отвечать — «От пары лет, до пары месяцев». До текущего момента этот ответ был довольно странный, но имеющий право на жизнь, ибо может показаться, что полученный опыт работы «IT-шником-одиночкой» (кем я и был до недавнего времени) не в IT компании довольно сложно применить к боевой разработке и в расчет к опыту профессиональной деятельности применяться не должен, но это не так. Недавно мне довелось перечитать один из бестселлеров трилогии дядюшки Боба -«Идеальный программист» и сквозь призму времени, довольно странного опыта и изученного материала я готов обозначить, пожалуй, главные навыки, которые должен иметь, либо развивать «Идеальный программист». Данный список является несколько абстрактным, что делает его применимым не только для разработки, но и для других сфер.

1. Старайся стремиться к профессионализму

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

  1. Алгоритмы и структуры данных. В подавляющем большинстве случаев, рядовой разработчик не сталкивается с прямой надобностью использовать алгоритмы их в том виде, в котором они изложены в учебных пособиях, но их присутствие практически в каждой строчке кода в том или ином виде — бесспорна. Банальное грамотное оперирование командами if и else закладывает в Ваш фундамент профессионализма кирпичик базового познания.

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

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

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

2. Научись говорить НЕТ

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

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

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

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

3. Научись говорить ДА

Во-первых, это большая ответственность, сказать да. Во-вторых, как и в предыдущем примере, при принятии решения необходимо время. Обычно перед выбором ответа, я задаю себе следующие вопросы:

  1. Это срочно?

  2. Это важно?

  3. Это зависит от другого человека?

Первые 2 вопроса нужны для определения важности дела по матрице Эйзенхауэра, что позволяет разбить положительный ответ разные временные рамки, в противном случае пробрести аргументы для отрицательного ответа и определения новых рамок посредством переговоров. Третий вопрос позволяет мне добавить в конечный ответ обещание либо с конечной целью (в случае с отсутствием зависимости), либо с обещанием действия для достижения этой цели. В любом случае говорить да легче, чем нет, но этот ответ должен быть с чётким пониманием и готовностью взять на себя ответственность, чтобы при следующем общении у собеседника не возникло сомнений в надежности этих обещаний.

4. Умей справляться с давлением

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

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

  2. Умение контролировать свои обязательства. Помимо текущей задачи, скорее всего, у вас имеются и ряд других. Конечно, в критических ситуациях стоило бы пересмотреть приоритеты и сообщить об этом всем причастным, но для этого должна быть очень веская причина. Также стоит довериться своим собственным правилам, которые определяются индивидуально. Это может быть как и обычная физическая активность (подтягивания, бег), так и специфические методики по типу ведения документации проекта через PHPdocumentor. В любом случае у вас есть хорошая предметная база с фаворитами, которые помогут в таких ситуациях.

5. Цени время

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

Итог

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

Комментарии (4)


  1. amarao
    06.10.2021 16:19

    Идеальный для кого? Что является метрикой?


    1. Black4Cloud Автор
      06.10.2021 20:49

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


  1. ChePeter
    06.10.2021 16:26

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

    1. Алгоритмы и структуры данных...."

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

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

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

    А сортировка это наш мир - логика, алгоримы, предикаты и т.д.


    1. Black4Cloud Автор
      06.10.2021 21:18

      В это понятие был внесен более простой смысл, а точнее - как один из элементов в контексте необходимого технического минимума для "идеального" разработчика.