company_banner

Программист 2020: Терминатор отдыхает

    Программист сегодня не то что прежде — одного знания языка (или языков) программирования мало, чтобы быть действительно конкурентным на рынке труда. Ты можешь сколько угодно прописывать в коде на С++ указатель на указатель на указатель, но какой в этом толк, если твой работодатель плачет (менее ванильные ребята орут, лишают премии, угрожают и стоят на стороне клиента — в смысле живого клиента и пользователя вашей программы, а не того, что обменивается информацией с сервером)? Какое-то время назад что гаджеты, что концепции управления, что тенденции подбора персонала тяготели к одному и тому же: модульности, дискретности, а то и даже примитивизации и узкой специализации сотрудников, софта, инструментов. Но эволюция повернула не туда и теперь мир требует умные устройства, которые умеют всё, многофункциональные программы и приложения (привет, Яндекс Go) и, конечно, универсальных специалистов. Концепция «человека-оркестра» вернулась в тренд, не успев уйти из него. 


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

    ▍Структуры данных и алгоритмы


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

    Но в первые же рабочие дни на хорошем проекте начинаются проблемы и становится очевидно, что учебные задачки, которые сделали тебя классным кодером, не имеют ничего общего с кодом в продакшене. Чтобы написать хороший, профессиональный код нужно разбираться в структурах данных и алгоритмах, уметь проектировать программное обеспечение. Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д. У таких ребят две отличительных черты: 1) они упрямы и уверены в своём превосходстве; 2) они тратят адски много времени на написание того, что уже существует как структура —  я видел изобретённые заново сортировки и деревья, это страшно и странно. Молчу уже о ресурсах.

    Поэтому программист любого уровня должен легко оперировать структурами и существующими алгоритмами. К слову, HR-специалисты и CIO страшно любят использовать эти темы на собеседовании. Стоит ли превращать собеседование в экзамен, тема отдельной статьи, но факт остаётся фактом.

    ▍Бизнес-процессы


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

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

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

    ▍Математика


    Царица полей. Ну или наук, не суть. Как бы мы с вами в айтишном мире ни избегали математики, с каждым годом её важность возрастает. Ни машинное обучение, ни нейронные сети, ни искусственный интеллект без знания математики разработать не получится. И если вы, разработчик сайтов или фронтендер, сейчас хмыкнули и пошли читать следующий пункт, остановитесь, это касается всех. Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих. Поэтому, выход простой: пока не поздно, изучайте необходимый срез математики.

    У меня есть небольшой секрет, как начать: купить любую продвинутую энциклопедию для детей или научно-популярную книгу о математике и погрузиться в атмосферу, освежить базовые термины. А там пойдёт и даже затянет. 

    ▍Базовые знания в смежных областях


    Этот пункт может возмутить любого, но да — программисту и его коллегам будет лучше, если все они будут чуть больше знать о работе соседа по опенспейсу, кабинету, команде. Если вы программист, вам лучше знать какие-то основы UI/UX, фронтенда и бекенда, системного администрирования, тестирования и т.д. Это позволит выстраивать продуктивный рабочий диалог без взаимных обвинений и подозрений. Не нужно вникать в самую глубину предмета — достаточно базового учебника, онлайн-лекций и интернет-курса. Если вы реально заинтересованы в карьере разработчика, можно пройти какую-нибудь очную программу комплексной разработки ПО — там всё будет дано в умеренных объёмах, правда, чаще всего платно. 

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

    ▍Техно-трио, без которого в будущее не пустят


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

    1. Облачные технологии. Облако это не только экономия и простая масштабируемость для компаний, это ещё и огромные вычислительные мощности, которые доступны любой компании (а вот собственные сервера на такие мощности практически недоступны по стоимости и сложности управления). За облачными системами наше с вами инфраструктурное будущее. Поэтому понимание и умение использовать Amazon Web Service (AWS), Google Cloud Platform (GCP) или Microsoft Azure гарантированно увеличат стоимость программиста на рынке труда. 
    2. Микросервисы. Микросервисная архитектура решает многие проблемы безопасности, управления и эксплуатации высоконагруженных проектов, работы с огромными базами данных. Микросервисные архитектуры пока востребованы, в основном, крупными компаниями, но совсем скоро они шагнут и средний бизнес. Спрос на программиста с таким навыком будет ещё долго (пока наносервисы не изобретут).
    3. Контейнеры (пока это конкретно Docker и Kubernetes) упрощают процесс развёртывания ПО на проекте, облегчают тестирование приложений и процесс управления зависимостями, гарантируют масштабирование на лету. И самое интересное, что в отличие от микросервисов, контейнеры используют компании любого уровня, поскольку это удобно, просто в изучении и широко распространено. 

    ▍Софт скиллы не дичь какая-то


    Я люблю токсичных сотрудников компаний. Если пиарщица или менеджер проектов нервно поправляет каре и говорит, что в компании «джавист Сергей токсичный», я знаю, что скорее всего джавист Сергей угнетает коллег своим объёмом знаний, профессионально находит ошибки и из лучших побуждений их занудно объясняет, а из-за раздражения окружающих замыкается в себе и ведёт себя грубовато. Но он профи — и таких немало. Но, увы, люди — существа социальные, с тонко организованной психикой и поэтому не выносят людей без эмпатии, социального вектора и, простите, эмоционального интеллекта. Поэтому пока джавист Сергей морозится и ведёт умные разговоры с гарбадж коллектором, питонист Савелий уже и сеньор, и метит в тимлиды, и побывал на трёх конференциях, и с начальством дружбу водит, и с клиентом на выставку в Барселону летит (вы же уже поняли, что примеры выдуманные и все совпадения случайны, ведь никто в 2020 в Барселону не летит). 

    Сейчас время коммуникаций, которые чем реже, тем ценнее, поэтому записывайте, что вам нужно прокачать:

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

    У меня для вас хорошая новость: большинство из софт-скиллов установлены у человека по умолчанию, нужно просто грамотно из себя вытащить эти навыки. Не ходите к тренерам и коучам, 2-3 базовые книги по организационной психологии, конфликтологии и социальной психологии сделают вас продуманным собеседником. 

    Вообще интересно развивается наша жизнь: я сейчас вспоминаю, какими прорывными были Google Glass, как чётко зашли Pokemon Go, как взлетели и тут же рухнули разные системы управления проектами. Это были волны хайпового спроса, спроса на трендах. Поэтому перечисленные навыки программиста в 2020 году кажутся такими «кондовыми»: они долгосрочные, а не на пару сезонов. То есть с ними можно дожить примерно до 2030 года без особого напряга. А остальной мир держится на этих слонах. Ну а языки программирования, конечно, черепаха под слонами, основа основ.  

    К чему это мы? С днём программиста, друзья! Вы меняете жизнь к лучшему с помощью кода, вы делаете требования рабочими приложениями, ты читаете ТЗ между строк и знаете, что думает заказчик или тимлид. Любите свою работу, растите над ней и над собой и пусть не будет пропущена ни одна «;». Всем hello word и меньше багов.
    RUVDS.com
    RUVDS – хостинг VDS/VPS серверов

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

      +2

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

        +13
        Статья понравилась, поэтому не упущу возможности попридираться.
        «любой разработчик должен разбираться в бизнес-процессах».
        Что это за бизнес-процессы разработчик поймет уже во время работы, а не поняв — не сможет написать что-то здравое.
        «изучайте необходимый срез математики».
        Какой именно? Когда наш программист узнает какая математика ему нужна — будет уже поздно. Математика большая. Очень. А база дается всем в институте на первых двух курсах.
        «2-3 базовые книги по организационной психологии, конфликтологии и социальной психологии сделают вас продуманным собеседником».
        А две-три книги по самбо, карате и боксу сделают вас нормальным рукопашником. )
          0
          Какой именно?

          Матлог, конечно же!


          Эта база даётся, кстати, очень мало кому.

          +11
          Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих.
          И прикручиваться этот функционал будет парой строчек обращения к готовому фреймворку/библиотеке, а математикой лежащей в основе будут заниматься разработчики фреймворка.
          У меня есть небольшой секрет, как начать: купить любую продвинутую энциклопедию для детей или научно-популярную книгу о математике и погрузиться в атмосферу, освежить базовые термины. А там пойдёт и даже затянет.
          Что бы без профильного образования разобраться в математике на уровне необходимом для понимания работы тех областей о которых Вы писали выше, на это надо потратить не один год регулярных занятий.
          И надо хорошо понимать, что Вы планируете изучать и зачем, иначе эти сотни часов занятий будут потрачены впустую.
            +9
            Но в первые же рабочие дни на хорошем проекте начинаются проблемы и становится очевидно, что учебные задачки, которые сделали тебя классным кодером, не имеют ничего общего с кодом в продакшене. Чтобы написать хороший, профессиональный код нужно разбираться в структурах данных и алгоритмах, уметь проектировать программное обеспечение. Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д.
            Это забавно. Контекст: PHP, на некоторых галерах PHP + Python, немного JS. Сколько не менял рабочих мест, аутсорс, продуктовые компании, проекты вроде платёжных систем, бэк для кассовых систем и т.п., нигде не получалось толком осознанно применить алгоритмы и структуры данных. И единственное где их удаётся применить — это программистические (учебные) задачки, которые как раз ничего общего с кодом в продакшене не имеют. Мне вот тупо любопытно, это у меня одного так, или это распространённый кейс?
            Микросервисы. Микросервисная архитектура решает многие проблемы безопасности, управления и эксплуатации высоконагруженных проектов, работы с огромными базами данных. Микросервисные архитектуры пока востребованы, в основном, крупными компаниями, но совсем скоро они шагнут и средний бизнес. Спрос на программиста с таким навыком будет ещё долго (пока наносервисы не изобретут).
            А это случаем не отголоски хайпа, которые добавили в статью просто чтобы символов до норматива добрать?
              0

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

                +1
                Вот, исключительно ради собеседований и я поддерживаю это всё в памяти, решая головоломки которые предполагают использования алгоритмов.
                +5
                Если бы не было распространенным кейсом, то таких приколов бы не было:image

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

                Я бы и сам с удовольствием на работе писал бы алгоритмы, т.к. это и интересно и для мозга тренировка. Но, реальные задачи совсем другие.
                  +2
                  Мне вот тупо любопытно, это у меня одного так, или это распространённый кейс?

                  Первый случай — если компания с крупными R&D отделами, то и алгоритмы и математика в ней будут. В поисковиках с такими задачами сталкиваешься. Не то чтобы каждый день, но периодически во что-нибудь влипаешь.
                  Второй случай — считается, что железо дешевле программистов, но иногда у разросшейся компании наступает момент, когда оказывается выгоднее заняться оптимизацией, а не закидывать пожары железками. И в такие времена всплывают все аккуратно разложенные по кодовой базе тройные циклы for.
                  А иногда к коду сразу жесткие требования предъявляют, в HFT, например.


                  Другое дело, что на собесах задавать алгоритмические задачи любят сейчас все, вне зависимости от необходимости их использования в дальнейшем. Это такой удобный способ хоть что-нибудь проверить у человека, когда просто не знаешь что проверять.
                  Слюна не капает — чекд, разворот дерева написал — чекд. Ок, берем.

                  +2
                  Итак, что вам нужно для полного программистского счастья соответствия набора в конце 2020?
                   
                  Структуры данных, алгоритмы, бизнес-процессы ит.д.

                  Неправильный ответ! Правильный — "Конечно же, наш VDS сервер по специальному тарифу"

                    +4

                    2061 год — Академик-программист ищет проекты на фриланс. Знаю все. Умею все. Под каждый новый проект создаю новый язык программирования. Если чего-то не существует, придумаю, реализую, покрою тестами и отдам заказчику. :)

                      +4
                      а софт-скилы где? да знаете, таких академиков как вы на каждом углу, чем вы лучше других?
                        0
                        Лучше не нанять лишнего хорошего академика, чем потратиться на релокацию плохого.
                          +2
                          Интриган манипулятор. Имею базу посреди тихого океана, штат приспешников и несколько проектов на гитхабе.
                            0
                              0
                              Спасибо, мы вам перезвоним! На позицию джуна придется подучиться еще конечно…

                              ))) а вообще очень повеселил ваш коммент! Интриган манипулятор, блин...))))
                          +1
                          И это большая проблема: разработчики создают продукт просто по ТЗ, не ради удобства конкретных клиентов.

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

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

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

                            Увы, но "кто-то при составлении ТЗ хреново поработал" — обычное дело. Нечетко сформулированные ТЗ, ТЗ с грубыми ошибками и серьезными противоречиями, вариантов осложнить жизнь исполнителю масса.
                            А спросят таки с программиста по полной. Вот и приходится вникать в предметную область и делать "хорошо клиенту", иногда даже вопреки ТЗ, чтобы клиент удовлетворился и принял работу. А если делать строго по ТЗ, то клиент будет недоволен со всеми вытекающими (или вообще ничего не получится, если ТЗ внутренне противоречиво).
                            Часто такое бывает в небольших проектах-шабашках, когда заказчик и руководитель группы разработчиков сами с трудом понимают, как оно должно быть.


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

                            +3
                            У таких ребят две отличительных черты: 1) они упрямы и уверены в своём превосходстве;

                            Вся статья пропитана этим же.
                              –1
                              Статья класс.
                              Но стоит сделать отметку на массовость джунов или будущих джунов среди читателей.
                              Понимание бизнес-процессов джуну не нужно. Он будет работать по сторям, созданным аналитиками, которые разжевали эти бизнес-процессы для конкретных одной-двух недель работы по СКРАМ, которые ему нарежет на задачи тимлид или синьор.
                              В процессе роста себя до мидла джун изучит это как необходимость.

                              А вот про софт скиллы… Видя такую дыру во многих, необязетельно разработчиков ПО, людях, становится очень страшно за школьное образование, которое должно как раз этому обучать. 11 классов закончил и «бе-ме» связать не можешь в беседе. Плохо.
                                +1

                                Что-то не наблюдаю я такого. А наблюдаю совсем обратное. Отрасль движется в сторону дальнейшей специализации.


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

                                  0
                                  Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д. У таких ребят две отличительных черты:

                                  Одна из них — мифические существа, которые разрабатывают фреймворки. Весь этот список «массивы, деревья, связанные списки, сортировки» — это школьная программа 9-10 класса, где учат ими пользоваться, а не реализовывать. Можно подумать что человека выгнали из школы, и вместо (вместе) профильного образования он решил заняться программированием вроде как для хобби.

                                  Если пиарщица или менеджер проектов нервно поправляет каре и говорит, что в компании «джавист Сергей токсичный», я знаю, что скорее всего джавист Сергей угнетает коллег своим объёмом знаний

                                  А если такого джависта, за токсичность, посылает бородатый дядя, за плечами которого +100 500 проектов на десятке языков, что вы тогда о нем тогда думаете?
                                    0
                                    «массивы, деревья, связанные списки, сортировки» — это школьная программа 9-10 класса, где учат ими пользоваться

                                    У меня такого в школе и близко не было. Ну или я полностью это пропустил, хотя занятия вроде бы не часто прогуливал.
                                      0
                                      видимо, автор какой-то углублённый профильный лицей имел ввиду
                                        0
                                        Раньше может и не было, но последние 10 лет точно есть, по крайней мере периодически имею дело с программой разных школ, но это в основном Москва и подмосковье. Конечно это профили или факультативы, которые могут выбирать ученики. Но даже у меня в 8 классе 90-x годах был урок информатики на БК где массивы проходили, примитивно на уровне «тык мык».

                                        Просто тут речь идет явно не о школьниках. А такой уровень это совсем азы. Это в мое время все это изучалось по затертым до дыр книжкам, а сейчас у всех все под носом.
                                      +2
                                      Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих.

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

                                        Читаешь такие статьи, осознаёшь свою никчёмность, погружаешься в уныние, начинаешь фантазировать о хаках не для слабонервных… :)


                                        Когда, решая сложную задачу, озаряет: две головы - лучше!

                                        image


                                        Имплементируешь

                                        image
                                        image


                                        И уже работаешь тандемом, профит!

                                        image

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

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