5 мифов о ведущих разработчиках, от которых мне становится грустно

    Ведущие разработчики, они же Senior developers. Это те самые люди, которые на своем веку перевыполняли уже все возможные задачи. Это люди, которые входят в переговорку, открывая дверь с ноги. Они — решение всех проблем компании и гарантия светлого будущего. Они не изучают технологии, а изобретают. Они знают бизнес-требования до того, как те были сформулированы. И самое главное: они четко и отчетливо представляют себя через пять, а иногда и через десять лет.

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

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

    10+ лет опыта


    У меня вот есть эти 10+ лет опыта, но вспоминая, чем и как я занимался 10 лет назад, я надеюсь, что мне никогда не придется применять эти знания. Технологии бегут, просто летят и меняются с огромной скоростью. То, что было актуально вчера — сегодня уже bad practice, завтра — deprecated, послезавтра — история. В нашей профессии мы не накапливаем знания, мы их просто одалживаем на время, заменяя на более современные и полезные.

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

    Самостоятельный


    Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал. Без вопросов, без уточнений, без проблем. Интерфейс, который принимает в качестве аргумента задание, а на выходе отдает работающий код. На практике это часто вредно. Некоторые разработчики вместо того, чтобы уточнить бизнес-требования, пытаются быть самостоятельными, не отвлекать продукт-овнера и додумывают все сами. Додумывают неправильно.

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

    Обучает начинающих


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

    Обучать людей — это талант. И не у каждого хорошего программиста он есть. На самом деле, сеньор должен быть скорее Яндекс Картами, чем гидом. Он должен указывать направление, следить, чтобы джуниор не свернул в опасный район и шел правильной дорогой. При должном желании джуниора этого с лихвой хватит, чтобы вырастить из него приличного мидла.

    Незаменим


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

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

    Коммуникабельный


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

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

    Итого


    По сравнению с вакансиями пятилетней давности, компании сделали большой шаг вперед. Уже не перечисляют все термины, которые можно услышать в каком-либо уголке офиса. Вакансии составлены настоящими профессионалами и действительно выглядят привлекательными. Тем не менее, раз за разом, я вижу в вакансиях мифы, оформленные в виде требований. И каждый раз, когда от меня требуют быть дружелюбным или учить джуниоров — мне становится немного грустно.
    Поделиться публикацией
    Комментарии 107
      +28
      Технологии бегут, просто летят и меняются с огромной скоростью. То, что было актуально вчера — сегодня уже bad practice, завтра — deprecated, послезавтра — история

      Тут есть два замечания:


      1. Это далеко не всегда так. Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?
      2. Аналогично, есть архитектурные подходы, которые сформировались где-то лет 40 назад и которые только переизобретаются и уточняются. Но ничего кардинально нового не приходит.
        +8
        Скорее всего речь автор ведет о web разработке
          +2
          Да и в веб-разработке тоже не очень. Концепции и синтаксис Java, PHP, Python поменялись не сильно, разве что новые языки добавились. Скорее всего вы имели ввиду js — вот тут действительно за всеми новыми фреймворками и фичами не уследишь.
            –1
            SPA — не так давно внедряются в мир. Я вот не могу уже рендерить HTML странички в PHP, твигом и т.п. и прокидывать туда переменную с массивом постов из бд, тошнить начинает.
            Microservices, SOA — из той же серии, правда, не такие уж незаменимые, но модные.
            Docker — туда же.

            Так что в разработке очень-очень часто все обновляется!
              +15
              SPA — не так давно внедряются в мир

              до этого народ писал десктопный софт, где были те же компоненты в UI (виджеты), те же mvvm и т.д. Ну и как же не вспомнить ужасный extjs, mootols и прочие фреймворки. А еще помните flash/flex?


              модные нынче flux это просто ребрендинг smalltalk mvc и т.д. подслащенный отсутствием ограничений по оперативке присущие концу 70-ых.


              Microservices, SOA — из той же серии

              Микросервисы — это soa good parts. А сколько лет SOA, это ух прям. А до были actor model. И до этого тоже были интересные похожие идеи. Ничего нового. Просто хорошо забытое старое.


              Docker — туда же.

              LXC появился 9 лет назад. Докер просто сделал это удобным. Ну и до докера тоже как-то инфраструктуру надо было налаживать.


              Так что в разработке очень-очень часто все обновляется!

              На самом деле не очень. Качество инструментов растет — это да. А вот "координально нового", того что прям ставит под сомнение 10 лет опыта, такого я лично не знаю. У людей проблемы с простыми концепциями которые придумали лет 40 назад и которые никуда не исчезли, все еще best practice и т.д. Большинство просто даже не знают о их существовании (всякие там structured design и подобные раритетные штуки).


              Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.

                +2
                Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.

                Чертовски верное уточнение…
                0
                Верный путь к производству спагетти в промышленных масштабах.
                –3
                Чтобы понять, что вы не правы, вы просто должны открыть чейндж лог любого популярного браузера. И это будет только начала пути осознания, что вы не правы.
                Да синтаксис языка может и не меняется. Но вот технологии меняются. И меняются очень часто. Не так недавно я радовался флексбоксу, а сейчас уже новые гриды подплывают. Или CSS, там нет изменений? Синтаксис тотже. Но теперь анимацию делают на голом CSS.
                Да о чем говорить, если парадигма ООП меняется. Верней понятие этой парадигмы.

                  +6
                  Но вот технологии меняются.

                  принципы не меняются.


                  а сейчас уже новые гриды подплывают

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


                  Но теперь анимацию делают на голом CSS.

                  Это что-то что надо как-то переосмыслять или чем-то принципиально отличается от анимаций на JS с точки зрения понимания того как работают все эти переходы и как их описать?


                  если парадигма ООП меняется. Верней понятие этой парадигмы.

                  А вот тут мне даже интересно, что именно вы имеете ввиду. Начнем с того что есть 2 разных трактовки ООП (а то и больше), одна — просто надстройка над структурным программированием, а вторая — которую никто не понимает (под вдохновением от которой родилась концепция actor model).


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

                    0
                    Концепции трактовки парадигмы меняются, как только подплывают новые гриды. А идеи принципов меняют технологии.
                      0

                      как это коррелируется с опытом?

              0
              Увидел такое своими глазами с моим коллегой: человек вполне себе разбирается в WinForms, но WPF обошёл его стороной, совсем. И в 2016м году он был искренне удивлен о том, как работают байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM.
                +1
                Справедливости ради, хотел бы заменить, что технология WPF появилась в 2006 году. Ну и тот же поход MVVM, который он использует начал упоминаться Microsoft в 2005.
                  –1
                  Простите, но не понял к чему Ваш комментарий?
                    –1

                    Технологии, которым удивился коллега, были новыми только для него.
                    Чуть выше, в другой ветке написали про это:


                    У людей проблемы с простыми концепциями которые придумали лет 40 назад и которые никуда не исчезли, все еще best practice и т.д. Большинство просто даже не знают о их существовании (всякие там structured design и подобные раритетные штуки).
                    Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.
                  0
                  И в 2016м году он был искренне удивлен о том, как работают байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM.

                  А может и к лучшему?
                  К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси…
                  А если говорить о неплохих идеях, заложенных в нем (но либо плохо воплощенных, либо так и не воплощенных), так все равно к 2k16 в современном фронте значительно все поменялось — от идей до их реализации.


                  В том смысле — что если ваш коллега все это проскочил, то и ок, а то бы может там и застрял посильнее, чем в винформах.


                  P.S. С WPF довелось познакомиться и плотно поработать (с теми самыми "байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM").

                    +3
                    К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси

                    А что сейчас лучше по вашему для Desktop GUI применять?
                      +2
                      Хороший вопрос.
                      Что делать, если разработку дестопных UI-технологий забросили в угоду вебу?
                      Видимо, разрабатывать на том, что есть — на том же WPF или винформах.
                      Есть еще вариант разрабатывать десктопые приложение с вебовским UI — кажется, клиент Slack так разработан?
                      Когда то в пору Windows 8 Microsoft вроде так и планировали — чтобы писать декстопные формы на HTML5.
                        +2
                        Qt. Их пока еще не забросили.
                          +1
                          Как-то мы незаметно перешли с .Net на C++. Там ещё где-то GTK бродит.
                            +7
                            Не нашел в треде привязки к до-диезу, однако нашел обсуждение текущих реалий разработки GUI. В таком контексте Qt вполне смотрится.
                              0
                              Как же бессмертный WinAPI?
                                0
                                WinForms же
                                  –1
                                  Это NETовская обертка над WinAPI? Я просто не в курсе, работаю напрямую.
                                0
                                Бессмертным он будет до виндекапец, его понимание, на самом деле, также важно, как понимание ассемблера. На мой взгляд, единственное, где тут стоит влезать в такую низкоуровневость — это крайняя необходимость в быстродействии и получении специфических фишек Винды. Гуи на нем писать сомнительно.
                                0
                                UI в Qt можно и на JS писать, можно даже без С++ вообще.
                                  –1
                                  Изначально шёл разговор про GUI на .Net (WPF). Автор камента написал, что WPF — жуткое легаси и устарело. Я спросил — если не WPF, то что применять? QT здесь вообще не в тему, поскольку языки .Net в фреймворке QT не поддерживаются от слова совсем. Есть, конечно QtSharp, но это просто обёртка над Qt, позволяющая пользовать его функционал в C# .Net и Mono. Причём, на мой скромный взгляд это может пригодится только для Mono (ну может, ещё .Net Core). Классический .Net на винде вполне может обходиьтся WPF`ом.
                                    0
                                    а зачем вообще .net?
                                      +2
                                      Что значит зачем? Код на нём пишут.
                                        0
                                        QT здесь вообще не в тему, поскольку языки .Net в фреймворке QT не поддерживаются от слова совсем

                                        из вашей логики не понятно зачем отказываться от Qt когда можно отказаться от .net
                                          0
                                          Действительно. Зачем ездить на метро, если есть фуникулёр? Логика странная. Разговор изначально шёл про .Net. Исключительно про .Net. Если позволите ещё одна аналогия. Стоят два человека, обсуждают чем лучше смазывать лыжи. Подходит третий и говорит — надо прорезиненные гусеницы ставить.
                                        +1

                                        а зачем вам C++?

                                        0
                                        Есть, конечно QtSharp, но это просто обёртка над Qt, позволяющая пользовать его функционал в C# .Net и Mono.

                                        Какая разница над чем обёртка и вообще обёртка или полноценный продукт, если API для использовани из .Net/Mono имеется?


                                        Классический .Net на винде вполне может обходиьтся WPF`ом.

                                        "может обходиться" != "единственный доступный вариант"

                                0
                                К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси…

                                Десктопные решения, представьте себе, еще дорабатываются и разрабатываются новые. На сколько я понимаю, Xamarin.Forms в принципе опирается на WPF. Разработка под Windows Store, так называемые UWP — тоже.
                                  +1
                                  Зачем? Мобильная платформа умерла, как давно вы пользовались Store на десктопе?(Это я про UWP и Store)
                                    –2
                                    Зачем

                                    Что зачем?
                                    Мобильная платформа умерла

                                    Для Вас может и да. Я лично до сих пор пользую WP. Да и Xamarin, на мой взгляд, имеет право на жизнь и востребована.
                                    как давно вы пользовались Store на десктопе?(

                                    Сегодня.
                              –1
                              Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?

                              Да. Особенно, если вам придётся работать с 10-й версией.

                                +3
                                Ну, разве с 7.2 (вышла в 2002) сильно поменялась логика работы индексов? То есть, добавились новые, но старые вроде так же работали.
                                  –3

                                  Использовать только старые при современных требованиях? Вы это серьёзно?

                                    +3
                                    Нет конечно, изучать новые технологии нужно, но вы же используете старые индексы, например, Btree?
                                      –3

                                      Вот пройдитесь по описанию команды CREATE INDEX хотя бы. Настоятельно рекомендую.
                                      И ещё неплохо было бы понимать, что Btree (balanced tree) — это логика. А вот физическая реализация может существенно различаться от версии к версии, что приводит к различиям в планах выполнения запросов и, соответственно, различном времени выполнения этих запросов на разных версиях ПГ. На соответствующих ресурсах неоднократно такие вопросы задаются.

                                        +9
                                        И что, это вещи которые невозможно узнать «на лету», по ходу дела? Это мелочи которые вы же сами несколько раз на день гуглите по работе.
                                          –1

                                          Желание решать проблемы в проде — оно сейчас более востребовано, да. Только вот я предпочитаю не создавать этих проблем бездумным внедрением обновлений, когда обновление может существенно повлиять на работу существующего приложения, и/или разведением зоопарка из дикого количества различных ключ-значение решений, когда нужная функуциональность появляется в используемой СУБД.
                                          А для этого надо не гуглить по несколько раз за день, а внимательно изучать, что появилось/изменилось в новой версии. Вот как-то так. Гуглить — это когда возникла конкретная проблема. Для уточнения конкретной возможности используемого ПО надо пользоваться официальной документацией. Тем более, что у постгреса поиск по документации весьма годный.

                                            +2
                                            А для этого надо не гуглить по несколько раз за день, а внимательно изучать, что появилось/изменилось в новой версии.
                                            Надо в какой момент? Нет не надо.
                                            Когда появится необходимость — тогда и изучай, за счет времени оплачиваемого работодателем. (Если нет личного чистого интереса.)
                                            Вот я с PG в проде работал мало. Но в случае надобности работодатель наймет меня и заплатит за мое обучение. (за то что я в рабочее время подтягиваю то что нужно работодателю)
                                            По крайней мере если другие мои скилы подойдут работодателю.

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

                                            Любые знания которые не применяются забываются. Так что заранее учить подряд все нюансы нет никакого смысла, разве что ради интереса. Старые знания легко подтянуть до 10й версии. И то, далеко не всё понадобится в проде.

                                            Предмет спора что основные идеи не поменялись с прошлых версий.
                                            Всё это мелочи которые легко и достаточно быстро учатся, особенно если есть опыт с другими БД или есть понимание о чем идет речь.
                                              –1

                                              есть мнение что нужно всё-таки знать немного заранее — иначе трудно проектировать


                                              вот не знаешь, допустим, что в pg10 есть xmltable, а он бы может как раз очень подошел вместо второй СУБД умеющей xml

                                                +1

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


                                                Я вот постгрес использую последние года 4, ждал релиз 10-ки но про xmltable вот не знаю. И не особо переживаю по этому поводу. Как никак, плюшка довольно редко используемая.


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

                                      +3
                                      Что же там такого появилось в 10й версии?
                                        0

                                        Рекомендую изучить (на русском, если что):
                                        https://postgrespro.ru/docs/postgresql/10/release.html
                                        https://postgrespro.ru/docs/postgresql/10/release-10-1.html
                                        Я лучше всё равно не скажу.

                                          +4
                                          Я бы не сказал, что что-то поменалось так, что рядовому энтерпрайсному программисту придется переучиваться.
                                            –1

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

                                              +4

                                              лучше ответте на простой вопрос. Допустим 10 лет назад человек знал postgresql. Никаких jsonb небыло, другие СУБД по возможностям были примерно там же… Предположим что волею судьбы мы на 10 лет отстранились от psql. А теперь вопрос — мы вообще на 10 лет ушли от баз данных и SQL? Версткой начали заниматься? Ну так тут тогда нет 10-ти лет опыта.


                                              А если мы все же занимались разработкой и так или иначе юзали ораклы, ms sql, мускули и т.д. читали статьи и новости то если через 10 лет мы вдруг решили "а сделаю я проект с postgres 10" — я не думаю что у челвоека уйдет больше недели на то что бы восстановить знания и ознакомиться с новыми плюшками.

                                            0
                                            Я лучше всё равно не скажу
                                            Что по вашему мнению там ключевого?
                                              –1

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

                                          0

                                          а вам нужны всякие брин индексы? Вряд ли зная постгрес 10 лет назад и сейчас вы не сможете почитать вики или в целом были в информационном вакууме и вообще ничего не знали про psql.

                                      –1
                                      По поводу актуальности Psql хорошо сказано в подкасте радиота, выпуск 574, начиная с 1:28:00
                                      radio-t.com/p/2017/12/02/podcast-574
                                      Скажем, основные идеи какого-то postgres так сильно поменялись, что если вы знали его 5-10 лет назад, вам нужно будет его переучивать?

                                      Нет, переучивать не нужно, нужно учить Монгу, если вы этого еще не сделали!
                                        +1
                                        По поводу актуальности Psql хорошо сказано в подкасте радиота, выпуск 574, начиная с 1:28:00
                                        radio-t.com/p/2017/12/02/podcast-574

                                        Не могу послушать, у этих ребят кривой сайт и не мотается подкаст.


                                        Нет, переучивать не нужно, нужно учить Монгу, если вы этого еще не сделали!

                                        Там кластер уже не разваливается с пол-пинка? В любом случае, каждому делу свой инструмент.

                                          +1
                                          нужно учить Монгу, если вы этого еще не сделали!

                                          мне казалось мода на монгу уже давно канула в лету. jsonb в постгресе покрывает 90% юзкейсов для которых люди брали монгу. Возможность быстро на монге делать шарды и реплики перекрывается отсутствием реальной необходимости у тех же 90% в этом. Да и есть более интересные решения вроде тех же orientdb или arangodb.


                                          То что сегодня надо уметь не только в реляционную модель но и понимать зачем нужны document/column/key value модели, это факт. Но это не обязательно должна быть монга и это никак не говорит что пора выкидывать любимый постгрес.


                                          Я бы не стал инвестировать свое время в монгу (в 13-ом году пол годика побаловались и хватит), да и с точки зрения управления данными есть куча прикольных концептов вроде aws dynamodb в купе с хайповыми нынче serverless решениями.

                                        +2
                                        С чем-то можно согласиться, а с чем-то нет.
                                        Но с чем я точно соглашусь, так это с дебильными вакансиями, в которых перечисляют все что нашли в гугле.
                                          +4
                                          ) а по факту оказывается, что нужен был эникей
                                            +7

                                            Напомнило древний, но по-прежнему актуальный баян.


                                            Если бы водителей принимали на работу как программистов...

                                            Вакансия: водитель.


                                            Требования:


                                            Профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО.
                                            Навыки раллийного и экстремального вождения обязательны.
                                            Опыт управления болидами “Формулы 1” – приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей.
                                            Опыт проведения кузовных и окрасочных работ – приветствуется.
                                            Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.


                                            Зарплата: определяется по результатам собеседования.

                                              +1
                                              Ага и в итоге нанимали бы прекрасных водителей трехколесных велосипедов :).
                                            +2
                                            Действительно, самостоятельность — это отличительное качество сеньора. Но принимать решения он должен только в вопросах архитектуры и кода.
                                            Так ли это? Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться? Вдруг найдется то решение о котором я не подумал.

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

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

                                                +2
                                                Есть 10 full-stack разработчиков которые пилят один проект, если они не будут согласовать (обсуждать и советоваться) что да как делать, это же будет каша в проекте?

                                                Разработчик взял и сделал молча как захотел, добавив костыли и новые сторонние библиотеки и завязав проект на парочку типов приложений вроде RabbitMQ и Redis, ведь другие разработчики и архитекторы не для того что бы я их дергал или они меня дергали.

                                                Или наоборот, приходит задача разработчику, разработчик думает об архитектуре, а потом такой «СТОП! У нас же есть архитектор, вот ему таска пусть подумает, а потом скажет мне какая будет архитектура». Не странно ли?

                                                Может я чего то не понимаю. Масса рабочего времени уходит на обсуждение / согласование, как требований так и способов решений, часто бОльшая часть времени.
                                                  +2

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

                                                    +3
                                                    Я из геймдев команды, где мы согласовывали основные направления развития кода и способы реализации фич (не подробно, но общий подход и инструменты решения) попал в команду где каждый молча пилит свою фичу, ни с кем не советуясь.

                                                    Снижение эффективности во втором подходе буквально вгоняет меня в депрессию.
                                                    Не рекомендую такой подход в геймдеве. Моя старая команда в 6 человек на порядок (именно в десять раз, судя по джире) эффективнее текущей команды в 14 человек по количеству фич в месяц, более того, многие фичи вообще не достижимы в новой команде в разумный срок. Дальше становится только хуже, и я не могу исправить ситуацию.
                                                    Более того, чужие решения начинают ломать твои фичи, что превращает линейную разработку в поддержку старых систем.
                                                    Вот так страшно жить.
                                                  +2
                                                  Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться?
                                                  Более того, обычно в компаниях вообще запрещено коммитить что-либо, не посоветовавшись с остальными разработчиками в виде code review.
                                                    +2

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

                                                  +4

                                                  Ну, за "открывать в переговорку дверь с ноги" можно многое отдать

                                                    +11
                                                    Просто в руках ноут, блокнот и чашка с кофе
                                                      +4

                                                      Особенно, если дверь открывается наружу.

                                                      +5

                                                      По моему опыту, senior разработчик — это просто категория для отдела кадров и бухгалтерии. Никогда не встречал специалиста, называющего себя таким титулом при знакомстве, например.


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

                                                      Знания, как раз, позволяют не только быстро приобретать нужные навыки, но, что важнее — осознанно выбирать, которые из них стоят приобретения.


                                                      В нашей профессии мы не накапливаем знания, мы их просто одалживаем на время, заменяя на более современные и полезные.

                                                      Я бы уточнил — знания накапливаем (это чтобы одно на другом строить, или, наоборот — держаться подальше), а некоторые навыки (локальные) приобретаем на время.

                                                        0

                                                        Логично ибо эффект Даннинга — Крюгера имеет место быть

                                                        0

                                                        Ожидал увидеть другие качества senior'a в заметке: "senior developer is expensive, bored and opinionated"

                                                          0
                                                          судя по тону заметки «opinionated» — это про автора :)
                                                          +2

                                                          Ведущий разработчик для меня это уже lead. Team lead, tech lead, может lead developer (редкая официальная позиция в целом). От старшего (senior) разработчика отличается прежде всего развитыми, как говорится, soft skills, прежде всего упомянутые как ненужные коммуникабельность, самостоятельность, способность обучать (ну, или, хотя бы способность грамотно и понятно донести свою техническую мысль до менее технически квалифицированных разработчиков, а не просто направлять джунов по принципу "делай так, а то руки оторву твой код моё ревью не пройдёт").

                                                            +20
                                                            Мне кажется, вы переоцениваете значимость текстов о вакансиях) Это не священные скрижали, а просто сборник хотелок в поисках идеала. Тексты составляют обычные люди, разные, зачастую случайные и далекие от принятия решений.

                                                            Представьте пишет кто-то вакансию. Допустим, HR. Или даже кто-то реально компетентный. Но проходит мимо большой босс и говорит: «Добавь-ка там Гарвард и Нобелевскую премию. Я такие деньги плачу! Да за них можно пятерых гениев нанять, блин!». Окей. Подбегает маркетолог. Говорит: «Глубокие знания бизнес-процессов обязательны! Нам нужны умные понимающие люди!». Ну окей. Пробегает девочка-бухгалтер: «Ой, а давайте напишем, чтобы был спортивного телосложения...». Уборщица кивает и поддакивает: «Во-во! И чтобы бачок в унитазе починил!». Ну и так далее.

                                                            Много хотеть и искать идеал — это нормально. И вопреки стереотипам, тексты вакансий не всегда годятся для оценки рынка. Мы же не журналисты, чтобы по трем цифрам зарплат с доски объявлений Урюпинска «исследовать» медианные заработки в IT «во всем цивилизованнном мире» :)

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

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

                                                            Вывод? Не грустите :)
                                                              –1
                                                              Какие вакансии? Если ты ведущий, самостоятельный, коммуникабильный — значит ты фрилансер.
                                                                +2
                                                                Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал.

                                                                Ха, если бы это было так! Для специалистов уровня сеньйоров и выше под «самостоятельностью» подразумевается не только выполнение задачи, а и её формулирование, аргументация её практической пользы для проекта и чуть ли не план повышения продаж продукта и роста прибыли после реализации фичи.
                                                                  +2
                                                                  Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал.
                                                                  Это когда на проекте только один разработчик и бизнес аналитик всё классно разжевал в документации. В остальных случаях не представляю как это возможно.
                                                                  +4
                                                                  или выпускником, с горящими глазами

                                                                  Честно, такое читать в реалиях смешно. От всех только и слышишь, что опыта мало.
                                                                    +3

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


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

                                                                    +6
                                                                    Ведущие разработчики, они же Senior developers

                                                                    И сходу самая распространенная ошибка в обсуждениях Titles разработчиков.
                                                                    Ведущий != Senior, очень даже не равно.

                                                                    Senior это просто старший опытный разработчик, который все знает, как лучше всего сделать, к чему это приведет, если сделать так-то и так то, как обойти то-то, когда нужен микроскоп, а когда молоток, которые знает не только конкретные технологии, но и общие принципы, etc — за счет знаний и/или опыта.
                                                                    Который может сам сделать задачу, и его не нужно особой контролировать.

                                                                    Ведущий (Lead) — на то и ведущий, что он ведет других за собой.
                                                                    Это может быть или Team Lead — ведущий за собой команду в разрезе процесса разработки, либо Tech Lead — ведущий команду в плане выбора и соблюдения технологий.

                                                                    Причем, Senior вполне может быть Team Lead'ом (здесь больше нужны организационные навыки), а вот до Teach Lead'а сеньору нужно дорасти одну ступеньки строго по вертикали.
                                                                      –1
                                                                      То что вы в статье описали это Principal Developer. В чем разница — хорошо описали в этой статье.
                                                                      www.quora.com/What-is-the-difference-between-a-principal-developer-and-a-senior-developer

                                                                      У нас в компании все Principal Developer.

                                                                      Знание конкретного языка не имеет значения.
                                                                      Все работают одновременно с C/C++/Java/TSQL/C# в 2-3 фреймворках.
                                                                      Кто -то в чем-то лучше кто-то меньше.
                                                                      У каждого свой фронт работ и полная отвественность за результат.
                                                                      С написанием юнит тестов, функциональных и нагрузочных.
                                                                      Документациим спецификаций и прочая.
                                                                      Если что отряд не заметит потери уход бойца.

                                                                        0
                                                                        «Back to the black». ИМХО. Прихожу к выводу, что лучше инвестировать свое время в основы: в изучение алгоритмов, архитектур популярных БД (реляционных и нет), изучение устройства сетей и протоколов, парадигм программирования (функ., императив. итд) и др.
                                                                        Изучение конкретных технологий и узких приемов в конкретном языке инструменте — не выгодно.
                                                                          0
                                                                          В сказанном много правды, но есть ещё кое-что. Технологии в конечном счёте вторичны по сравнению с алгоритмами и архитектурой. Выучить новый способ забивания гвоздя — не проблема.

                                                                          Приходится работать с джуниорами, ошибки в технологиях тоже есть, но главная проблема не в этом. Вроде бы всем объясняли про архитектуру, но юноша с горящими глазами забивает бизнес-логику в presentation layer, прогоняет один раз, вроде работает, ура, коммитит. И если это не заметили на ревью (юнош много), то к тому моменту, когда всё развалится, переделывать придётся очень много.

                                                                          Или, работают с коллекциями, LINQ в .NET, прекрасная вещь, написал строчку и всё готово. Что там под капотом никого не волнует, а там полноценная итерация. Итерация, поверх итерации и ещё условие — O(N^3) как с куста. И всё в порядке с технологиями.

                                                                          А у сениора когда он такое видит сразу глаза кровью наливаются :-)
                                                                            –1

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

                                                                              –1
                                                                              И каждый раз, когда от меня требуют быть дружелюбным или учить джуниоров — мне становится немного грустно.

                                                                              Быть дружелюбным — это требование применимо к любому сотрутнику, а не только к сеньору. Смысл нанимать того, кто будет третьим в команде из лебедя, рака и щуки?

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

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

                                                                                  Исходя из своего опыта, я готов несогласится с автором.


                                                                                  10+ лет опыта

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


                                                                                  Самостоятельный

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


                                                                                  Незаменим

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


                                                                                  Коммуникабельный

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

                                                                                    –1
                                                                                    ИМХО Сеньор это тот кто не сошел еще с ума после 10 лет разработки, знает что все плохо и смирился с этим. Это не космонавт — это святой.
                                                                                      0

                                                                                      А если не смерился и пытается хотя бы локально улучшить "все плохо"?

                                                                                        0
                                                                                        Значит не Сеньор. Сеньор должен знать что человек несовершенен и еще более несовершенен его код. И цитата из «святого писания»: Высочайший уровень интеллекта — далеко не главное условие для человека, желающего стать хорошим программистом.
                                                                                        Совершенный код, Макконнелл 33.2
                                                                                          +1

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


                                                                                          p.s. цитату вы привели тоже не к месту. Про уровень интеллекта никто вообще не говорил. А так выходит что синьер это застой и тупость (я утрирую конечно).

                                                                                            0
                                                                                            Само подобное суждение говорит о вашей гордыни, а гордыня это несовершенство.
                                                                                            Отриньте гордыню и поймите уже вы не совершены, ваши мысли не совершены, а ваш код… Апеллируйте уже не философским понятиями, а математическим.
                                                                                              +1

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

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

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


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

                                                                                                    +1

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

                                                                                          0
                                                                                          Да это ж про меня!
                                                                                          –1
                                                                                          Автор поразительно удачно извратил значение каждого из этих 5 пунктов.
                                                                                            +2
                                                                                            Мне больше 40. По себе могу сказать, что утомляет не изучение новых технологий, а изучение старых.
                                                                                            Если бы мне предложили срочно делать проект на Хаскеле или на React (которых я не знаю), глаза у меня горели бы не меньше, чем в 25. Проблема в том, что кроме того, постоянно приходится изучать вроде-бы новые технологии, в которых 90% по сути старое, но другое.
                                                                                            У меня в голове полно места для новых идей, но совсем нет места для простых навыков, которые у меня уже есть и которые нужно заместить новыми. Лет до 40 это не было для меня проблемой.
                                                                                              0
                                                                                              10+ лет опыта


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

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

                                                                                              Зато глаза горят.

                                                                                              Самостоятельный


                                                                                              Всё зависит от написанного ТЗ.

                                                                                              Если его нет и работа ведётся гибким методом (смотрим коммуникабельность), то да — разработчики на работе только и делают, что разговаривают, а не работают.

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

                                                                                              Обучает начинающих


                                                                                              Здесь всё правильно написано. Дорогу одолеет идущий.

                                                                                              Незаменим


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

                                                                                              Коммуникабельный


                                                                                              Не вижу проблем в шашлыке и общении на природе, если это происходит в оплачиваемый раб-день чисто в рабочие часы.
                                                                                                0
                                                                                                Если есть четкое ТЗ

                                                                                                Вы когда-нибудь подобное видели? Если да — сколько времени было потрачено на составление этого ТЗ? Как потом обрабатывали изменения требований?

                                                                                                  0
                                                                                                  В некоторых областях, вроде авиации или медицины, такое бывает. И то не всегда.

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

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