Какие личностные качества нужны разработчику?

Original author: Ewa Mitulska-Wójcik
  • Translation

Начинающий программист Ewa Mitulska-Wójcik описала в недавней публикации на Медиуме свои мысли о необходимых разработчикам личных качествах. Публикуем перевод этой заметки и небольшой комментарий в самом конце.


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



Коммуникабельность


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


Вот некоторые повседневные коммуникативные задачи, с которыми вам придётся столкнуться, как разработчику.


  1. Делиться возникшими проблемами с другими ребятами в команде.
  2. Отчитываться о деталях прогресса в системе управления проектами, вроде Jira.
  3. Выражаться ёмко и конкретно, насколько возможно, когда этого требует ситуация.
  4. Уметь слушать и быстро реагировать
  5. Чётко объяснять все потребности, сомнения, риски и прогресс проекта в понятной остальным членам команды, менеджеру или клиенту форме.
  6. Объяснять технические проблемы так, чтобы вас понимали клиенты и члены команды, не связанные с технической частью.
  7. Полное профессиональное владение английским. Знать больше одного иностранного языка — всегда плюс. Я за испанский ;)
  8. Открыто высказываться о проблемах, заниматься поиском решений до появления конфликтов.
  9. Приводить состоятельные аргументы в пользу предложенных вами технических решений
  10. Дотошно относиться к коду, документации, отчетам и тикетам.
  11. Быть готовым к общению с другими программистами на форумах, в блогах и на конференциях. Делиться своими знаниями и не бояться выступать с микрофоном перед большой аудиторией.

Это только несколько ситуаций, когда коммуникативные навыки имеют решающее значение.



Любопытство


"Много будешь знать — скоро состаришься" — это не про разработчиков. Желание всё знать — самое реактивное топливо для новых изобретений и саморазвития. Экспериментаторство помогает видеть картину в целом и находить новые решения.


Вы можете получить ценный опыт, проверяя свои гипотезы. Задавайте вопросы, создавайте что-то новое, применяя уже полученные знания, продолжайте сегодня развивать то, что начали вчера. Не бойтесь пробовать. Даже если ничего не получится, вы ничего не потеряете. Почему? Потому что вы набираетесь опыта.


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


Делитесь своими способами мышления и наблюдениями на форумах, пишите о них посты и делитесь тем, что узнали.


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


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


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



Выработка стратегии


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


Быть хорошим стратегом — значит замечать подводные камни до момента столкновения с ними.


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


Непрерывное обучение


Разработка — плохая карьера для интеллектуальных лентяев. Если вы мечтаете о стабильной, хорошо оплачиваемой работе без особых усилий, даже не пробуйте! Специализация в одной области будет приносить хороший доход, только если вы остаетесь открытыми к новому и готовы учиться.


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


Со временем некоторые фреймворки и языки становятся более популярными, а вы можете увеличить заработок, зная какие языки, фреймворки и библиотеки более востребованы.


Быть открытым новым идеям также означает быть терпимым и проявлять уважение и инициативу. Не будьте хейтером React'а только потому, что не знаете его и работали на Angular последние несколько лет. Отрывайтесь иногда от монитора и ходите на конференции, митапы. Общайтесь с другими разработчиками в реальности и оффлайн. Оставайтесь голодными! Оставайтесь безрассудными!



Предпринимательское мышление


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


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


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


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


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




Путешествие без цели интересно, но оно не лучше прогулки. Я начинающий разработчик и знаю, кем хочу стать.



А каким хотите стать вы? С каким типом разработчика идентифицируете себя вы? Насколько вы уверены, что движетесь в правильном направлении как новичок? Если вы работаете годами программистом, чего вы достигли?


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


(Перевод Наталии Басс)




Комментарий редактора: Хочу добавить кое что от себя. Эта статья в целом будет полезна многим, она поднимает важные вопросы. Общение, умение слушать и объяснять, публичные выступления и близость к бизнесу это на самом деле крутые качества. Большинство компаний, особенно не очень больших, и выпускающих собственные продукты, ищут именно таких специалистов. Но и у переводчика, и у меня возникли не совсем приятные ощущения от некоторых особенностей и мотивов.


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


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


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


Настоящие программисты получают удовольствие от программирования.

Only registered users can participate in poll. Log in, please.

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

  • +10
  • 24.6k
  • 9
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

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

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

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

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

      0
      Делиться возникшими проблемами с другими ребятами в команде.

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

      Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
      +1
      В принципе это статья не только для программиста, просто её писал програмист. Если подставить другую профессию, то тоже хорошо пойдётю
        0
        Коммуникабельность важна, поскольку бывает полно ситуаций, когда разработчики друг друга не слышат. Например, пытаются доказать свою правоту до конца, вместо того чтобы сосредоточиться на решении задачи. Или ситуации, когда боятся сказать реальные оценки сроков задач, или вовремя сообщить о какой-то проблеме команде/менеджеру (проект не нравится, стул не удобный, коллеги достали и т.п.). Но, если ты интроверт, это не значит что с коммуникацией проблемы. Можно общаться мало, но уметь это делать так, чтобы команда тебя понимала и получать желаемый результат.

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

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

              +3
              Единственное то что меня напрягает в моей работе так это как раз — общение. Говорить с коллегами и тем более с начальством составляет большой труд. Так или иначе я хороший разработчик и берут меня на работу без проблем, платят достойно и хорошо относиться. Как можно уже догадаться большую часть времени вообще почти не разговариваю ни с кем и считаю что описанные в посте рекомендации не предоставляют весомой пользы если ты знаешь своё дело хорошо
                +1
                Такое допустимо только если перед вами список тикетов. Если вам надо планировать архитектуру, управлять командой или выравнивать процессы с девопсом, без подвешенного языка не получится.
                0
                Личностные.

                Only users with full accounts can post comments. Log in, please.