роль техлида зачастую не оформляется формально — сотрудник технического отдела просто берет на себя дополнительные интересные ему задачи.
...
тимлиды и техлиды в ПСБ — скорее неформальные лидеры, которые могут быть назначены на кураторство определенных факультативных задач
...
тимлиды в ПСБ официально не считаются управленцами, к работе своей команды грамотный тимлид подходит и с позиции хорошего менеджера.
А в чем сложность все-таки сделать нормальные официальные должности с прозрачным и понятным путем роста до них? А то, честно говоря, со стороны выглядит как попытка компании схитрить - обязанности дополнительные появляются, а оклад остается как у обычного программиста.
Обычно грейды взаимосвязаны с повышением зарплаты, и как раз вводятся для того, чтобы сотрудникам было прозрачно и понятно, как повысить уровень оплаты своего труда. Так что, думаю, такого нет, что просто вешается лычка senior-грейда без изменения уровня зарплаты. Иначе это было бы совсем уж странно.
Я думаю, не стоит путать ревью и решение задач на собеседованиях/литкоде. Ревьюер ведь это не тот кто знает единственно верное решение, а тот, кто делится альтернативным взглядом на решение. И предлагаемое решение абсолютно не факт, что будет единственно возможным, что и подтверждают комментарии к этой статье выше.
А по поводу "развивать" - имхо, на ревью это уже поздновато делать. Это должно происходить где-то гораздо раньше ДО ревью: на митапах, внутренних докладах, в документации и т.п. А тут видно из начального решения, что разработчик понятия не имел о предпочтениях тимлида по функциональному подходу, и на него это все свалилось как кирпич на голову прямо на ревью, когда время на решение уже потрачено, код уже написан и только ждет, чтобы его поскорее одобрили и выкатили на прод :)
В целом, конечно, радует, когда ревью делается не для галочки, а вот так вот подробно рассматриваются варианты улучшения.
Но, честное слово, я бы убрал вот эти вот игры в "поле чудес" с вопросами вида "а попробуй догадаться, почему мне это не нравится". Респект разработчику, что он очень адекватно реагировал на такое - я видел много ситуаций, когда автор кода был не столь терпелив) В общем, на будущее совет - если Senior или Team Lead видит пути улучшения, лучше просто банально написать о них, не стоит пытаться демонстрировать собственное превосходство и играть в угадайки :)
Спасибо большое за проделанную работу и подробное описание. Но, к сожалению, как и во многих других статьях на тему грейдов и|или компетенций, почему-то все ограничивается уже избитой цепочкой Junior -> Middle -> Senior -> Team Lead.
Гораздо более интересно было бы увидеть еще и то, как у вас можно планировать карьерный рост человеку уровня Senior, который не хочет переходить в менеджерскую ветку и становиться тимлидом, но при этом уже перерос должность разработчика-исполнителя. Ведь есть же еще такие технические должности как Архитектор, Principal Engineer и т.д. И также хотелось бы понимать, а как дальше у вас карьерно расти человеку, который уже Team Lead.
Было бы здорово увидеть это в следующих статьях :)
По-моему, и так большинству понятно, что "алгоритм машинного обучения" это то же самое, что и "алгоритм, используемый в машинном обучении". Зачем до придирок к таким мелочам то доходить? :)
Не понял каким образом линейная регрессия превратилась в алгоритм машинного обучения
А что не так? Машинное обучение это ведь не только нейросети и deep learning. Действительно, линейная регрессия это один из простейших supervised learning алгоритмов:
По-моему, все смешано в кучу. Principal Engineer это вообще другая ветка, а не следующая ступенька после Team Lead. Должность Team Lead означает, что специалист уже выбрал менеджерскую ветку. Конечно, возможно, что в конкретной этой компании нельзя стать Principal без управления командой, но звучит странно.
Проблема в том, что вы медленно окажетесь в мире, где каждая база кода написана на собственном подмножестве языка.
Не вижу ничего плохого в том, что кодовые базы разных проектов и организаций используют разный стиль. Важно, чтобы в одной и той же кодовой базе стиль был одинаковый.
Так же как и города во всем мире не обязаны быть как под копирку. Главное, чтобы на одной и той же улице рядом со строениями 18-го века не стояли небоскребы :)
Взять упомянутый язык Scala. В каких-то командах привыкли использовать его в "better Java" стиле, какие-то команды любят и умеют писать на Scala в функциональном стиле.
Было бы очень странно и бессмысленно всем в мире диктовать "используй от всей Scala только ООП подмножество" или "ты обязан писать на Scala исключительно в функциональном стиле".
Так я и написал "дать конструктивную оценку". Информацию о том, что у кандидата плохие знания по Java не обязательно доносить именно в категоричной форме. Но мой посыл был в другом - в том, что предлагаемый автором "правильный" вариант еще хуже.
Неплохая статья, многие вещи я и для себя отмечал. Но вот с одним моментом я не согласен полностью:
никаких персональных оценок, вроде «вы недостаточно квалифицированы» или «у вас плохие знания Java». Так нельзя отвечать — это очень грубо. Просто сообщают что не готовы сделать предложение и приглашают попробовать еще раз через год.
В чем грубость дать конструктивную оценку по поводу конкретных областей, которые нужно улучшить кандидату? Чем лучше давать абсолютно неинформативный ответ вида "мы не готовы сделать вам предложение"? По такой логике, кандидат потом должен сидеть и гадать, в каком из пяти интервью и что он сказал не так.
Как раз-таки проблема в том, что часто представление того, что нужно от тимлида, очень расплывчатое. Ему приписывают и то, что он должен быть самым крутым разработчиком в команде, к которому все ходят за помощью, и то что он должен быть архитектором, который утверждает все подходы и технологии. Но на самом деле же тимлид это про другое - про управление командой и умение делегировать. Я знал случаи, когда команду программистов успешно тимлидит человек с бэкграундом вообще не с теми языками программирования, на которых пишется проект.
Жаль, что в локальных IT-компаниях стран СНГ обычно или идти в тимлиды, или Senior Dev до пенсии. Была бы чуть больше развита культура роста в техническом направлении выше Senior Dev - уверен, было бы гораздо меньше тимлидов не на своих местах.
Всегда было интересно, откуда это желание управлять всем и сразу. Ведь если объективно один партнёр хорош как product manager, но слабоват как техлид, а второй хорош как техлид, но такой себе предприниматель, можно же разделить обязанности, но при этом по-прежнему владеть равноценными долями компании.
Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
В общем, ладно, я чувствую, что все советы не будут тут восприниматься, потому что вы заранее сконцентрировались на идее «сделать аналог метода PATH в REST», и только эта идея кажется вам логичной и красивой. Если вам нравится менять состояние БД через queries — на здоровье :)
Теперь давайте все-таки отложим в сторону REST с его различиями null\undefined и попробуем посмотреть на мутации как на функции в языках программирования. И, вместо вашего оригинального технического решения, которое меняет состояние БД в query-запросах (причем, каждое поле в отдельном запросе к БД), можно решить задачу, например, так:
# Создаем input, где все поля - опциональные
input ExampleOptionalInput {
foo: String
bar: String
}
# Создаем мутацию с доп. аргументом
type Mutation {
updateExampleOptionally(input: ExampleOptionalInput!, onlyFields: [String!]): Example
}
Приводите, пожалуйста, аргументы или какую-то статистику к своим выводам, а то обсуждение получается немного бесполезным.
Optimistic lock это просто и поддерживается некоторыми ORM вообще из коробки. Надеяться на partial update как на основное решение при совместном редактировании считаю непрофессиональным. Где-то оно, может, и будет помогать худо-бедно, а где-то, где, скажем, поле «описание» у товара редактируется в 10 раз чаще других полей — не будет.
А в чем сложность все-таки сделать нормальные официальные должности с прозрачным и понятным путем роста до них? А то, честно говоря, со стороны выглядит как попытка компании схитрить - обязанности дополнительные появляются, а оклад остается как у обычного программиста.
Обычно грейды взаимосвязаны с повышением зарплаты, и как раз вводятся для того, чтобы сотрудникам было прозрачно и понятно, как повысить уровень оплаты своего труда. Так что, думаю, такого нет, что просто вешается лычка senior-грейда без изменения уровня зарплаты. Иначе это было бы совсем уж странно.
Я думаю, не стоит путать ревью и решение задач на собеседованиях/литкоде. Ревьюер ведь это не тот кто знает единственно верное решение, а тот, кто делится альтернативным взглядом на решение. И предлагаемое решение абсолютно не факт, что будет единственно возможным, что и подтверждают комментарии к этой статье выше.
А по поводу "развивать" - имхо, на ревью это уже поздновато делать. Это должно происходить где-то гораздо раньше ДО ревью: на митапах, внутренних докладах, в документации и т.п. А тут видно из начального решения, что разработчик понятия не имел о предпочтениях тимлида по функциональному подходу, и на него это все свалилось как кирпич на голову прямо на ревью, когда время на решение уже потрачено, код уже написан и только ждет, чтобы его поскорее одобрили и выкатили на прод :)
В целом, конечно, радует, когда ревью делается не для галочки, а вот так вот подробно рассматриваются варианты улучшения.
Но, честное слово, я бы убрал вот эти вот игры в "поле чудес" с вопросами вида "а попробуй догадаться, почему мне это не нравится". Респект разработчику, что он очень адекватно реагировал на такое - я видел много ситуаций, когда автор кода был не столь терпелив) В общем, на будущее совет - если Senior или Team Lead видит пути улучшения, лучше просто банально написать о них, не стоит пытаться демонстрировать собственное превосходство и играть в угадайки :)
Спасибо большое за проделанную работу и подробное описание. Но, к сожалению, как и во многих других статьях на тему грейдов и|или компетенций, почему-то все ограничивается уже избитой цепочкой Junior -> Middle -> Senior -> Team Lead.
Гораздо более интересно было бы увидеть еще и то, как у вас можно планировать карьерный рост человеку уровня Senior, который не хочет переходить в менеджерскую ветку и становиться тимлидом, но при этом уже перерос должность разработчика-исполнителя. Ведь есть же еще такие технические должности как Архитектор, Principal Engineer и т.д. И также хотелось бы понимать, а как дальше у вас карьерно расти человеку, который уже Team Lead.
Было бы здорово увидеть это в следующих статьях :)
По-моему, и так большинству понятно, что "алгоритм машинного обучения" это то же самое, что и "алгоритм, используемый в машинном обучении". Зачем до придирок к таким мелочам то доходить? :)
И нейросети, кстати, это только одно из подмножеств машинного обучения, а не вся его основа. Навскидку: https://www.coursera.org/articles/machine-learning-vs-neural-networks
А что не так? Машинное обучение это ведь не только нейросети и deep learning. Действительно, линейная регрессия это один из простейших supervised learning алгоритмов:
https://en.m.wikipedia.org/wiki/Supervised_learning#Algorithms
По-моему, все смешано в кучу. Principal Engineer это вообще другая ветка, а не следующая ступенька после Team Lead. Должность Team Lead означает, что специалист уже выбрал менеджерскую ветку.
Конечно, возможно, что в конкретной этой компании нельзя стать Principal без управления командой, но звучит странно.
Не вижу ничего плохого в том, что кодовые базы разных проектов и организаций используют разный стиль. Важно, чтобы в одной и той же кодовой базе стиль был одинаковый.
Так же как и города во всем мире не обязаны быть как под копирку. Главное, чтобы на одной и той же улице рядом со строениями 18-го века не стояли небоскребы :)
Взять упомянутый язык Scala. В каких-то командах привыкли использовать его в "better Java" стиле, какие-то команды любят и умеют писать на Scala в функциональном стиле.
Было бы очень странно и бессмысленно всем в мире диктовать "используй от всей Scala только ООП подмножество" или "ты обязан писать на Scala исключительно в функциональном стиле".
"Выгодное налогооблАжение" это интересно..
Так я и написал "дать конструктивную оценку". Информацию о том, что у кандидата плохие знания по Java не обязательно доносить именно в категоричной форме. Но мой посыл был в другом - в том, что предлагаемый автором "правильный" вариант еще хуже.
Неплохая статья, многие вещи я и для себя отмечал. Но вот с одним моментом я не согласен полностью:
В чем грубость дать конструктивную оценку по поводу конкретных областей, которые нужно улучшить кандидату? Чем лучше давать абсолютно неинформативный ответ вида "мы не готовы сделать вам предложение"? По такой логике, кандидат потом должен сидеть и гадать, в каком из пяти интервью и что он сказал не так.
Как раз-таки проблема в том, что часто представление того, что нужно от тимлида, очень расплывчатое. Ему приписывают и то, что он должен быть самым крутым разработчиком в команде, к которому все ходят за помощью, и то что он должен быть архитектором, который утверждает все подходы и технологии. Но на самом деле же тимлид это про другое - про управление командой и умение делегировать. Я знал случаи, когда команду программистов успешно тимлидит человек с бэкграундом вообще не с теми языками программирования, на которых пишется проект.
Жаль, что в локальных IT-компаниях стран СНГ обычно или идти в тимлиды, или Senior Dev до пенсии. Была бы чуть больше развита культура роста в техническом направлении выше Senior Dev - уверен, было бы гораздо меньше тимлидов не на своих местах.
Всегда было интересно, откуда это желание управлять всем и сразу. Ведь если объективно один партнёр хорош как product manager, но слабоват как техлид, а второй хорош как техлид, но такой себе предприниматель, можно же разделить обязанности, но при этом по-прежнему владеть равноценными долями компании.
Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
Будет одна транзакция. Запросов
UPDATEбудет несколько.Естественно, можно много как организовать валидацию. Основной смысл не меняется.
С таким аргументом и не поспоришь :)
null\undefinedи попробуем посмотреть на мутации как на функции в языках программирования. И, вместо вашего оригинального технического решения, которое меняет состояние БД в query-запросах (причем, каждое поле в отдельном запросе к БД), можно решить задачу, например, так:Optimistic lock это просто и поддерживается некоторыми ORM вообще из коробки. Надеяться на
partial updateкак на основное решение при совместном редактировании считаю непрофессиональным. Где-то оно, может, и будет помогать худо-бедно, а где-то, где, скажем, поле «описание» у товара редактируется в 10 раз чаще других полей — не будет.