Программист должен решать


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


    Программист должен решать проблемы бизнеса
    Программист не должен решать задачи бизнеса


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


    Уровни разработчиков


    Начну я, пожалуй, с вопросов иерархии и уровней. Раньше я думал, что существует 3 уровня:


    1. Младший разработчик — когда выходишь из института и можно лепить, как пластилин. Некоторые могут сворачивать горы, некоторые тупят над простейшими задачами. Но самое главное — нужен строгий контроль того, что делают эти разработчики, по крайней мере на первое время. Часто нужно давать задачи и разжевывать каждый шаг.
    2. Разработчик — простой разработчик, который уже знает, что такое "продакшен код", релизы, дебаги, авралы, и прочие интересные штуки. Решает средней сложности задачи. может давать задание более младшим разработчикам.
    3. Старший разработчик — решает уже технически сложные задачи. Хорошо подкован в своей предметной области, а даже в некоторых смежных. Его кидают на амбразуру в случае непонятных или нетривиальных задач.

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


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


    Дальше наступает практически потолок в технической части. Можно лишь свернуть в сторону руководства и управления. Так появляются технические руководители и менеджеры.


    Так я раньше думал. Однако впоследствии оказалось, что старший разработчик может стать еще более старшим. И еще более. Как так? Есть несколько путей.


    Разделение труда


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


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


    1. Senior engineer.
    2. Staff software engineer.
    3. Senior staff software engineer.
    4. Principal software engineer.
    5. Fellow engineer.

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


    Большие и маленькие компании


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


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


    Бизнес


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


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


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


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


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


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


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


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


    Все очень индивидуально и зависит от обстоятельств. Ну а тот, кто умен, найдет ключ в статье для своего собственного развития. Всем удачи!

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +3

      У вас рассуждение строится на утверждении "Дальше наступает практически потолок в технической части". Но мне оно не очевидно. Почему наступает потолок в технической части? Там точно "потолок"?

        +7

        Да, там потолок. Возьмём PG, если вы уже знаете как работает SQL, хранение данных, индексы, репликация, WAL, MVCC и умеете писать расширения, то глубже вам эту БД знать не нужно, если только вы не являетесь ее разработчиком. Может я пару пунктов забыл, но список недлинный. Аналогично с любой другой технологией.


        Можно в ширь пойти, изучить MSSQL таким же образом, но там, примерно, все то же самое. Изучили 2-3 БД и вы знаете их все, аналогично с UI, API и т.д.


        Когда вы уперлись в этот потолок как раз начинаются интересные задачи.


        • Инженерные — «нам нужна система хранения с характеристиками, отличными от всего, что есть»
        • Организационно-технические — «есть 50 индусов и приложение на 10 000 формочек, сделайте архитектуру и процесс, чтобы они за 2 года все сделали»
        • Дизайн систем — «у нас тут на вход данные с такими характеристиками, вот такая обработка, нужно придумать как эту обработку, хранение и показ данных организовать». Тут крайне важно знать область, иначе можно всякого напридумывать.

        И так далее и тому подобное — реальная проблема и профессионал, который ее решает, понимая пространство решений, альтернативы и компромиссы.


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

          +1

          У вас комментарий строится на том что вы текст не читаете.


          "Так я раньше думал. Однако впоследствии оказалось, что старший разработчик может стать еще более старшим. И еще более. Как так? Есть несколько путей."

          +9

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


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

            0

            Офигенное сравнение Дозорами. Спасибо, возьму на вооружение)

              0
              хех, тоже читал дозоры )

              насколько я помню, там не пропасть была, а просто разницу в энергии между двумя чуваками вне категорий нельзя было измерить. А вот навыки и искусность могли сильно отличаться.
              Просто тогда аналогия выходит неудачной (что есть сила а что есть навыки для программиста?)
              +11
              Неуклюжие попытки разбить всех программистов по категориям напоминают «Божественное хранилище благотворных знаний»:
              животные делятся на:
              а) принадлежащих Императору,
              б) набальзамированных,
              в) прирученных,
              г) молочных поросят,
              д) сирен,
              е) сказочных,
              ж) бродячих собак,
              з) включённых в эту классификацию,
              и) бегающих как сумасшедшие,
              к) бесчисленных,
              л) нарисованных тончайшей кистью из верблюжьей шерсти,
              м) прочих,
              н) разбивших цветочную вазу,
              о) похожих издали на мух.
                +1

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

                  0
                  :)
                  +3
                  Мне кажется автор забыл упомянуть две вещи.

                  1) Критерий попадания в principal и вообще карьерного роста. Это *уровень влияния* на судьбу проекта, отделов фирмы, всей фирмы, целой индустрии. Уровень охвата одним человеком самого себя, своего проекта или десятков/сотен/тысяч других людей. А не способность решить самостоятельно сложную задачу или запилить очередной фреймворк или сервис. Это как раз ожидается от обычного разработчика. А вот повести за собой остальных, увидеть проблемы и поставить задачи на годы вперед, это уже другой разговор.

                  2) Уровень зарплат. Который обычно нехило подскакивает при нахождении в данной категории senior/principal/staff/disitinguished и так далее (можно видеть на levels.fyi). Очень мотивирует, если кому надо.

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

                    Создать с нуля фреймворк — это ожидается от обычного разработчика? Как же все вокруг изменилось...


                    А под "запилить очередной сервис" вы что понимаете?

                      0
                      О, неправильно выразился. Я имел в виду запилить интеграцию с каким-то фреймворком или сервисом. Но и поднять свой фреймворк с нуля, это тоже не совсем о том, кроме редких случаев, когда решение становится буквально глобальным и принимается в очень широких кругах. В своей прошлой жизни я писал фреймворки и ими таки пользовались многие. Однако это ни на шаг не приблизило меня к позиции senior. Это пришло потом, когда организовал работу команды и поднял проект с нуля. Так что какое-то конкретное решение сделанное руками одного человека, каким-бы классным оно ни казалось в данный момент, это все же хорошее (или отличное) решение одной конкретной задачи. Для impact-а и позиций указанных в статье придется все же брать выше и шире.
                        0
                        Это пришло потом, когда организовал работу команды и поднял проект с нуля.

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

                          0
                          Вы несколько путаете понятия влияние и руководство. Как я писал выше, позиции senior, principal, staff и так далее (которые в статье упомянуты) они как раз о влиянии и способности быть негласным лидером, по крайней мере там где я работал (это США). Техническое совершенство, конечно, ожидается, но во главу угла ставится прежде всего impact. Руководство людьми, их найм, 1:1 и так далее здесь вообще ни при чем, это параллельная ветка. Попробуйте получить Senior или Staff в западной фирме развиваясь чисто технически до уровня Бог (на чем подозреваю многие читатели фиксируются, в том числе благодаря этой статье), уверяю у вас ничего не выйдет — я знаком с критериями промо не по наслышке.
                            +1

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


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


                            Получается как в анекдоте: не сто рублей, а три рубля, не выиграл, а проиграл.

                              0

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

                                0

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


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


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

                                  +2
                                  «одобренных обычно руководством», «человек без административного ресурса», «выполняя менеджерскую роль» — друзья, возможно вам менее знакомо понятие командного лидерства (о котором я собственно и говорю с самого начала), но зато хорошо знакомы иерархические отношения и «админ ресурсы», где все делается или не делается по указанию и одобрению начальства. Или человека наделенного oсобым титулом или полномочиями (лычкой).

                                  Здесь (США, Израиль) так обычно не работает. Начальник занимается карьерным ростом людей и направляет проект в нужную сторону. Команда «плоская» (есть разные позиции, но нет никаких иерархий, голоса всех равны, просто кто опытнее обычно приводит более убедительные аргументы) и сама делает все остальное и каждый проявляет ровно столько инициативы, сколько может и умеет. Раздавать пинки, разрешать/запрещать и трясти перед людьми «админ ресурсом» это уже очень российская реальность, с которой я плохо знаком. Хотя нет, вру, довелось однажды работать в российской конторе. То еще осталось впечатление от выстроенных там пирамид и иерархий.
                                    0
                                    одобренных обычно руководством и/или командой

                                    Да и в США с Израилем хватает иерархических структур в разработке, даже в стартапах.

                                      +1
                                      Я говорил о тенденции и большинстве случаев. Лично я не встречал вертикальных команд, ни там, ни там. В Израиле так особенно иерархичность в отношениях не приветствуется. Один раз в жизни я это встретил и это была российская фирма с офисом в Европе. Сразу понял что не мое от слова совсем.
                                    0

                                    Да, понятно, вы там в светлом граде на холме на острие прогресса, а мы тут лаптем щи хлебаем и блох подковываем в лучшем случае.


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


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


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


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

                                      0

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

                                        0

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


                                        Ну и, по-моему, не следует опускаться с уровня "организовал работу команды и поднял проект с нуля" до "я сделал PR с интеграцией автоматического запуска линтера перед коммитом". Поскольку "организовал работу" (как по мне) означает, что кто-то распределяет работу (т.е. делает декомпозицию и распределяет задачи) между членами команды, обеспечивает контроль за выполнением работы, решает оперативные вопросы и рабочие разногласия. А "поднял проект с нуля" (опять же как по мне) означает, что человек взаимодействовал с заказчиками проекта (внутренними или внешними), чуть ли не от момента возникновения самой задачи и вплоть до запуска в эксплуатацию. Т.е. брал на себя ответственность за объем работ, их очередность, сроки выполнения и т.д.


                                        Все это несколько больше, чем "выбрать фреймворк" или согласовать набор паттернов.

                                          0

                                          Организовал принятие решения :)

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

                              Не знаю, как насчет Staff, я такого грейда не видел, а вот Senior — легко. Не все "западные фирмы" одинаковы.

                                0
                                Отлично, кому-то повезло! Критерии действительно могут отличаться. В фирмах поменьше, возможно, они менее жесткие. В более крупных без варианта. Там где был я 100% не прокатило бы, каким бы прокачанным чел ни был. С уровня senior ожидают не только конкретные примеры широкого влияния на свою и другие команды, но и голоса нескольких человек след уровня, готовых поддержать кандидатуру промо. Одними техническими скилами тут не обойтись никак. Как пример — классический L6 или SDE III в Амазоне, он же L5 в Гугле.

                                Staff встретил сам впервые в Убере. Примерно равняется Амазоновскому Principal (L7).
                                  0
                                  Там где был я 100% не прокатило бы, каким бы прокачанным чел ни был.

                                  Какая это доля от всех "западных компаний"?

                                    0
                                    В вопросе подразумевается ирония. Везде где я работал сам (2 компании) и получал предложения (4 другие компании). Это так важно? Так хочется остаться при своем мнении? Так оставайтесь. Не сомневаюсь, что есть конторы или стартапы где человеку неглупому дадут и уровень и должность, особо не заморачиваясь критериями. Назовут хоть архитектором, хоть синьором впечатлившись интервью и способностью в одиночку решать сложные задачи. Но ни в Амазоне, ни в Гугле, ни в Фейсбуке, ни в Убере, ни в Эппле так не работает. Если работа там не интересует, то мы просто говорим о разных конторах. И тогда можно прицепиться к фразе «западные фирмы», найти контр-примеры и остаться при своем мнении. Я пытался развеять розовые очки автора и возможно некоторых читателей. Если кому-то проще верить в обратное, так пожалуйста. Расскажите мне потом как проходило ваше промо на L6 и выше.
                                      +1
                                      Это так важно?

                                      Да, это важно, потому что хочется понимать, чего в реальности можно ожидать в "западной конторе".

                                        –1
                                        Сергей, с радостью отвечу на любые вопросы, если хотите пишите в личку. Могу поделиться своим опытом, а также своих друзей и родственников.
                                    0
                                    С уровня senior ожидают… голоса нескольких человек след уровня, готовых поддержать кандидатуру промо.

                                    То есть с улицы такую позицию получить невозможно? или уже работая, или по знакомству?

                                      +1
                                      Если она уже была на предыдущей работе, то без проблем. Прыгнуть же на ступеньку выше чисто по результатам интервью тоже можно, но придется приводить примеры влияния на решения и процессы, а не только «я писал такой-то код».

                                      Я же скорее говорил о процессе промо на senior или principal внутри фирмы. А потом и сохранении, так как review раз в год и критерии оценок работы все те же, как и на промо. Т.е чтобы однажды получить и удержать, придется регулярно показывать свое соответствие должности.
                                  +1
                                  Техническое совершенство, конечно, ожидается, но во главу угла ставится прежде всего impact.

                                  Такое ощущение, что у вас движение по цепочке junoir -> middle -> senior ассоциируется с качеством кода. Мол, пока пишет плохой код, то junior, как только код стал удобоваримым, повысили до middle, а вот когда уже начал писать отличный код, вот тогда уже senior.


                                  Уж не знаю, как там в "западных фирмах", может быть и так.


                                  Но вот в окружающей меня реальности разница между junior, middle и senior определяется вовсе не качеством кода, а двумя более важными факторами:


                                  • количеством информации и подробностью деталей при выдаче задания;
                                  • степенью контроля за исполнителем.

                                  Т.е. junior-у нужно все рассказать максимально подробно, да еще и снабдить ссылками на необходимые ресурсы. А потом еще и тщательно контролировать.


                                  Тогда как middle можно ставить менее подробные задачи и контролировать можно разве что конечный результат (ну или на важных промежуточных шагах).


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


                                  И вот как раз с senior-ом зачастую говорят на языке бизнеса или около того. Мол, нам нужно повысить надежность сервиса или снизить время отклика. Оставляя senior-у на откуп поиск технического решения. А то и отдавая всю реализацию по его ответственность (особенно если это не требует координации работы нескольких команд).


                                  Тогда как с middle и junior-ом разговор ведется на техническом языке. Типа сделать фичу такую-то в такой-то версии такого-то продукта. А для junior-а еще и: сделать фичу так-то и так-то.

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

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

                                    И я вижу тут уже не первый раз всплывает тема «под чью ответственность». Мне это напоминает поиск виноватых в случае не совсем верных решений. Отвечает не один человек, который предложил какой-то дизайн, а вся команда. Потому что проект это командное усилие, а не личная территория контроля одного человека. Кто-то предлагает решение, команда обсудила, одобрили/доработали и поехали. А попытка навешивать всю ответственность на одного человека опять же напоминает мне вертикаль власти. А также снимает всю ответственность со всех остальных игроков, что губительно. Да, за дизайном обычно стоит driver, который его толкает вперед вместе со всеми (и которому потом учтут все его инициативы на perf review), но это не то же самое что теперь это «его ответственность».
                                      0

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

                                        0

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


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


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

                                          +1

                                          Разработчик может отвечать за уборку и делать уборку в помещении. Это все прекрасно. Вопрос в другом: стоит ли в этом развиваться и какая от этого польза?

                                        0
                                        от senior как раз ожидают координацию и влияние на несколько команд

                                        Могли бы вы привести примеры того, что вы называете "координацией"?


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

                                        Я процитировал фрагмент вашего высказывания. Видимо, нужно еще раз повторить:


                                        Техническое совершенство, конечно, ожидается, но во главу угла ставится прежде всего impact.

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


                                        На что я вам и указал, что в цепочке развития junior -> middle -> senior качество кода вообще не главное. Соответственно, если до senior-а качество кода не главное, то и дальше оно главным не будет.


                                        Мне это напоминает поиск виноватых в случае не совсем верных решений.

                                        Это не напоминает, это оно и есть. "Ответственность" — это значит ответ за принятые (и не принятые) решения, за сделанное и не сделанное.


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


                                        Отвечает не один человек, который предложил какой-то дизайн, а вся команда.

                                        Это как? Просрали сроки, не обеспечили качество, вышли за рамки бюджета и вся команда отправляется на мороз?


                                        Даже если в команде 30 человек, а пятеро из них junior-ы, которые делают только то, что им скажут, и никакого влияния ни на архитектуру, ни на выбранные инструменты, ни на принятые технические решения, не оказывают. Так что ли?


                                        Ну и мне интересно: вот у вас в команде не только вы умеете правильные слова говорить, но и еще один-два человека. С правильными словами, с уверенностью в своей правоте, с желанием добиваться своего, с амбициями расти дальше, для чего нужны результаты. И вот вы предлагаете решение X, второй такой же решение Y, а третий — решение Z. Все решения более-менее одинаковы, при должных усилиях каждое из них приведет к работающему результату. Выбор, фактически превращается в дело вкуса и личных предпочтений.


                                        Вы голосованием будете делать выбор из этих вариантов?

                                0
                                Мне всегда казалось, что middle-разработчик в состоянии сам написать свой фреймворк. В конце концов, как можно делать хороший продукт на фреймворке, не зная, как он работает изнутри.
                                  0

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


                                  Что до знания "как он работает изнутри", то что-то я сомневаюсь, что поголовно все пользователи каких-нибудь Spring, Hibernate, Akka, Orleans, Qt и пр. имеют такие знания. Или даже имеют достаточную квалификацию, чтобы при необходимости заглянуть вовнутрь и разобраться с каким-нибудь частным вопросом.

                              0

                              Поддерживаю коллег выше — отличная статья!

                                0

                                Капитанская статья

                                  +5

                                  Если бы это была капитанская статья, то не было бы двух других.

                                  +1
                                  В целом верно, что на уровне senior карьера только начинается :-)
                                  Точнее, в Y-модели разделение на технический и менеджерский трек начинается после senior.
                                  В статье приведены позиции технического трека, названия специфичны для компаний, насколько я знаю.
                                  И опять же верно, нужен человек, который способен понять потребности бизнеса и предложить сбалансированное техническое решение. В некоторых компаниях такого человека называют архитектором, иногда это роль, иногда это должность, но это senior+ (если бюджет компании позволяет).
                                  Архитектура — это система компромиссов (уж не помню, где встречал это определение).
                                    0
                                    Реквестую статьи «Программист должен» и «Программист».
                                      –1
                                      +++ автору
                                      согласен

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

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