Смерть программиста одиночки +4


AliExpress RU&CIS

Введение

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

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

Основные принципы

Уважение, скромность, доверие - принципы, которые должны быть основой любой командной работы.

Уважение

Вы искренне проявляете внимание к тем, с кем работаете. Вы обращаетесь с ними как с людьми и цените их способности, достижения, пытаетесь понять их позицию и аргументы. Критикуя решения другого человека, вы сосредотачиваетесь не на его характере, а на желании разработать наиболее удачный продукт. Важно услышать позицию и аргументы разработчика. Так к менее уверенным в себе людям стоит применять более мягкий подход. Например основывать свои замечания на сложности восприятия для вас. То есть, не стоит подходить к коллеге и говорить: "Ну и ошибок же тут наделал, лучше было бы сделать вот так". Это может спровоцировать негативные эмоции по отношению к вам, хотя вы и были настроены на улучшение качества кода. В подобной ситуации были задеты чувства коллеги, и скорее всего он будет ощущать себя дураком. Лучше выразить эту мысль так: "Я не совсем понял поток команд, может быть стоило использовать стандартный шаблон, чтобы в дальнейшем с ним было проще разобраться и работать?". В данном примере проблема исходит от вас, это вы не понимаете код, а человек здесь не при чем. Важно не требовать, чтобы коллега обязательно поправил данный участок, а только предложить возможность улучшения для повышения читаемости при дальнейшем развитии проекта.

Скромность

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

Доверие

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

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

Я — незаменим

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

Скромность — путь к развитию

Помни о том, как ослепляет собственный успех.

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

Будьте скромными и не останавливайтесь на локальных достижениях и сравнивайте себя со специалистами мирового уровня. Это поможет вам постоянно развиваться и не останавливаться на достигнутом.

Заключение

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

Список литературы

1. Программист-фанатик. - Фаулер Ч. ISBN 978-5-4461-0846-6

2. Идеальная IT-компания. Как из гиков собрать команду программистов. - Фитцпатрик Б., Коллинз-Сассмэн Б. ISBN 978-5-496-00949-2




Комментарии (27):

  1. demon416nds
    /#22760432 / +8

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

    • peakle
      /#22761988

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

      • DrPass
        /#22762418

        К слову, сижу вот, пишу в одно рыло систему управления проектами в строительной сфере. А жена в другой комнате так же делает CRM для компании, продающей автомобильные масла. А мой брат — мини-ERP для управляющих недвижимостью компаний. И работаем мы все в одной конторе, оформленной на мою жену. А вы говорите…
        Ну да, третьи лица немного участвуют, например, дизайн мы заказываем у UI-дизайнера, плюс, Azure и деплоем заведует админ, который в этот деле шарит лучше нас. Но всё-таки это честная разработка «в одиночку».

  2. Megadeth77
    /#22760630

    На заметку тем, кто считает что в их руках — средство производства (компьютер).

  3. iiwabor
    /#22760640 / +4

    Это смотря какого уровня программист-одиночка — некоторые умудряются в одно лицо писать ПО на миллионы долларов.

  4. dipsy
    /#22760764 / +2

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

    • igor-D
      /#22761324 / +2

      Это же сарказм?)

      • NikZanyat
        /#22762148

        Вероятно, нет.
        Вот квадратики: https://m.youtube.com/watch?v=P2KQ5VA4L7Y
        Вот схема, чтобы комп понял, а кода нету:
        https://m.youtube.com/watch?v=K7RpGL35k_4

        • dipsy
          /#22762510

          Возможно это мета-сарказм, в ответ на тезисы автора поста, он ведь всё это тоже не всерьёз?

          • NikZanyat
            /#22762812

            Я пост не читал, ибо много букв и ошибки режут глаз. Прокрутил до комментариев и увидел забавное сочетание про эджайл-коучей и no-code. Триггернуло. Коучам я не доверяю ни разу, а вот по второму пункту вполне себе есть прикольные примеры.

  5. Tiendil
    /#22760836 / +7

    Половина open-source middleware в одиночку разрабатывается :-D

  6. oam2oam
    /#22760862 / +10

    Практически десятки лет пишу ПО в одиночку (именно пишу, не продаю, не обслуживаю) и я не вижу никакой возможности создавать некоторые классы ПО иначе, чем командой одиночек — именно так… И не надо кивать на аджайл и прочее. Просто если вы рабочий в цеху ИТ, то для вас кажется, что работа ведется командой, но если вы конструктор (архитектор) чего-то реально сложного (а не интерфесы, жабаскрипт и вот это вот всё) — вы одиноки, просто потому, что нет людей, которые бы вас понимали.

    • kovriga25
      /#22767016

      это очень грустно, когда архитектора никто не понимает

  7. dkuch
    /#22760896

    "Современные программы создаются командами не одиночками. Как таковое понятие гения программиста одиночки изолированного от мира и разрабатывающего что-то у себя в компьютере сейчас устарело и вымерло"


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

  8. DmitryShm
    /#22760902 / +4

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

    • JordanoBruno
      /#22761846

      Кто бы поведал, как такие коллективы создаются.

      Это несложно, достаточно стать тимлидом и набрать людей по своим критериям.

  9. ParALVic
    /#22761326

    Тимлидов больше нет. Расходимся.

  10. event1
    /#22761444 / +3

    полный гитхаб проектов написанных в одно лицо. Среди них есть и большие. Это не значит, конечно, что надо быть подозрительным, хамоватым нарциссом, но тем не менее

  11. NeverIn
    /#22761596 / +3

    Типичные мантры бизнеса. Ещё бизнесу нравятся самоорганизующихся команды. Слишком идеально чтобы применять на практике.

  12. x8core
    /#22762130

    Фриланс? ;)

  13. syusifov
    /#22763326

    Какие современные программы? Где они?

  14. igor-D
    /#22763630

    Если выразить статью одним предложением: Не веди себя по принципу «Все пи..., а я д'Артаньян».
    Ну и немного в стиле КО — объемный коммерческий проект делают команды, а не 1 человек.

  15. tvant
    /#22771560 / +1

    Хотелось бы продолжить использованное автором в начале статьи утверждение:

    Как на смену ручному производству пришло конвейерное, так на смену программисту-одиночке пришли команды. Современные программы создаются командами, а не одиночками.

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

  16. 3263927
    /#22777594 / +1

    ой не знаю, у меня такое ощущение что размер команды только замедляет разработку… столько времени уходит на документацию, регламент, требования, обсуждения, контейнеры, сервисы, что одному было бы и дешевле и быстрее, причём раз в 10…
    но есть одно но — bus factor...

    • peakle
      /#22778704

      отличный фактор кстати)) заставляет задуматься

  17. fkthat
    /#22778838

    Талантливых программистов статья бомбанет.