Беда в том, что планка "среднего" неуклонно снижается.
В 80-х и даже в начале 90-х в IT денег ещё не было и шли туда в основном фанаты. Те, кто сам паял себе компьютеры и сам писал под них софт и операционки; кто поднимал фидошные ноды "потому что могу", кто занимался IT из любви к этой отрасли.
Потом зарплаты выросли и пошла волна "вайтишников": "Я тут после армии два года вагоны разгружал, а тут узнал, что программистам дохрена платят, какой язык мне выучить первым?". И сейчас уже их прочат в "сеньоры", потому что ну три года работает же, целых два проекта написал. Ну а то, что его код до сих пор ревьюить надо - "ну так все же так делают".
А те, кто писал код ещё задолго до рождения большинства этих "сеньоров" - они, судя по количеству минусов, звания сеньора как раз и не заслуживают, потому что писали в соло, а не сотней человек, подтирая друг за другом косяки. Ну что ж, давайте катиться по наклонной дальше.
Ну сейчас-то да, безусловно, когда в ИТ-компаниях число разработчиков измеряется сотнями, а подчас и тысячами - действительно, замещая количеством качество - надо строить сложную многоуровневую систему ревью, писать автотесты, гонять код статическими анализаторами... и всё равно допускать ошибки.
Но, понимаете ли, так было не всегда. Было время, когда любой приличный админ мог написать патч к ядру или любому софту, а при случае - и свой собственный написать. Достаточно вспомнить, что nginx был написан Игорем Сысоевым, когда он работал админом в Рамблере, потому что производительности апача не хватало. И это решение вполне работало.
Или, как пример, найдите интервью с Алексеем Кузнецовым, одним из основных разработчиков IP-стека в линуксе - он там рассказывал, как им в институт притащили две дискеты с линуксом - правда, половины libc не было и пришлось дописать самостоятельно. И он тоже не был профессиональным программистом, он был физиком.
И ревьюить их код было банально некому, да и незачем, потому что это сейчас логика программиста "моё дело - тикеты в жире закрывать, а зачем они - то пусть ПМ думает". Там люди сами ставили себе задачи и сами их решали - и инженер, не умеющий в декомпозицию, попросту не мог называться инженером.
Или, на Ваш взгляд, человек, написавший в одиночку самый популярный веб-сервер в мире, недостоин высокого звания сеньора? А ведь он не был каким-то выдающимся исключением, на это был способен любой приличный специалист, если он вдавался в проблему.
Я возражал на комментарий, в котором человек заявлял, что "Сеньор это не про соло проекты", не более того.
Что нельзя быть сеньором в 22 - я, скорее, соглашусь. Притом, что я сам программирую с 9 лет, а сейчас мне 44 и я ещё успел застать "старую школу" (начинал, к слову, сразу с ассемблера).
При этом мне неоднократно приходилось делать крупные проекты либо в одиночку, либо в группе, но где мою часть знал только я. Зачем нужно ревьюить код сеньора с опытом в четверть века и зачем ради этого нанимать второго такого же - ну, мне не очень понятно.
Покажите, пожалуйста, где написано, что сеньор обязательно должен проходить код-ревью, а не то он будет "колоссом на глиняных ногах"?
Кроме того, я говорил не о прохождении, а о проведении ревью самостоятельно. Это отдельный навык, безусловно полезный, но вовсе необязательный для сеньор-разработчика - если он, как было указано выше, писал исключительно соло-проекты.
И да, соло-проекты - это необязательно "сайт про меня и мою собачку жучку". Я знаю примеры крупных проектов с сотнями внедрений, написанных без код-ревью просто потому, что писали их люди, чей код ревьюить банально не было нужды (да и найти специалистов, способных это ревью провести, задача очень нетривиальная).
Как раз говорит. Потому что сеньор - это про умение строить архитектуру, умение поддерживать проект, про знание смежных областей. В соло-проектах именно эти навыки и необходимы. Когда никто, кроме тебя, не придумает общую концепцию проекта, не построит инфраструктуру, не обеспечит работоспособность.
Чего сеньор не получит в соло - это навыков распределения задач, совместной работы, код-ревью. Но это, по нынешним временам, уже скорее функции тимлида/техлида, сеньор-разработчику это необязательно.
А что в этом такого? Я начал программировать в 9, сеть техникума взломал в 16. Но это в ещё отсутствие Интернета, потому как в 80-х особого доступа не было.
Если парень начал с самого детства, имеет мозги и талант - то почему бы и не быть хакером в 12-15?
Отчасти это оправданно стоимостью сопровождения и поддержки. Со сторонней компанией можно заключить юридически понятный контракт на сопровождение, со своим отделом - ну вот увольняетесь Вы, как главный разработчик, и кто будет поддерживать эту систему? Ведь наверняка ни проектной документации, ни даже комментариев в коде особо нет. Стоимость владения получается непомерной - особенно с учётом зарплат отделу разработчиков.
Это может быть шагом к своему бизнесу, например. Потому что на одних технарских навыках далеко не уедешь, надо уметь продать себя и продукт, нужно уметь организовать разработку и добиться результата - а это как раз навыки хорошего ПМ.
А вот сочетая то и другое уже можно и на вольные хлеба идти, если есть желание.
Можно не совмещать, но иметь адекватный бэкграунд. Видел ПМ-а по банковским решениям с опытом ИТ-директора в нескольких банках и опытом разработчика. Вот там да, человек вменяемо мог и часы посчитать, и разработчикам всё объяснить, и заказчика размазать тонким слоем по столу и убедить в необходимости выделения бюджетов. Просто потому, что сам был на всех этих должностях.
В противном случае ПМ в лучшем случае будет играть роль секретарши, пригодной только организовать встречу заказчика с исполнителем.
Нормально руководить проектом может только техлид/архитектор, да и то - только если он вдобавок обладает навыками менеджера.
Только человек, который как видит весь проект целиком, так и понимает работу каждого фрагмента, может адекватно оценивать сроки, качество работы разработчиков, бюджеты, потребности. Если этого всего нет - РП превращается в говорящую куклу, вызывающую у всех досадливое отвращение: работы и так навалом, а тут ещё этот за штанину дёргает и чего-то клянчит. И единственная роль РП в этом случае - выступать мальчиком для битья в разговорах с заказчиком, да и то - только если заказчик технически неграмотен и сам не понимает происходящего.
"Раньше" было две категории: были разработчики и были системные администраторы (ещё раньше и администраторов не было, но в такую древность сейчас погружаться необязательно).
Разработчики писали софт, админы отвечали за работу этого софта на проде. В комплексе, потому что проблемы в работе могут вызываться чем угодно: кривыми руками пользователя, сбоями в сети, недостатком производительности серверов и ещё миллионом причин. И любой приличный админ умел программировать хотя бы на уровне прочитать код и написать патч, а хороший админ легко мог и ядро пропатчить, и свой драйвер файловой системы написать. Достаточно вспомнить, что nginx был написан, когда его автор, Игорь Сысоев, работал админом в Рамблере.
Потом решили, что "админы не нужны", потом придумали дево-псов, которые вроде бы должны сочетать разработку с администрированием, потом придумали SRE...
А по факту это всё те же админы. Только их мало осталось.
Фраза красивая, но это только один из частных случаев.
Во-первых, незаменимые есть всегда. Собственник, гендир. На этапе старта компании (а это нормальный этап, через который проходят все) незаменимость человека - норма жизни. Более того, ориентироваться на "заменимых" - значит ориентироваться не на квалифицированных специалистов, а на туповатых (но зато заменимых) середнячков, а с такими построить конкурентоспособный бизнес не получится.
Ну и, кроме того, это очень дорого, особенно на начальном этапе. Чтобы обеспечить возможность работы "середнячков" - должны быть очень качественно простроены бизнес-процессы, а это тоже должен сделать кто-то квалифицированный, сиречь незаменимый.
С другой стороны, возместить иски продавец обязан и в рамках гражданского производства, причём ИП отвечает всем своим имуществом, а ООО - всем капиталом (то есть и средствами на балансе маркетплейса, в частности, то есть речь явно пойдёт о суммах больше уставняка).
Это риски ИП Иванова. Продавец несёт ответственность за соответствие товара заявленным им характеристикам. А китайцам он потом может подавать регрессный иск, если захочет.
Достаточно абонентского обслуживания от нормальной конторы с тем самым высококвалифицированным админом. Чтобы этот админ с самого начала замониторил всю сеть клиента и дальше спал, пока не замигает красная лампочка. Но когда замигает - мог нормально разобраться в проблеме, а не кидать камни по всем кустам в надежде, что под одним из них окажется заяц.
А раньше это просто называлось "инженерное мышление" и не было чем-то уникальным.
Вспомнить того же инженера Сайруса Смита из Жюль-Верновского "Таинственного острова". Чувак знает физику, химию, биологию, может из подручных материалов сделать хоть порох, хоть подъёмник. И это отнюдь не было чем-то фантастичным, это было нормальным для инженеров того времени.
Тогда было бы интересно увидеть больше технических деталей, чтобы понимать "профит" принятых решений.
Какая была нагрузка на сайт изначально? (RPS веб-сервера, QPS БД в разрезе селектов/апдейтов). Какая была конфигурация VPS? Какие ставились задачи в цифрах? (просто "увеличить производительность и управляемость" - это что-то на маркетоидном, это не про технические характеристики). На чём развернут кубернетес? - из статьи неочевидно: то ли вы утащили всё в облака, то ли развернули миникуб на той же самой vps, где всё и жило. СУБД тоже утащена в докер? (надеюсь, нет). Какую производительность модифицированный сайт показал на тестах? Что такое "повышение управляемости", сколько человек в команде, как часто происходят релизы, сколько времени они занимают, реализовывался ли blue-green deployment?
А то пока что ощущение, что речь идёт не о гигантах типа GetCourse, где подобный подход был бы оправдан, а о какой-то студенческой поделке на впс-ке, на которую зачем-то сверху накрутили кучу модных технологий "чтобы было".
Хороший пример совершения работы ради работы. Была вполне нормальная конфигурация, но зачем-то был внедрён докер, кубернетес (зачем? У вас десятки нод, которые надо оркестрировать? А базу вы тоже под докером крутите?), прометеус, разделение БД и так далее. Хотя в данном случае просто аренда более производительного выделенного сервера (хороший Xeon, гигов этак 64/128 памяти, пара NVMe дисков) обошлась бы на порядок дешевле зарплаты этого девопса, а проблему, при правильных настройках и оптимизации индексов, скорее всего решила бы - если уж до этого всё крутилось на VPS.
Нет, вместо этого начинаем рефакторинг всего и вся и каждый шаг добавляет лишнего геморроя. Ещё бы на микросервисы переписали. Больше работы богу работы.
Потому что политика. Одно дело, когда админ Вася рвёт на груди тельняшку перед руководителем: "Мамой клянусь, шеф, всё заработает!"; другое дело - когда разработчики двух продуктов официально подтвердили совместимость (и теперь несут ответственность за свои слова).
Беда в том, что планка "среднего" неуклонно снижается.
В 80-х и даже в начале 90-х в IT денег ещё не было и шли туда в основном фанаты. Те, кто сам паял себе компьютеры и сам писал под них софт и операционки; кто поднимал фидошные ноды "потому что могу", кто занимался IT из любви к этой отрасли.
Потом зарплаты выросли и пошла волна "вайтишников": "Я тут после армии два года вагоны разгружал, а тут узнал, что программистам дохрена платят, какой язык мне выучить первым?". И сейчас уже их прочат в "сеньоры", потому что ну три года работает же, целых два проекта написал. Ну а то, что его код до сих пор ревьюить надо - "ну так все же так делают".
А те, кто писал код ещё задолго до рождения большинства этих "сеньоров" - они, судя по количеству минусов, звания сеньора как раз и не заслуживают, потому что писали в соло, а не сотней человек, подтирая друг за другом косяки. Ну что ж, давайте катиться по наклонной дальше.
Ну сейчас-то да, безусловно, когда в ИТ-компаниях число разработчиков измеряется сотнями, а подчас и тысячами - действительно, замещая количеством качество - надо строить сложную многоуровневую систему ревью, писать автотесты, гонять код статическими анализаторами... и всё равно допускать ошибки.
Но, понимаете ли, так было не всегда. Было время, когда любой приличный админ мог написать патч к ядру или любому софту, а при случае - и свой собственный написать. Достаточно вспомнить, что nginx был написан Игорем Сысоевым, когда он работал админом в Рамблере, потому что производительности апача не хватало. И это решение вполне работало.
Или, как пример, найдите интервью с Алексеем Кузнецовым, одним из основных разработчиков IP-стека в линуксе - он там рассказывал, как им в институт притащили две дискеты с линуксом - правда, половины libc не было и пришлось дописать самостоятельно. И он тоже не был профессиональным программистом, он был физиком.
И ревьюить их код было банально некому, да и незачем, потому что это сейчас логика программиста "моё дело - тикеты в жире закрывать, а зачем они - то пусть ПМ думает". Там люди сами ставили себе задачи и сами их решали - и инженер, не умеющий в декомпозицию, попросту не мог называться инженером.
Или, на Ваш взгляд, человек, написавший в одиночку самый популярный веб-сервер в мире, недостоин высокого звания сеньора? А ведь он не был каким-то выдающимся исключением, на это был способен любой приличный специалист, если он вдавался в проблему.
Я возражал на комментарий, в котором человек заявлял, что "Сеньор это не про соло проекты", не более того.
Что нельзя быть сеньором в 22 - я, скорее, соглашусь. Притом, что я сам программирую с 9 лет, а сейчас мне 44 и я ещё успел застать "старую школу" (начинал, к слову, сразу с ассемблера).
При этом мне неоднократно приходилось делать крупные проекты либо в одиночку, либо в группе, но где мою часть знал только я. Зачем нужно ревьюить код сеньора с опытом в четверть века и зачем ради этого нанимать второго такого же - ну, мне не очень понятно.
Так речь и идёт о сеньорах, причём именно в нормальном смысле этого слова, с десятками лет опыта за плечами.
Покажите, пожалуйста, где написано, что сеньор обязательно должен проходить код-ревью, а не то он будет "колоссом на глиняных ногах"?
Кроме того, я говорил не о прохождении, а о проведении ревью самостоятельно. Это отдельный навык, безусловно полезный, но вовсе необязательный для сеньор-разработчика - если он, как было указано выше, писал исключительно соло-проекты.
И да, соло-проекты - это необязательно "сайт про меня и мою собачку жучку". Я знаю примеры крупных проектов с сотнями внедрений, написанных без код-ревью просто потому, что писали их люди, чей код ревьюить банально не было нужды (да и найти специалистов, способных это ревью провести, задача очень нетривиальная).
Как раз говорит. Потому что сеньор - это про умение строить архитектуру, умение поддерживать проект, про знание смежных областей. В соло-проектах именно эти навыки и необходимы. Когда никто, кроме тебя, не придумает общую концепцию проекта, не построит инфраструктуру, не обеспечит работоспособность.
Чего сеньор не получит в соло - это навыков распределения задач, совместной работы, код-ревью. Но это, по нынешним временам, уже скорее функции тимлида/техлида, сеньор-разработчику это необязательно.
А что в этом такого? Я начал программировать в 9, сеть техникума взломал в 16. Но это в ещё отсутствие Интернета, потому как в 80-х особого доступа не было.
Если парень начал с самого детства, имеет мозги и талант - то почему бы и не быть хакером в 12-15?
Отчасти это оправданно стоимостью сопровождения и поддержки. Со сторонней компанией можно заключить юридически понятный контракт на сопровождение, со своим отделом - ну вот увольняетесь Вы, как главный разработчик, и кто будет поддерживать эту систему? Ведь наверняка ни проектной документации, ни даже комментариев в коде особо нет. Стоимость владения получается непомерной - особенно с учётом зарплат отделу разработчиков.
Это может быть шагом к своему бизнесу, например. Потому что на одних технарских навыках далеко не уедешь, надо уметь продать себя и продукт, нужно уметь организовать разработку и добиться результата - а это как раз навыки хорошего ПМ.
А вот сочетая то и другое уже можно и на вольные хлеба идти, если есть желание.
Можно не совмещать, но иметь адекватный бэкграунд. Видел ПМ-а по банковским решениям с опытом ИТ-директора в нескольких банках и опытом разработчика. Вот там да, человек вменяемо мог и часы посчитать, и разработчикам всё объяснить, и заказчика размазать тонким слоем по столу и убедить в необходимости выделения бюджетов. Просто потому, что сам был на всех этих должностях.
В противном случае ПМ в лучшем случае будет играть роль секретарши, пригодной только организовать встречу заказчика с исполнителем.
Нормально руководить проектом может только техлид/архитектор, да и то - только если он вдобавок обладает навыками менеджера.
Только человек, который как видит весь проект целиком, так и понимает работу каждого фрагмента, может адекватно оценивать сроки, качество работы разработчиков, бюджеты, потребности. Если этого всего нет - РП превращается в говорящую куклу, вызывающую у всех досадливое отвращение: работы и так навалом, а тут ещё этот за штанину дёргает и чего-то клянчит. И единственная роль РП в этом случае - выступать мальчиком для битья в разговорах с заказчиком, да и то - только если заказчик технически неграмотен и сам не понимает происходящего.
"Раньше" было две категории: были разработчики и были системные администраторы (ещё раньше и администраторов не было, но в такую древность сейчас погружаться необязательно).
Разработчики писали софт, админы отвечали за работу этого софта на проде. В комплексе, потому что проблемы в работе могут вызываться чем угодно: кривыми руками пользователя, сбоями в сети, недостатком производительности серверов и ещё миллионом причин. И любой приличный админ умел программировать хотя бы на уровне прочитать код и написать патч, а хороший админ легко мог и ядро пропатчить, и свой драйвер файловой системы написать. Достаточно вспомнить, что nginx был написан, когда его автор, Игорь Сысоев, работал админом в Рамблере.
Потом решили, что "админы не нужны", потом придумали дево-псов, которые вроде бы должны сочетать разработку с администрированием, потом придумали SRE...
А по факту это всё те же админы. Только их мало осталось.
Фраза красивая, но это только один из частных случаев.
Во-первых, незаменимые есть всегда. Собственник, гендир. На этапе старта компании (а это нормальный этап, через который проходят все) незаменимость человека - норма жизни. Более того, ориентироваться на "заменимых" - значит ориентироваться не на квалифицированных специалистов, а на туповатых (но зато заменимых) середнячков, а с такими построить конкурентоспособный бизнес не получится.
Ну и, кроме того, это очень дорого, особенно на начальном этапе. Чтобы обеспечить возможность работы "середнячков" - должны быть очень качественно простроены бизнес-процессы, а это тоже должен сделать кто-то квалифицированный, сиречь незаменимый.
Как преступление - да.
С другой стороны, возместить иски продавец обязан и в рамках гражданского производства, причём ИП отвечает всем своим имуществом, а ООО - всем капиталом (то есть и средствами на балансе маркетплейса, в частности, то есть речь явно пойдёт о суммах больше уставняка).
Это риски ИП Иванова. Продавец несёт ответственность за соответствие товара заявленным им характеристикам. А китайцам он потом может подавать регрессный иск, если захочет.
Достаточно абонентского обслуживания от нормальной конторы с тем самым высококвалифицированным админом. Чтобы этот админ с самого начала замониторил всю сеть клиента и дальше спал, пока не замигает красная лампочка. Но когда замигает - мог нормально разобраться в проблеме, а не кидать камни по всем кустам в надежде, что под одним из них окажется заяц.
А раньше это просто называлось "инженерное мышление" и не было чем-то уникальным.
Вспомнить того же инженера Сайруса Смита из Жюль-Верновского "Таинственного острова". Чувак знает физику, химию, биологию, может из подручных материалов сделать хоть порох, хоть подъёмник. И это отнюдь не было чем-то фантастичным, это было нормальным для инженеров того времени.
Тогда было бы интересно увидеть больше технических деталей, чтобы понимать "профит" принятых решений.
Какая была нагрузка на сайт изначально? (RPS веб-сервера, QPS БД в разрезе селектов/апдейтов). Какая была конфигурация VPS? Какие ставились задачи в цифрах? (просто "увеличить производительность и управляемость" - это что-то на маркетоидном, это не про технические характеристики). На чём развернут кубернетес? - из статьи неочевидно: то ли вы утащили всё в облака, то ли развернули миникуб на той же самой vps, где всё и жило. СУБД тоже утащена в докер? (надеюсь, нет). Какую производительность модифицированный сайт показал на тестах? Что такое "повышение управляемости", сколько человек в команде, как часто происходят релизы, сколько времени они занимают, реализовывался ли blue-green deployment?
А то пока что ощущение, что речь идёт не о гигантах типа GetCourse, где подобный подход был бы оправдан, а о какой-то студенческой поделке на впс-ке, на которую зачем-то сверху накрутили кучу модных технологий "чтобы было".
Хороший пример совершения работы ради работы. Была вполне нормальная конфигурация, но зачем-то был внедрён докер, кубернетес (зачем? У вас десятки нод, которые надо оркестрировать? А базу вы тоже под докером крутите?), прометеус, разделение БД и так далее. Хотя в данном случае просто аренда более производительного выделенного сервера (хороший Xeon, гигов этак 64/128 памяти, пара NVMe дисков) обошлась бы на порядок дешевле зарплаты этого девопса, а проблему, при правильных настройках и оптимизации индексов, скорее всего решила бы - если уж до этого всё крутилось на VPS.
Нет, вместо этого начинаем рефакторинг всего и вся и каждый шаг добавляет лишнего геморроя. Ещё бы на микросервисы переписали. Больше работы богу работы.
Потому что политика. Одно дело, когда админ Вася рвёт на груди тельняшку перед руководителем: "Мамой клянусь, шеф, всё заработает!"; другое дело - когда разработчики двух продуктов официально подтвердили совместимость (и теперь несут ответственность за свои слова).