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

Введение

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

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

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

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

Уважение

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

Скромность

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

Доверие

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

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

Я — незаменим

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

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

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

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

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

Заключение

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

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

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

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

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 6 146 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 27

    +10

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

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

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

        +8
        Это смотря какого уровня программист-одиночка — некоторые умудряются в одно лицо писать ПО на миллионы долларов.
          0
          linux, nginx?
          +3
          Менеджеры ещё нужны, и аджайл-коуч. Вообще программист, если так подумать, профессия вымирающая, роботы скоро будут всё писать, или даже вот, идея на миллион, а что если сделать систему, где не надо будет программировать, а например любой пользователь сможет нарисовать блок-схему из квадратиков, а по этой схеме компьютер поймет, что от него хотят. Назовем её, no-code, например. Патентуйте!
            +2
            Это же сарказм?)
              0

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

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

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

            +10
            Половина open-source middleware в одиночку разрабатывается :-D
              +15
              Практически десятки лет пишу ПО в одиночку (именно пишу, не продаю, не обслуживаю) и я не вижу никакой возможности создавать некоторые классы ПО иначе, чем командой одиночек — именно так… И не надо кивать на аджайл и прочее. Просто если вы рабочий в цеху ИТ, то для вас кажется, что работа ведется командой, но если вы конструктор (архитектор) чего-то реально сложного (а не интерфесы, жабаскрипт и вот это вот всё) — вы одиноки, просто потому, что нет людей, которые бы вас понимали.
                +1
                это очень грустно, когда архитектора никто не понимает
              • НЛО прилетело и опубликовало эту надпись здесь
                  +3
                  Многим из нас, и мне в том числе, стоило бы это перечитывать. В особенности перед совещаниями. Хочу работать в коллективе, где культивируются уважение, скромность и доверие. Кто бы поведал, как такие коллективы создаются.
                    –1
                    Кто бы поведал, как такие коллективы создаются.

                    Это несложно, достаточно стать тимлидом и набрать людей по своим критериям.
                    0
                    Тимлидов больше нет. Расходимся.
                      +5
                      полный гитхаб проектов написанных в одно лицо. Среди них есть и большие. Это не значит, конечно, что надо быть подозрительным, хамоватым нарциссом, но тем не менее
                        +4
                        Типичные мантры бизнеса. Ещё бизнесу нравятся самоорганизующихся команды. Слишком идеально чтобы применять на практике.
                          0

                          Фриланс? ;)

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

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

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

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

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

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое