Это неправда. Ну писать г.нокод наверное да. Писать что то промышленное наверное нет (возможно я уже старый и медленнее) так то десяток разных языков на которых профессионально писал в багаже есть, собеседование с листа наверное по парочке пройду... Но за две недели на новом писать вряд ли
Но это тупик развития, невозможно быть техлидом программируя 20% времени, это просто проедание старого запаса, через три года максимум человек в лучшем случае понимает что он не тянет тех часть а в худшем думает что еще тянет. Видел полно и тех и других, сам чуть в эту ловушку не попал. Но вовремя соскочил, сосредоточился на том чтобы собрать в команду экспертов уровня каким сам был когда то, разгрузить их от рутины и непроизводственных дел, на себе тимлидство, стратегические технические решения (варианты прорабатываю не я но я выбираю финальный) ну и иногдамкогда завал могу что то покодить в прод (процентов 5 времени). Команда около 50 человек (моя)
Дочитал до Кнута и на этом остановился, не люблю вранья. Ьтак в целом идеи высказанные выше здравые, команда из синьора и 10 джунов это тупик, наставник который адаптирует джуна нужен, джут выращеный в компании лучше чем внешний.
...высшее образование полученное в одном из топ-20 ВУЗов. В остальных может говорить а может не говорить. В статье выше много ложных утверждений. Матан и линейка нужны чтобы потренировать мозги и отсеять не умеющих учиться. За 30 лет после ВУЗа не особо что пригодилось, для того чтобы O(n) от O(n*logn) отличить особого исследования функций не надо, достаточно общих соображений. Ну сейчас для DSов конечно побольше нужно математики, но тоже не 80 уровня :-) А условному фронтэнд разработчику другиеинавыки и умения нужны
Спор остроконечников с тупоконечниками. Есть два подхода, условно промышленый и условно крафтовый, в первои исполнитель (разработчик) знает о предметке примерно ничего во втором примерно все. И есть еще бесконечное число промежуточных вариантов. И все они (в том числе) применяются в жизни. Мне несколькоближе именно промышленный подход, но его труднее реализовать, нужна сложная работа с заказчиком по выстраиванию процессов, это никто не любит.
Проще тешить себя мыслью что ты лучше заказчика знаешь область которой он годы учился и потом годы нарабатывал опыт. И делать это каждому джуну. Никого не осуждаю, сам таким был
Причем и вопрос 2 наверное лишний :-) А так поддерживаю. Ну по крайней мере когда был разработчикои меня примерно тот же круг интересовал :-) И когда стал сам нанимать меня вполне устраивают разработчики которых только это интересует. Но те которые активные и много вопросов задают тоже нормально, как говорится всяк овощь к месту можно приспособить
У вас же контрольной группы нет. Типа людей которых ваша модель отбрасывает, вы все же их берете, и они таки уходят (ну или не уходят, ошибка модели). Без этого (извините за прямоту) вы не 1.4 м сэкономили а на 1.4 м повесили лапши на уши заказчику, выглядит так. Статистика ранних увольнений на таком количестве спокойно может быть выбросом (особенно учитывая ситуацию прошлого года). С другой стороны, сам подход имеет право на жизнь, возможно вы с параметрами угадали, время покажет.
Но описано толково и подробно, было интересно, так что, в любом случае спасибо и поставлю плюс
Очень интересный и проект и рассказ. Если не секрет, можете раскрыть примерный состав команды и срок реализации проекта (не-mvp). Приблизительно, чтобы порядок понять. Если не в количестве то хотя бы в % аналитики - разработчики - тестировщики.
Блин... вот как только вижу такие фразы, понимаю что 99% что пишущий сам Кнута не читал а максимум держал в руках эту стопку кирпичей. И совершенно не понимаю зачем он 90% разработчиков. Эта книга писалась в другое время для другой аудитории. Ладно, будем считать что вы относитесь к 1% кто прочел. Я при стаже в разработке 30 лет и N лет (помимо основной работы) чтения своего курс лекций по программной инженерии в фин.университете могу честно сказать в Кнуте главе на четвертой увяз еще в университетские годы, закрыл и с тех пор открывал раза три и понимал что не зря закрыл. Поэтому советовать егл джуну самоучке это так себе идея...
В том что (физиология) у них более инертное мышление. Новое осваивать дольше. Это легко компенсируется опытом, поэтому условно 30 летние с опытом 10 лет этого не замечают за собой и коллегами). Вы можете быть исключением, но в целом это так. Поэтому при наличии нормального потока 21-22 летних выпускников профильных вузов невыгодно рисковать.
P.S. Я ничего не знаю про фронтэнд (ну как ничего, на уровне джуна наверное знаю) не мой профиль, там наверняка своя специфика. В моем подразделении (около 50 человек) примерно поровну синьоров и миддлов (синьоров больше) и одна штатная единица джуна. Ну и максимум два стажера хотя столько не нужно задач нет для них... как правило за год полтора джун или уходит или становится миддлом, вот и рынок джунов... а миддлы нужны всегда
Не знаю, стоило ли писать. Со своей позиции нанимающего менеджера (с полным бекграундом разработчик - солюшн - ентерпрайз архитект - ...) Не нужен джун 30 летний примерно никому. Джуна можно и нужно брать как чистый лист под свои процессы, его растишь под себя и он или вливается или понимает что не его и уходит в поисках лучшей доли :-) Если мне нужен человек со своей сложившейся позицией с которым я буду советоваться, вполне возмоно доверять его экспертизе и даже делегировать ему решения за которые я отвечаю - я буду брать синьора. Если нужна рабочая лошадка с потенциалом я буду искать миддла с опытом РЕАЛЬНЫХ задач. НЕ пет проектов когда делаешьчто хочешь а реальных проектов когда делаешь реальные проекты по реальным требованиям бизнес заказчиков с реальными ограничениями. Увы но это так.
P.S. по 10 часов в день работать не надо (сам как и большинство руководителей работаю, конечно, боьше). Готовность работать по 12 часов в день это минус а не плюс, человек не может работать эффективно больше 5-6 часов в день, ну еще часа три на совещания и переписку. К счастью, меня этому научили на первой работе более 30 лет назад
P.P.S. Не опускайте руки, шанс есть хотя он невелик
Я как раз именно так и набираю к себе в команду, технических вопросов вообще не задаю, ну или минимум, смотрю как человек рассказывает о своем опыте, максимально полно рассказываю ему чем мы занимаемся вообще и чем будет заниматься конкретно он, собственно если в целом человек нормальный спрашиваю ну как, справишься? Если да то испыталка 3 мес, за человеком закрепляется наставник и поехали. За 12 лет и наверное полторы сотни кандидатов два не прогедших испыталку. Считаю, отличный показатель
Всегда смотрю на подобные подборки с некоторым скепсисом. Но эта приятное исключение. Не могу сказать что видел все, но почти все, и мое мнение совпадает с авторским процентов на 80. Из того что мне категорически не понравилось это книжка про тестирование с pytest, мне кажется она только запутывает, проше просто по документации все посмотреть
Есть мнение что вышеописаное не ппо тимлида а про бардак когда человека назвали тимлидом и навесили ему тучу несвойственных обязанностей, он как то с этим пытается справиться и описать другим как с этим справляться. А на самом деле тут яркий антипаттерн как быть не должно. Не должен тимдид одновременно общаться с клиентом, придумывать структуру веток в гите и кодить. В ООП это называется God Object и за это бьют по рукам. В управлении разработкой правила еще не так формализовались. Проблема в том, что даже если есть человек который способен делать это хорошо то потенциальная потеря этого человека становится недопустимым бизнес риском и, если это не стартап а продукт - так делать неправильно. А в целом много здравых идей есть, но, повторю они для разных ролей
Прочел до конца. Идея понятна, не очень понятна (пока) ценность. Допустим, у вас есть не один датасет, а 10 тыс. И, допустим, пара сотен аналитиков делающих с ними операции типа описаных выше. При этом, естественно, примерно 80% этих операций делается один раз (сделал, посмотрел, ерунда получилась, выкинул, забыл). При этом человек выполняющий операцию совершенно не в курсе какие ресурсы при этом задействованы. Кто (и зачем) будет назначать сущностям значения всех атрибутов?
Это неправда. Ну писать г.нокод наверное да. Писать что то промышленное наверное нет (возможно я уже старый и медленнее) так то десяток разных языков на которых профессионально писал в багаже есть, собеседование с листа наверное по парочке пройду... Но за две недели на новом писать вряд ли
Но это тупик развития, невозможно быть техлидом программируя 20% времени, это просто проедание старого запаса, через три года максимум человек в лучшем случае понимает что он не тянет тех часть а в худшем думает что еще тянет. Видел полно и тех и других, сам чуть в эту ловушку не попал. Но вовремя соскочил, сосредоточился на том чтобы собрать в команду экспертов уровня каким сам был когда то, разгрузить их от рутины и непроизводственных дел, на себе тимлидство, стратегические технические решения (варианты прорабатываю не я но я выбираю финальный) ну и иногдамкогда завал могу что то покодить в прод (процентов 5 времени). Команда около 50 человек (моя)
Дочитал до Кнута и на этом остановился, не люблю вранья. Ьтак в целом идеи высказанные выше здравые, команда из синьора и 10 джунов это тупик, наставник который адаптирует джуна нужен, джут выращеный в компании лучше чем внешний.
...высшее образование полученное в одном из топ-20 ВУЗов. В остальных может говорить а может не говорить. В статье выше много ложных утверждений. Матан и линейка нужны чтобы потренировать мозги и отсеять не умеющих учиться. За 30 лет после ВУЗа не особо что пригодилось, для того чтобы O(n) от O(n*logn) отличить особого исследования функций не надо, достаточно общих соображений. Ну сейчас для DSов конечно побольше нужно математики, но тоже не 80 уровня :-) А условному фронтэнд разработчику другиеинавыки и умения нужны
Спор остроконечников с тупоконечниками. Есть два подхода, условно промышленый и условно крафтовый, в первои исполнитель (разработчик) знает о предметке примерно ничего во втором примерно все. И есть еще бесконечное число промежуточных вариантов. И все они (в том числе) применяются в жизни. Мне несколькоближе именно промышленный подход, но его труднее реализовать, нужна сложная работа с заказчиком по выстраиванию процессов, это никто не любит.
Проще тешить себя мыслью что ты лучше заказчика знаешь область которой он годы учился и потом годы нарабатывал опыт. И делать это каждому джуну. Никого не осуждаю, сам таким был
Причем и вопрос 2 наверное лишний :-) А так поддерживаю. Ну по крайней мере когда был разработчикои меня примерно тот же круг интересовал :-) И когда стал сам нанимать меня вполне устраивают разработчики которых только это интересует. Но те которые активные и много вопросов задают тоже нормально, как говорится всяк овощь к месту можно приспособить
У вас же контрольной группы нет. Типа людей которых ваша модель отбрасывает, вы все же их берете, и они таки уходят (ну или не уходят, ошибка модели). Без этого (извините за прямоту) вы не 1.4 м сэкономили а на 1.4 м повесили лапши на уши заказчику, выглядит так. Статистика ранних увольнений на таком количестве спокойно может быть выбросом (особенно учитывая ситуацию прошлого года). С другой стороны, сам подход имеет право на жизнь, возможно вы с параметрами угадали, время покажет.
Но описано толково и подробно, было интересно, так что, в любом случае спасибо и поставлю плюс
Очень интересный и проект и рассказ. Если не секрет, можете раскрыть примерный состав команды и срок реализации проекта (не-mvp). Приблизительно, чтобы порядок понять. Если не в количестве то хотя бы в % аналитики - разработчики - тестировщики.
Блин... вот как только вижу такие фразы, понимаю что 99% что пишущий сам Кнута не читал а максимум держал в руках эту стопку кирпичей. И совершенно не понимаю зачем он 90% разработчиков. Эта книга писалась в другое время для другой аудитории. Ладно, будем считать что вы относитесь к 1% кто прочел. Я при стаже в разработке 30 лет и N лет (помимо основной работы) чтения своего курс лекций по программной инженерии в фин.университете могу честно сказать в Кнуте главе на четвертой увяз еще в университетские годы, закрыл и с тех пор открывал раза три и понимал что не зря закрыл. Поэтому советовать егл джуну самоучке это так себе идея...
Ух ты, as/400 еще где то есть? Последний раз ее вживую щупал лет 25 назад... Прям интересно стало пошел гуглить
В том что (физиология) у них более инертное мышление. Новое осваивать дольше. Это легко компенсируется опытом, поэтому условно 30 летние с опытом 10 лет этого не замечают за собой и коллегами). Вы можете быть исключением, но в целом это так. Поэтому при наличии нормального потока 21-22 летних выпускников профильных вузов невыгодно рисковать.
P.S. Я ничего не знаю про фронтэнд (ну как ничего, на уровне джуна наверное знаю) не мой профиль, там наверняка своя специфика. В моем подразделении (около 50 человек) примерно поровну синьоров и миддлов (синьоров больше) и одна штатная единица джуна. Ну и максимум два стажера хотя столько не нужно задач нет для них... как правило за год полтора джун или уходит или становится миддлом, вот и рынок джунов... а миддлы нужны всегда
Не знаю, стоило ли писать. Со своей позиции нанимающего менеджера (с полным бекграундом разработчик - солюшн - ентерпрайз архитект - ...) Не нужен джун 30 летний примерно никому. Джуна можно и нужно брать как чистый лист под свои процессы, его растишь под себя и он или вливается или понимает что не его и уходит в поисках лучшей доли :-) Если мне нужен человек со своей сложившейся позицией с которым я буду советоваться, вполне возмоно доверять его экспертизе и даже делегировать ему решения за которые я отвечаю - я буду брать синьора. Если нужна рабочая лошадка с потенциалом я буду искать миддла с опытом РЕАЛЬНЫХ задач. НЕ пет проектов когда делаешьчто хочешь а реальных проектов когда делаешь реальные проекты по реальным требованиям бизнес заказчиков с реальными ограничениями. Увы но это так.
P.S. по 10 часов в день работать не надо (сам как и большинство руководителей работаю, конечно, боьше). Готовность работать по 12 часов в день это минус а не плюс, человек не может работать эффективно больше 5-6 часов в день, ну еще часа три на совещания и переписку. К счастью, меня этому научили на первой работе более 30 лет назад
P.P.S. Не опускайте руки, шанс есть хотя он невелик
Я как раз именно так и набираю к себе в команду, технических вопросов вообще не задаю, ну или минимум, смотрю как человек рассказывает о своем опыте, максимально полно рассказываю ему чем мы занимаемся вообще и чем будет заниматься конкретно он, собственно если в целом человек нормальный спрашиваю ну как, справишься? Если да то испыталка 3 мес, за человеком закрепляется наставник и поехали. За 12 лет и наверное полторы сотни кандидатов два не прогедших испыталку. Считаю, отличный показатель
Всегда смотрю на подобные подборки с некоторым скепсисом. Но эта приятное исключение. Не могу сказать что видел все, но почти все, и мое мнение совпадает с авторским процентов на 80. Из того что мне категорически не понравилось это книжка про тестирование с pytest, мне кажется она только запутывает, проше просто по документации все посмотреть
Есть мнение что вышеописаное не ппо тимлида а про бардак когда человека назвали тимлидом и навесили ему тучу несвойственных обязанностей, он как то с этим пытается справиться и описать другим как с этим справляться. А на самом деле тут яркий антипаттерн как быть не должно. Не должен тимдид одновременно общаться с клиентом, придумывать структуру веток в гите и кодить. В ООП это называется God Object и за это бьют по рукам. В управлении разработкой правила еще не так формализовались. Проблема в том, что даже если есть человек который способен делать это хорошо то потенциальная потеря этого человека становится недопустимым бизнес риском и, если это не стартап а продукт - так делать неправильно. А в целом много здравых идей есть, но, повторю они для разных ролей
Прочел до конца. Идея понятна, не очень понятна (пока) ценность. Допустим, у вас есть не один датасет, а 10 тыс. И, допустим, пара сотен аналитиков делающих с ними операции типа описаных выше. При этом, естественно, примерно 80% этих операций делается один раз (сделал, посмотрел, ерунда получилась, выкинул, забыл). При этом человек выполняющий операцию совершенно не в курсе какие ресурсы при этом задействованы. Кто (и зачем) будет назначать сущностям значения всех атрибутов?