даю справку: мало текста и много воды, перед самой главной фразой в статье - "предлагаю уникальные и востребованные услуги". предположу, что подобное у почтенной публике не в почёте.
выскажу крамольную мысль, но... работаю в большой конторе (4000+ работников) и мое субъективное наблюдение о том, что вижу вокруг в конкретном частном случае: чем больше нанимают середняков, тем больше энтропии плодят эти середняки и нужны новые середняки. не обобщаю на отрасль, возможно где-то иначе. по крайней мере на слайдах об успешном успехе многие рассказывают какие классные у всех команды. возможно неудачник это я)))
все это здорово, но как быть с сотрудниками, которые не укладываются в среднюю температуру по больнице, которую измерили опросами или иным способом? как их удовлетворять? стоит ли? интересно узнать мнение автора. иными словами - как решать противостояние "удовлетворенность сотрудникОВ vs удовлетворенность сотрудникА".
во времена перестройки один юморист (забыл фамилию) в своем монологе упоминал политического деятеля, который служил тем, кто его брал. и юморист предлагал нагрудить деятеля медалью "за неоднократную преданность".
в случае трудовых взаимоотношений (взаимо, подчеркиваю) все эти басни про одностороннюю лояльность (которую надо взращивать и изучать) выглядят как минимум нелогично. а в ответ работнику что? великая честь и футболка с логотипом компании?
буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
даю справку: мало текста и много воды, перед самой главной фразой в статье - "предлагаю уникальные и востребованные услуги". предположу, что подобное у почтенной публике не в почёте.
выскажу крамольную мысль, но... работаю в большой конторе (4000+ работников) и мое субъективное наблюдение о том, что вижу вокруг в конкретном частном случае: чем больше нанимают середняков, тем больше энтропии плодят эти середняки и нужны новые середняки. не обобщаю на отрасль, возможно где-то иначе. по крайней мере на слайдах об успешном успехе многие рассказывают какие классные у всех команды. возможно неудачник это я)))
все это здорово, но как быть с сотрудниками, которые не укладываются в среднюю температуру по больнице, которую измерили опросами или иным способом? как их удовлетворять? стоит ли? интересно узнать мнение автора. иными словами - как решать противостояние "удовлетворенность сотрудникОВ vs удовлетворенность сотрудникА".
подобное притягивает подобное. в этом и суть заключения трудовых взаимо(!)отношений. на рынке есть разные компании и кандидаты.
во времена перестройки один юморист (забыл фамилию) в своем монологе упоминал политического деятеля, который служил тем, кто его брал. и юморист предлагал нагрудить деятеля медалью "за неоднократную преданность".
в случае трудовых взаимоотношений (взаимо, подчеркиваю) все эти басни про одностороннюю лояльность (которую надо взращивать и изучать) выглядят как минимум нелогично. а в ответ работнику что? великая честь и футболка с логотипом компании?
не нашел ничего про принятие решения об увеличении/уменьшении грейда и/или зарплаты. только словесные пляски - развитие, планы, отзывы...
неужели я один такой меркантильный и наивный? или невнимательный?
буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
база для командной работы (и не только в IT) - это умение формулировать "мои мысли - мои скакуны" в устную и письменную речь.
мой любимый паттерн компаний - мы не будем дискриминировать по фото, но будем дискриминировать по факту наличия или отсутствия фото (#этодругое)
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
хорошие вопросы, я как тех.интервьюер отвечаю на подобные вопросы и встречный интерес проявляю - как работал кандидат.