Спасибо большое, что заметили! Поправили, перевыложили. Хотите какой-нибудь наш swag?) С последнего митапа остались носки со смайлами и логотипами, наклейки на ноут) Такого типа:
Зато наши спутники быстрые в разработке. Если всё писать на ассемблере под QNX — мы никогда не догоним Илона Маска!
Кроме шуток, вы чего такой серьёзный? Понятно же (или нет?), что это спека на типичный 12-factor микросервис, и по результатам имплементации должно быть видно, насколько кандидат разбирается в архитектуре, паттернах, особенностях языка, как он пишет код, как документирует, как тестирует — вот это вот всё. Мы в FunCorp спутники (пока) не запускаем, мы доставляем людям радость без использования баллистических носителей)
Ровно поэтому я при найме инженеров настаиваю на тестовом задании. А в ответ на это задание даю подробное ревью кода, архитектурных решений и рекомендации по улучшению, сопровождая это текстом типа "если вы будете работать у нас, то при приёмке такой задачи коллеги скажут вам то-то и то-то".
при опросе 1 раз в 6 часов — 135 месяцев или 11,2 года
Я бы на вашем месте не стал делать такую интерполяцию фактически по двум точкам. Если честно посчитать погрешность такого вычисления, то получится ±50 месяцев :) Да и в первой колонке видно, что зависимость нелинейная.
По пунктам 1 и 2 мы с вами живём, возможно, в несколько разных измерениях. Я верю, что сменить работу программисту сегодня несложно. Прокачать скиллы, если их не хватает — вполне реально. Так что если человек сидит в ядовитом болоте — скорее всего он это делает не против своей воли, а от лени.
Пункт 3 не объясняет, как мы приходим к выбору "или Линус ругается как чёрт, или линукс не является нужным". Можно ревьюить код незнакомых людей, не ругаясь при этом как чёрт.
Лично я — нет, но догадываюсь, что это сложный и дорогостоящий процесс, поэтому мы рассматриваем такой вариант как аварийный. Тайвань нас полностью устраивает.
Нет, мы не в равных условиях. Если Semtech захочет отключить Россию от LoRa — LoRa в России закончится, потому что никому не надо создавать здесь независимый филиал, получать по суду "принудительные лицензии" и т.п., минимум полтора года поднимая всё из руин. Если Китай захочет отключить "Стрижа" от своих fabs — перенести производство чипов, на которые есть все маски и документация — вопрос единиц месяцев, и технически можно сделать это хоть в Зеленограде.
Ээээ… Вот сейчас вы меня удивили. Вы правда не видите разницы между правообладателем и производителем? Чипы LoRa уже сейчас скорее всего недоступны для компаний из санкционного списка, поскольку Semtech — американская компания. Наверняка поставщикам решений на LoRa в РФ можно забыть про госзаказ и контракты компаний с существенным государственным участием.
При этом экономическая блокада РФ со стороны Китая — на ближайшие несколько лет просто басня, мы для Китая один из ключевых рынков, и значимость растёт с разгаром торговых войн между Китаем и США. Но даже в том исчезающе маловероятном случае каких-то проблем с Китаем (которые, если и начнутся, то скорее будут носить коммерческий характер, как с производством чипов для майнинга крипты) — перенос производства в любую другую страну, обладающую технологией для производства чипов — вопрос пары-тройки месяцев, на это время у нас, конечно, есть запас.
Я уже писал выше: становитесь партнёром, покупайте devkit'ы, и заглядывайте так глубоко, как вам хочется)
Что до изъянов, то они в целом всему рынку известны: небольшая скорость передачи данных, пакеты фиксированного размера, тоже очень маленькие, неуверенный downlink, особенно для устройств с батарейным питанием (кстати, мы, похоже, нащупали способ существенно тут улучшить нашу платформу), отсутствие подтверждения доставки… Ну так мы и не претендуем на полный охват. Где-то проще использовать Bluetooth, где-то ZigBee, где-то вообще WiFi. А мы — это дальность, дешевизна по деньгам и питанию, помехоустойчивость.
В описываемой вами ситуации придётся создавать в РФ структуру, которая возьмёт на себя разработку, производство и поддержку этих чипов и технологии в целом. Очевидно, что существующей структуре это поручить не удастся, потому что её затаскают по судам за рубежом. На самом деле конечно никто ничего создавать не будет, потому что это никому, кроме интеграторов решений LoRa, не нужно.
Кстати в таком контексте — а чипы Стрижа где производятся?
То ли на Тайване, то ли в Гонконге, не помню точно.
Вы удивитесь как много людей не имеют возможности "не принять" и не имеют возможности "перейти в команду, где такого быть не может" (потому что таких команд мало).
Я не согласен по обоим пунктам. Команд, "где такого быть не может", возможно, мало, но всё же невыносимо токсичных команд, активно сопротивляющихся изменениям, ещё меньше. Разработчики ПО в современном мире — довольно привилегированная каста, стоят они дорого, значительную часть их стоимости составляет их экспертиза, нанимать их сложно, поэтому к их мнению, особенно консолидированному, чаще прислушиваются.
Если развивать вашу позицию, то мы придем к выбору: или Линус ругается как черт, или линукс не является нужным.
Это мой первый опыт перевода, и блин может быть комом, прошу меня простить. "Пожалуйста, не надо так делать" — это цитата из Линуса, и я думаю, что в рассылке Linux Kernel он более чем имеет право именно так написать, а адресатам надо будет внимательно прислушаться. Впрочем он наверняка не ограничится простым "не надо так делать", а в двух словах пояснит, почему именно так не надо.
Да и нет. Действительно атмосфера в коллективе ощущается как воздух (хороший каламбур, спасибо), но до тех пор, пока никто не занимается исследованием атмосферы или не появляется потребность сформулировать ценности команды. Буквально пару недель назад у нас в "Стриже" случилось ровно такое озарение: наш фаундер имеет большой опыт работы в консалтинге, в том числе в Big Four, и когда в очередной раз кто-то поднял вопрос о том, что хорошо бы сформировать наши ценности, он взорвался филиппикой на тему, что формирование ценностей — это корпоративный буллшит, которого он не потерпит. "Мы не берем на работу мудаков — вот наша основная ценность!". На этом месте все переглянулись и сказали, что ценность отличная и давно надо было её так и сформулировать. "Приходя на работу к нам люди могут быть уверены, что у них не будет мудака-начальника и мудаков-коллег". Мы, конечно, напишем это в описании вакансий менее радикальными словами, но суть такова)
У этого кейса может быть много правильных решений, в том числе зависящих от конкретной команды, существующих в ней практик и взаимоотношений внутри, поэтому дальше — моё мнение, основанное на моём опыте и не претендующее на всесторонность.
Первое, на что бы я обратил внимание — это недостаточный контроль выполнения задач со стороны руководителя отдела и/или прямого руководителя бойца. Выявлять потенциальную проблему такого масштаба нужно на более ранних сроках, пока она не стала критической (дедлайн так близок, что время есть только на передачу таска другому, более опытному бойцу).
Далее, я бы разобрал, почему передача таска ощущается бойцом как грубость. Если ситуация такова, как вы описываете, и все, включая его самого, согласны с тем, что боец а) фатально провалил сдачу в срок б) не в состоянии самостоятельно справиться с проблемой в оставшееся время, то передать задачу другому члену команды — по сути единственное возможное решение, и ничего зазорного в этом нет. Если сам боец не согласен с такой постановкой вопроса — нужно подробно разобрать, откуда берутся эти разногласия, и приложить усилия к донесению до него реального положения дел, попутно проведя reality check на своей стороне: все мы можем ошибаться. В крайнем случае годится аргумент: "я верю в тебя, но я опасаюсь, что ты не справишься по каким-либо ещё, кроме твоей компетентности, причинам, а задача слишком важна и у нас уже не осталось права на ошибку. Мой уровень тревоги сейчас слишком высок, я предпочту более надёжный вариант". Обратите внимание, я перемежаю технические аргументы с высказыванием чувств и эмоций: вера в, опасение, тревога, то есть демонстрирую, что решение одновременно и техническое, и эмоциональное.
Далее подыскать ему менее срочную задачу, требующую для решения нужные абстракции и инструменты, заложить полуторный срок и внимательно контролировать процесс её решения, требуя промежуточных коммитов каждый день или даже несколько раз в день, обсуждать с ним, как он осваивает и правильно ли использует новые для него знания.
Ничего себе, слона-то я и не заметил. Спасибо, что увидели лишний абзац, удалил.
Что токсичные команды существует в реальной жизни — я не сомневаюсь, хотя сам и не видел. Например на одном из мест работы я взял в команду человека из крупного онлайн-ритейлера. Он рассказывал просто какой-то хоррор: плохие условия труда, штрафы за опоздания, штрафы за пропущенные баги, интриги и подсиживания. Мы его два месяца просто выхаживали всей командой, как подранка, пока он понял, что тут его не будут истязать и заставлять работать по 10-11 часов, что тут можно экспериментировать и совершать ошибки в процессе, что тут его ценят, относятся с уважением и т.д. Почему он не ушёл при первой же возможности? Обычная история: маленький ребёнок и кредиты.
Так что есть многое на свете, друг Горацио, что мы своим рациональным мозгом сходу отвергнем как невозможное. И понятно, что автор исходной статьи не противопоставляет черное белому, а предлагает по возможности двигаться по шкале на светлую сторону.
В команду с декларированными ценностями, которая готова эти ценности защищать, невозможно кого-то "запустить": команда их просто не примет, а если попытаться ей такое решение насадить с позиции силы, то просто уйдёт, благо у разработчиков такого уровня обычно 1-2 оффера всегда открыты.
Нормальная человеческая улыбка никогда не была маркером агрессии. Посмотрите на улыбающихся годовалых детей, например. Маркером агрессии может быть американский противоестественный оскал в 32 зуба, но, надо признать, я давно не встречал его в реальной жизни. Смех несёт в себе заряд агрессии, но намного больше смех представляет из себя выражение облегчения. Наши родственники-приматы всегда смеются над хищником с высокого дерева и никогда — с земли :)
Мы вообще сейчас зайдём в тёмный лес тонких психологических материй. Это тоже софтскилл: в комментарии на веб-странице так выстроить фразу, чтобы человек воспринял её не как направленную на себя, а как "вот смотри, мы стоим с тобой рядом, я показываю пальцем на дурацкие, по моему мнению, практики где-то там и предлагаю тебе присоединиться к моему презрению". У упомянутого Джорджа Карлина это неплохо получалось, а попробуйте прослушать любую его миниатюру как направленную лично на себя; то ещё удовольствие.
Примеров того, как коллективы, построенные на взаимоуважении и декларирующие его как ценность выдавливали из себя токсичных представителей — сотни. Мой эталон — отдел разработки Яндекса при Сегаловиче и как изменилась вся компания при Императоре и далее с уходом Колмановской.
Могу привести десятки примеров, когда "накосячивших" разработчиков не только не увольняли, но наоборот — делали из катастроф дидактические кейсы. Возьмите, например, инцидент с дропом базы Gitlab в январе 2017. Виновный продолжает работать и даже официально получил должность Senior data loss engineer :) Потому что если подумать, то увольнять человека, только что получившего колоссальный кусок опыта, который мало кто мало где вообще когда-нибудь получит — это несколько расточительно.
И да, главное в современной компании не качество и не скорость написания кода, главное — это объём знаний, сосредоточенный в компании. Компании, которые быстро пишут код за деньги, сами их сотрудники называют "галерами", по аналогии с трудом римских рабов на флоте. Этому феномену посвящен целый сайт https://ebanoe.it/, рекомендую ознакомиться, прямо живая иллюстрация анекдота про мышей и кактус.
И наконец: в современной медицине вывихи вправляются с обезболиванием. Максима "no pain — no gain", как и любая генерализация, ложна.
Это отсутствие так называемых софтскиллов. Дело не в понимании, а в неумении считывать невербальную обратную связь и нежелании слышать вербальную. Возможно процедура code review через инструменты типа Github/Gitlab, общение через почту и мессенджеры этому способствует, потому что там обратную связь считать или получить почти невозможно.
Да, спасибо! Сейчас поменяем в примере. Предлагаю приз за внимательность, см. коммент выше)
Спасибо большое, что заметили! Поправили, перевыложили. Хотите какой-нибудь наш swag?) С последнего митапа остались носки со смайлами и логотипами, наклейки на ноут) Такого типа:
https://www.facebook.com/FunCorpDev/photos/a.2474687749231993/2474688732565228/?type=3&permPage=1
https://www.facebook.com/FunCorpDev/photos/a.2474687749231993/2474687825898652/?type=3&permPage=1
Зато наши спутники быстрые в разработке. Если всё писать на ассемблере под QNX — мы никогда не догоним Илона Маска!
Кроме шуток, вы чего такой серьёзный? Понятно же (или нет?), что это спека на типичный 12-factor микросервис, и по результатам имплементации должно быть видно, насколько кандидат разбирается в архитектуре, паттернах, особенностях языка, как он пишет код, как документирует, как тестирует — вот это вот всё. Мы в FunCorp спутники (пока) не запускаем, мы доставляем людям радость без использования баллистических носителей)
Ровно поэтому я при найме инженеров настаиваю на тестовом задании. А в ответ на это задание даю подробное ревью кода, архитектурных решений и рекомендации по улучшению, сопровождая это текстом типа "если вы будете работать у нас, то при приёмке такой задачи коллеги скажут вам то-то и то-то".
Интересное исследование, спасибо!
Я бы на вашем месте не стал делать такую интерполяцию фактически по двум точкам. Если честно посчитать погрешность такого вычисления, то получится ±50 месяцев :) Да и в первой колонке видно, что зависимость нелинейная.
По пунктам 1 и 2 мы с вами живём, возможно, в несколько разных измерениях. Я верю, что сменить работу программисту сегодня несложно. Прокачать скиллы, если их не хватает — вполне реально. Так что если человек сидит в ядовитом болоте — скорее всего он это делает не против своей воли, а от лени.
Пункт 3 не объясняет, как мы приходим к выбору "или Линус ругается как чёрт, или линукс не является нужным". Можно ревьюить код незнакомых людей, не ругаясь при этом как чёрт.
Лично я — нет, но догадываюсь, что это сложный и дорогостоящий процесс, поэтому мы рассматриваем такой вариант как аварийный. Тайвань нас полностью устраивает.
Нет, мы не в равных условиях. Если Semtech захочет отключить Россию от LoRa — LoRa в России закончится, потому что никому не надо создавать здесь независимый филиал, получать по суду "принудительные лицензии" и т.п., минимум полтора года поднимая всё из руин. Если Китай захочет отключить "Стрижа" от своих fabs — перенести производство чипов, на которые есть все маски и документация — вопрос единиц месяцев, и технически можно сделать это хоть в Зеленограде.
Ээээ… Вот сейчас вы меня удивили. Вы правда не видите разницы между правообладателем и производителем? Чипы LoRa уже сейчас скорее всего недоступны для компаний из санкционного списка, поскольку Semtech — американская компания. Наверняка поставщикам решений на LoRa в РФ можно забыть про госзаказ и контракты компаний с существенным государственным участием.
При этом экономическая блокада РФ со стороны Китая — на ближайшие несколько лет просто басня, мы для Китая один из ключевых рынков, и значимость растёт с разгаром торговых войн между Китаем и США. Но даже в том исчезающе маловероятном случае каких-то проблем с Китаем (которые, если и начнутся, то скорее будут носить коммерческий характер, как с производством чипов для майнинга крипты) — перенос производства в любую другую страну, обладающую технологией для производства чипов — вопрос пары-тройки месяцев, на это время у нас, конечно, есть запас.
Я уже писал выше: становитесь партнёром, покупайте devkit'ы, и заглядывайте так глубоко, как вам хочется)
Что до изъянов, то они в целом всему рынку известны: небольшая скорость передачи данных, пакеты фиксированного размера, тоже очень маленькие, неуверенный downlink, особенно для устройств с батарейным питанием (кстати, мы, похоже, нащупали способ существенно тут улучшить нашу платформу), отсутствие подтверждения доставки… Ну так мы и не претендуем на полный охват. Где-то проще использовать Bluetooth, где-то ZigBee, где-то вообще WiFi. А мы — это дальность, дешевизна по деньгам и питанию, помехоустойчивость.
-
В описываемой вами ситуации придётся создавать в РФ структуру, которая возьмёт на себя разработку, производство и поддержку этих чипов и технологии в целом. Очевидно, что существующей структуре это поручить не удастся, потому что её затаскают по судам за рубежом. На самом деле конечно никто ничего создавать не будет, потому что это никому, кроме интеграторов решений LoRa, не нужно.
То ли на Тайване, то ли в Гонконге, не помню точно.
Я не согласен по обоим пунктам. Команд, "где такого быть не может", возможно, мало, но всё же невыносимо токсичных команд, активно сопротивляющихся изменениям, ещё меньше. Разработчики ПО в современном мире — довольно привилегированная каста, стоят они дорого, значительную часть их стоимости составляет их экспертиза, нанимать их сложно, поэтому к их мнению, особенно консолидированному, чаще прислушиваются.
Как именно мы придём к такому выбору?!
Это мой первый опыт перевода, и блин может быть комом, прошу меня простить. "Пожалуйста, не надо так делать" — это цитата из Линуса, и я думаю, что в рассылке Linux Kernel он более чем имеет право именно так написать, а адресатам надо будет внимательно прислушаться. Впрочем он наверняка не ограничится простым "не надо так делать", а в двух словах пояснит, почему именно так не надо.
Да и нет. Действительно атмосфера в коллективе ощущается как воздух (хороший каламбур, спасибо), но до тех пор, пока никто не занимается исследованием атмосферы или не появляется потребность сформулировать ценности команды. Буквально пару недель назад у нас в "Стриже" случилось ровно такое озарение: наш фаундер имеет большой опыт работы в консалтинге, в том числе в Big Four, и когда в очередной раз кто-то поднял вопрос о том, что хорошо бы сформировать наши ценности, он взорвался филиппикой на тему, что формирование ценностей — это корпоративный буллшит, которого он не потерпит. "Мы не берем на работу мудаков — вот наша основная ценность!". На этом месте все переглянулись и сказали, что ценность отличная и давно надо было её так и сформулировать. "Приходя на работу к нам люди могут быть уверены, что у них не будет мудака-начальника и мудаков-коллег". Мы, конечно, напишем это в описании вакансий менее радикальными словами, но суть такова)
У этого кейса может быть много правильных решений, в том числе зависящих от конкретной команды, существующих в ней практик и взаимоотношений внутри, поэтому дальше — моё мнение, основанное на моём опыте и не претендующее на всесторонность.
Первое, на что бы я обратил внимание — это недостаточный контроль выполнения задач со стороны руководителя отдела и/или прямого руководителя бойца. Выявлять потенциальную проблему такого масштаба нужно на более ранних сроках, пока она не стала критической (дедлайн так близок, что время есть только на передачу таска другому, более опытному бойцу).
Далее, я бы разобрал, почему передача таска ощущается бойцом как грубость. Если ситуация такова, как вы описываете, и все, включая его самого, согласны с тем, что боец а) фатально провалил сдачу в срок б) не в состоянии самостоятельно справиться с проблемой в оставшееся время, то передать задачу другому члену команды — по сути единственное возможное решение, и ничего зазорного в этом нет. Если сам боец не согласен с такой постановкой вопроса — нужно подробно разобрать, откуда берутся эти разногласия, и приложить усилия к донесению до него реального положения дел, попутно проведя reality check на своей стороне: все мы можем ошибаться. В крайнем случае годится аргумент: "я верю в тебя, но я опасаюсь, что ты не справишься по каким-либо ещё, кроме твоей компетентности, причинам, а задача слишком важна и у нас уже не осталось права на ошибку. Мой уровень тревоги сейчас слишком высок, я предпочту более надёжный вариант". Обратите внимание, я перемежаю технические аргументы с высказыванием чувств и эмоций: вера в, опасение, тревога, то есть демонстрирую, что решение одновременно и техническое, и эмоциональное.
Далее подыскать ему менее срочную задачу, требующую для решения нужные абстракции и инструменты, заложить полуторный срок и внимательно контролировать процесс её решения, требуя промежуточных коммитов каждый день или даже несколько раз в день, обсуждать с ним, как он осваивает и правильно ли использует новые для него знания.
Ничего себе, слона-то я и не заметил. Спасибо, что увидели лишний абзац, удалил.
Что токсичные команды существует в реальной жизни — я не сомневаюсь, хотя сам и не видел. Например на одном из мест работы я взял в команду человека из крупного онлайн-ритейлера. Он рассказывал просто какой-то хоррор: плохие условия труда, штрафы за опоздания, штрафы за пропущенные баги, интриги и подсиживания. Мы его два месяца просто выхаживали всей командой, как подранка, пока он понял, что тут его не будут истязать и заставлять работать по 10-11 часов, что тут можно экспериментировать и совершать ошибки в процессе, что тут его ценят, относятся с уважением и т.д. Почему он не ушёл при первой же возможности? Обычная история: маленький ребёнок и кредиты.
Так что есть многое на свете, друг Горацио, что мы своим рациональным мозгом сходу отвергнем как невозможное. И понятно, что автор исходной статьи не противопоставляет черное белому, а предлагает по возможности двигаться по шкале на светлую сторону.
В команду с декларированными ценностями, которая готова эти ценности защищать, невозможно кого-то "запустить": команда их просто не примет, а если попытаться ей такое решение насадить с позиции силы, то просто уйдёт, благо у разработчиков такого уровня обычно 1-2 оффера всегда открыты.
Нормальная человеческая улыбка никогда не была маркером агрессии. Посмотрите на улыбающихся годовалых детей, например. Маркером агрессии может быть американский противоестественный оскал в 32 зуба, но, надо признать, я давно не встречал его в реальной жизни. Смех несёт в себе заряд агрессии, но намного больше смех представляет из себя выражение облегчения. Наши родственники-приматы всегда смеются над хищником с высокого дерева и никогда — с земли :)
Мы вообще сейчас зайдём в тёмный лес тонких психологических материй. Это тоже софтскилл: в комментарии на веб-странице так выстроить фразу, чтобы человек воспринял её не как направленную на себя, а как "вот смотри, мы стоим с тобой рядом, я показываю пальцем на дурацкие, по моему мнению, практики где-то там и предлагаю тебе присоединиться к моему презрению". У упомянутого Джорджа Карлина это неплохо получалось, а попробуйте прослушать любую его миниатюру как направленную лично на себя; то ещё удовольствие.
Примеров того, как коллективы, построенные на взаимоуважении и декларирующие его как ценность выдавливали из себя токсичных представителей — сотни. Мой эталон — отдел разработки Яндекса при Сегаловиче и как изменилась вся компания при Императоре и далее с уходом Колмановской.
Могу привести десятки примеров, когда "накосячивших" разработчиков не только не увольняли, но наоборот — делали из катастроф дидактические кейсы. Возьмите, например, инцидент с дропом базы Gitlab в январе 2017. Виновный продолжает работать и даже официально получил должность Senior data loss engineer :) Потому что если подумать, то увольнять человека, только что получившего колоссальный кусок опыта, который мало кто мало где вообще когда-нибудь получит — это несколько расточительно.
И да, главное в современной компании не качество и не скорость написания кода, главное — это объём знаний, сосредоточенный в компании. Компании, которые быстро пишут код за деньги, сами их сотрудники называют "галерами", по аналогии с трудом римских рабов на флоте. Этому феномену посвящен целый сайт https://ebanoe.it/, рекомендую ознакомиться, прямо живая иллюстрация анекдота про мышей и кактус.
И наконец: в современной медицине вывихи вправляются с обезболиванием. Максима "no pain — no gain", как и любая генерализация, ложна.
Это отсутствие так называемых софтскиллов. Дело не в понимании, а в неумении считывать невербальную обратную связь и нежелании слышать вербальную. Возможно процедура code review через инструменты типа Github/Gitlab, общение через почту и мессенджеры этому способствует, потому что там обратную связь считать или получить почти невозможно.