Пока какой нибудь telegram или watsapp не интегрируют в себя такую штуку (а в телегу вполне могли бы), которая автоматически включалась бы при отсутствии интернета - нужной массовости чтобы обеспечить связность сети хотя бы одном доме - не наберётся. И все это звучит как очень нишевые штуки, которыми никто никогда не воспользуется
Как будто подобные статьи отлично опровергают даже своим существованием целесообразность человекоподобных роботов.
Его тут через симуляции с огромным трудом учат выполнять задачу, в которой минимум неопределенности (барабаны всегда на одних и тех же позициях, одни и те-же, движения все одинаковые). И все равно результат весьма слабый даже в самой симуляции.
В защитники антропоморфных роботов рассказывают, как они сэкономят за счёт того, что один робот будет решать все задачи пользуясь оборудованием для человека.
Да при таком плохом и сложном обучении на статичных задачах - каких бесконечных денег и проблем будет стоить обучение и эксплуатация в динамичном - где каждый нож/вилка/сковорода разных размеров, весов и добротности.
Я много раз слышал про такой эффект, но ни разу не видел такого в жизни (когда попадает неэффективный руководитель и выживает тех, кто может составить ему конкуренцию). Слышал такое только от людей, которые пошли на конфликт с руководством и предвзяты (так что уверенность не 100% в их словах).
Очень хотелось бы пару примеров или историй от людей, которые реально в такую ситуацию попадали
Страшно, очень страшно. Даже в ручную то страшно обновлять зависимости больше чем по одной, а тут автоматика наобновляла в случайном порядке их несколько раз подряд - потом ищи - какой конкретно апдейт все сломал.
Но при 100% покрытии тестами инструмент интересный
Вся продукция Razer такая. Deathadder - 2 штуки - даблклик клавиш через год, Naga - тоже и сдох энкодер ролика, Razerphone 2 - накрылся USB-C порт, и дизайн ужасно непродуманный. Так что их продукцию лучше не покупать, если планируешь больше 6 месяцев использовать.
Я пока не понял как вы подходом с таблицами данных предлагаете решить первоначальную проблему ооп с возастающей иерархичностью данных. Вот у вас один персонаж бъет другого мечём, при одетых перчатках с модификатором огня и должен соответсвенно учесть защиту аппонента и защиту от огня. Вам все равно придётся пройти по всем предметам персонажа и аппонента, каждый предмет обладает группой свойств - а значит иерархическая запись - таблица таблиц. Дальше вы выберете данные с учетом типа атаки и посчитаете результат по некторой формуле, внеся его в статы аппонента.
Кажется как будто тоже самое не сложнее написать с ооп - просто реализовав у атакующего метод - аыдающий сумаризированные данные атаки, а у защищающегося - принимающий их, считающий урон по внутренней формуле и применяющий.
Проблемы начинаются при реактивных штуках (если противник парировал атаку, даёт +100% к слеюущей) но они и в случае хранения данных в общей куче - точно такие же.
В своё время при разработке игры ооп очень круто помог масштабировать проект благодаря композиции. Игровые объекты были "актерами", и игровая сцена, содержащая в себе набор взаимодействующих актеров - тоже была актером (по интерфейсу). За счёт этого их можно было комбинировать как угодно, вкладывая одни готовые сценарии в другии в любых масштабах (как матрёшка, только круче).
Т.е. если актер это один юнит - который умеет только анимироватся и двигаться, то взвод имеющий некоторую логику построения - снаружи тоже актер, и армия - обладающая уже полноценным управлением и целями - тоже актер, и конечная сцена - может содержать несколько армий, несколько отдельных взводов, какое-то количество просто юнитов - и все это вместе с точки зрения движка - тоже 1 актер, которому просто передаётся управление.
Вы так говорите - как будто принудительно повышаете сотрудников без права отказаться. Тогда конечно - они расстроятся и можно ценного специалиста потерять. На деле - это предложение а не принудиловка.
Тут как раз - у тебя 5к сейчас или 4к потом + 4к потенциальных бонусов - отсеет людей - которым эта должность не нужна, а они просто больше денег хотят.
Не хочешь, оставайся на своих 5к и расти дальше в техническом русле (я к слову, когда ко мне приходили, выбрал именно этот вариант)
Точно так-же у нас при хантинге людей в стартап (новое юр лицо от той-же компании, с уникальным продуктом) - предлагали уйти с 5к на 3, но с доплатой акциями, опционами и небольшим процентом от выручки (и перспективой быть "у истоков" - если стартап выстрелит). Ушли именно люди, которые горели идеей поработать в стартапе (он кстати не выстрелил в итоге)
Обычные разработчики редко когда «принимают решения»
Обычные разработчики принимают миллион маленьких решений по реализации. Если разработчик не принимает решения - его скорее всего успешно можно заменить скриптом. И тут большой вопрос - нужен ли такой в компании.
Будет ответ «извините NDA». Если попадете на «волка» — будет просто красочный заученный рассказ.
Заученный рассказ или привирания - сыпятся после следующих вопросов (и это как способ выявить привирателей). А "извините за nda" - решается предложением рассказать в общем виде без деталей проекта. Если разработчик ничего не хочет рассказывать всё время упирая на nda - это ему сразу минус в вероятности пройти собеседование (у меня) т.к. нечего рассказывать только тем, кто ничего не делал, а nda не более чем отговорка. Даже у людей которые чисто формы клепали - за год найдется хотя бы одна задача, которую можно описать.
Либо снова скажут про NDA либо подберут технологии, которыми лучше всего владеют или на которые натасканы.
Если человек подберет технологии которыми владеет - это и нужно, я вообще не против. Спрашивать надо именно по технологиям которыми человек владеет (или думает что владеет) - если он "владеет" корутинами, но при этом не может рассказать как они устроены - отличный пример, что и другие технологии он будет осваивать поверхностно.
Технологии все время меняются, но человек который хорошо освоил rx - справится и с flow за неделю, а человек у которого серьёзные пробелы в том, что он преподносит как свои доситжения, будет иметь такие-же в новых для себя технологиях.
Вопрос про предидущий опыт - он же нужен не ради выяснения где работал кандидат, а как отправная точка для обсуждения решений которые он принимал и в этом плане он до сих пор отлично работает.
Легко соврать что ты работал в яндексе - но далее следует вопрос - какие задачи там были, какие конкретно решения были сделаны, почему такие и что бы хотелось сделать иначе.
Если человек говорит что работал 4 года, но не может вспомнить ни одной задачи или у него ответы типо "клепал формы" - это тоже показатель.
Плюс можно спросить - какие технологии там использовались и спрашивать уже конкретно по ним - если человек говорит - там (где он 4 года работал) использовал RxJava, а потом сливает все вопросы по ней - это тоже показатель, что либо он врёт, либо чисто копипастил чужие решения даже не разобрав, что тоже не очень хорошо.
Ещё раз - вы откуда свою статистику берёте что "ничего подобного не видим"? Скиньте ссылку на эффективность попадания дронов до и после. А то у вас классические аргументы "очевидно", "не видим". Без цифр - выеденного гроша такие рассуждения не стоят.
Видосики с летящими дронами мне кстати товарищь скидывал и во время отключения интернета - ну потому что из дома через окно когда снимаешь - не нужен для этого мобильный интернет, да и камера не отключается от этого - так что вот как раз этот довод "притянут за уши".
А подскажите - зачем руководителю аналитический службы демонстрировать подчиненным наличие компетенций? Я просто реально не знаю - но руководитель - это всегда про управление людьми, и интересно почему это может зависеть от службы.
оклад ниже чем топового линейного сотрудника, но есть значительное количество бонусов
Вы до значительного количества бонусов не дочитали видимо.
Если хочешь сидеть на попе ровно и получать много - выгоднее быть простым Топовым сотрудником (фактически курицей, которая несёт золотые яйца).
Если хочешь очень много - становить руководителем, но будь готов нести отвественность за свои действия - если по твоей вине курицы золотых яиц не снесли, или разлетелись - получишь как обычный сотрудник - если количество яиц удвоилось, и все довольны - получишь например 10% от прибыли - что может быть и х5 от оклада.
А если человек не готов рисковать и нести ответсвенность, а хочет сидеть на попе ровно - грош цена ему как руководителю.
Тут ещё вопрос из какой должности был переход. В тех случаях про которые я писал - человек уходил в управленца не из максимальной технической должности - в итоге да, понижения оклада не случалось, но оклад был меньше максимального оклада линейного сотрудника высшего уровня, как я и писал)
Если руководитель не готов нести овтественность за свои решения своими деньгами (мотивирующей частью) - то большей вопрос - а почему?
Он не уверен в себе? Он не верит в отдел? Он не знает как достигать результатов? Он боится рисковать?
А нужен ли в компании руководитель с такими качествами, никак для хорошего руководителя не подходящими?
Именно потому, что руководить не легко и очень отвественно - существует разделение на мотивирующую и окладную часть в хороших компаниях. Чтобы отсчечь "руководителей" которые пришли на окладе просиживать штаны теша свое чсв и каждый месяц сетуя на обстоятельства и взять Руководителей - которые пришли тащить отдел, делать вещи и побеждать.
Там планы это не только и не столько про фичи в разработке - а рост отдела, рост продаж, прирост производительности на сотрудника/доллар или по отделу, устранение известных проблем если есть - например текучки кадров, или недовольства клинетов.
Т.е. планы больше про развитие.
Ну и пример - в плане увеличить производительность команды на 5% - хорошо - 5%, превосходно - 15%. Или план - увеличить точность попадания в оценки. Плохо - точность не выросла, хорошо - отклонение от оценки упало со средних 15% до 11% - превосходно - с 15% до 3%.
Вообще подбор команды и распределение задач - то чем можно очень сильно влиять на скорость и цену разработки. И собирать команду "супер звёзд" - как делают часто в бигтехе - очень нерациональный подход. У грамотного руководителя, как у хорошего спортивного менеджера - вместо 15 синьоров, может с такой же эффективностью и качеством работать 3 синьора, 8 мидлов и 4 джуна (условно) - за половину бюджета.
2 компании, у одной был продукт, вторая - галера аутсорс/аутстафф.
Управляющий за тем и нужен, чтобы обигрывать рынок и внешние риски. Если профизошел некий форс мажор - решения по выплатам принимаются группой владельцев компании, которые имели шкурный интерес поощрить хорошего управленца чтобы не сбежал, даже если планы не выполнены но без его вины (только про вторую компанию, первая которая продуктовая ООО - и там хз как это решали, может на собрании акционеров)
Все верно - на повышение шли люди, которые побыв в сфере поняли, что управленческая часть им нравится больше.
Не знаю как в c#, но в java в finaly можно получить исходное искоючение и что-то сделать (не перехватить но обработать).
Если у вас не так - то я не понимаю как try finaly решает проблему "нужно вывести ошибку в том ui компоненте, откуда пользователь кнопку нажал, а catch у нас где угодно но не там"
Я же написал - оклад ниже, но есть серъезный набор премий за выполнение плана. Т.е. если нигде не накосячил - выйдет примерно то-же на то-же, если результаты хорошие показал - то больше на 20 - 30%, если превосходные - может и кратно больше быть. Часть премиальных выдается долей в компании - акциями пример - чтобы руководитель имел шкурный интерес тащить компанию вперёд, часть выдаётся отложенно на 6 месяцев (теряешь при уходе) - чтобы не было мотивации сжечь все ресурсы сейчас, и сбежать с премиальными.
При этом я заметил, что по ходу работы - сами по себе находились сотрудники, которые больше любили управленческие задачи, и вот следующие 2 раза именно такие уходили в руководители, а технари (а т.ч. я) отказывались.
Пока какой нибудь telegram или watsapp не интегрируют в себя такую штуку (а в телегу вполне могли бы), которая автоматически включалась бы при отсутствии интернета - нужной массовости чтобы обеспечить связность сети хотя бы одном доме - не наберётся. И все это звучит как очень нишевые штуки, которыми никто никогда не воспользуется
Как будто подобные статьи отлично опровергают даже своим существованием целесообразность человекоподобных роботов.
Его тут через симуляции с огромным трудом учат выполнять задачу, в которой минимум неопределенности (барабаны всегда на одних и тех же позициях, одни и те-же, движения все одинаковые). И все равно результат весьма слабый даже в самой симуляции.
В защитники антропоморфных роботов рассказывают, как они сэкономят за счёт того, что один робот будет решать все задачи пользуясь оборудованием для человека.
Да при таком плохом и сложном обучении на статичных задачах - каких бесконечных денег и проблем будет стоить обучение и эксплуатация в динамичном - где каждый нож/вилка/сковорода разных размеров, весов и добротности.
Я много раз слышал про такой эффект, но ни разу не видел такого в жизни (когда попадает неэффективный руководитель и выживает тех, кто может составить ему конкуренцию). Слышал такое только от людей, которые пошли на конфликт с руководством и предвзяты (так что уверенность не 100% в их словах).
Очень хотелось бы пару примеров или историй от людей, которые реально в такую ситуацию попадали
Страшно, очень страшно. Даже в ручную то страшно обновлять зависимости больше чем по одной, а тут автоматика наобновляла в случайном порядке их несколько раз подряд - потом ищи - какой конкретно апдейт все сломал.
Но при 100% покрытии тестами инструмент интересный
Вся продукция Razer такая. Deathadder - 2 штуки - даблклик клавиш через год, Naga - тоже и сдох энкодер ролика, Razerphone 2 - накрылся USB-C порт, и дизайн ужасно непродуманный. Так что их продукцию лучше не покупать, если планируешь больше 6 месяцев использовать.
Я пока не понял как вы подходом с таблицами данных предлагаете решить первоначальную проблему ооп с возастающей иерархичностью данных. Вот у вас один персонаж бъет другого мечём, при одетых перчатках с модификатором огня и должен соответсвенно учесть защиту аппонента и защиту от огня. Вам все равно придётся пройти по всем предметам персонажа и аппонента, каждый предмет обладает группой свойств - а значит иерархическая запись - таблица таблиц. Дальше вы выберете данные с учетом типа атаки и посчитаете результат по некторой формуле, внеся его в статы аппонента.
Кажется как будто тоже самое не сложнее написать с ооп - просто реализовав у атакующего метод - аыдающий сумаризированные данные атаки, а у защищающегося - принимающий их, считающий урон по внутренней формуле и применяющий.
Проблемы начинаются при реактивных штуках (если противник парировал атаку, даёт +100% к слеюущей) но они и в случае хранения данных в общей куче - точно такие же.
В своё время при разработке игры ооп очень круто помог масштабировать проект благодаря композиции. Игровые объекты были "актерами", и игровая сцена, содержащая в себе набор взаимодействующих актеров - тоже была актером (по интерфейсу). За счёт этого их можно было комбинировать как угодно, вкладывая одни готовые сценарии в другии в любых масштабах (как матрёшка, только круче).
Т.е. если актер это один юнит - который умеет только анимироватся и двигаться, то взвод имеющий некоторую логику построения - снаружи тоже актер, и армия - обладающая уже полноценным управлением и целями - тоже актер, и конечная сцена - может содержать несколько армий, несколько отдельных взводов, какое-то количество просто юнитов - и все это вместе с точки зрения движка - тоже 1 актер, которому просто передаётся управление.
Вы так говорите - как будто принудительно повышаете сотрудников без права отказаться. Тогда конечно - они расстроятся и можно ценного специалиста потерять. На деле - это предложение а не принудиловка.
Тут как раз - у тебя 5к сейчас или 4к потом + 4к потенциальных бонусов - отсеет людей - которым эта должность не нужна, а они просто больше денег хотят.
Не хочешь, оставайся на своих 5к и расти дальше в техническом русле (я к слову, когда ко мне приходили, выбрал именно этот вариант)
Точно так-же у нас при хантинге людей в стартап (новое юр лицо от той-же компании, с уникальным продуктом) - предлагали уйти с 5к на 3, но с доплатой акциями, опционами и небольшим процентом от выручки (и перспективой быть "у истоков" - если стартап выстрелит). Ушли именно люди, которые горели идеей поработать в стартапе (он кстати не выстрелил в итоге)
Обычные разработчики принимают миллион маленьких решений по реализации. Если разработчик не принимает решения - его скорее всего успешно можно заменить скриптом. И тут большой вопрос - нужен ли такой в компании.
Заученный рассказ или привирания - сыпятся после следующих вопросов (и это как способ выявить привирателей). А "извините за nda" - решается предложением рассказать в общем виде без деталей проекта. Если разработчик ничего не хочет рассказывать всё время упирая на nda - это ему сразу минус в вероятности пройти собеседование (у меня) т.к. нечего рассказывать только тем, кто ничего не делал, а nda не более чем отговорка. Даже у людей которые чисто формы клепали - за год найдется хотя бы одна задача, которую можно описать.
Если человек подберет технологии которыми владеет - это и нужно, я вообще не против. Спрашивать надо именно по технологиям которыми человек владеет (или думает что владеет) - если он "владеет" корутинами, но при этом не может рассказать как они устроены - отличный пример, что и другие технологии он будет осваивать поверхностно.
Технологии все время меняются, но человек который хорошо освоил rx - справится и с flow за неделю, а человек у которого серьёзные пробелы в том, что он преподносит как свои доситжения, будет иметь такие-же в новых для себя технологиях.
Вопрос про предидущий опыт - он же нужен не ради выяснения где работал кандидат, а как отправная точка для обсуждения решений которые он принимал и в этом плане он до сих пор отлично работает.
Легко соврать что ты работал в яндексе - но далее следует вопрос - какие задачи там были, какие конкретно решения были сделаны, почему такие и что бы хотелось сделать иначе.
Если человек говорит что работал 4 года, но не может вспомнить ни одной задачи или у него ответы типо "клепал формы" - это тоже показатель.
Плюс можно спросить - какие технологии там использовались и спрашивать уже конкретно по ним - если человек говорит - там (где он 4 года работал) использовал RxJava, а потом сливает все вопросы по ней - это тоже показатель, что либо он врёт, либо чисто копипастил чужие решения даже не разобрав, что тоже не очень хорошо.
Без обратной связи их можно например корректируя gps приземлить где нибудь в поле за городом. Или подвести под пво и сбить куда аккуратнее.
Или вы серьёзно думаете, что военные не люди да ещё и одновременно идиоты и злодеи?
Ещё раз - вы откуда свою статистику берёте что "ничего подобного не видим"? Скиньте ссылку на эффективность попадания дронов до и после. А то у вас классические аргументы "очевидно", "не видим". Без цифр - выеденного гроша такие рассуждения не стоят.
Видосики с летящими дронами мне кстати товарищь скидывал и во время отключения интернета - ну потому что из дома через окно когда снимаешь - не нужен для этого мобильный интернет, да и камера не отключается от этого - так что вот как раз этот довод "притянут за уши".
А подскажите - зачем руководителю аналитический службы демонстрировать подчиненным наличие компетенций? Я просто реально не знаю - но руководитель - это всегда про управление людьми, и интересно почему это может зависеть от службы.
Вы до значительного количества бонусов не дочитали видимо.
Если хочешь сидеть на попе ровно и получать много - выгоднее быть простым Топовым сотрудником (фактически курицей, которая несёт золотые яйца).
Если хочешь очень много - становить руководителем, но будь готов нести отвественность за свои действия - если по твоей вине курицы золотых яиц не снесли, или разлетелись - получишь как обычный сотрудник - если количество яиц удвоилось, и все довольны - получишь например 10% от прибыли - что может быть и х5 от оклада.
А если человек не готов рисковать и нести ответсвенность, а хочет сидеть на попе ровно - грош цена ему как руководителю.
И не путайте с тим и тех лидами.
Тут ещё вопрос из какой должности был переход. В тех случаях про которые я писал - человек уходил в управленца не из максимальной технической должности - в итоге да, понижения оклада не случалось, но оклад был меньше максимального оклада линейного сотрудника высшего уровня, как я и писал)
Если руководитель не готов нести овтественность за свои решения своими деньгами (мотивирующей частью) - то большей вопрос - а почему?
Он не уверен в себе? Он не верит в отдел? Он не знает как достигать результатов? Он боится рисковать?
А нужен ли в компании руководитель с такими качествами, никак для хорошего руководителя не подходящими?
Именно потому, что руководить не легко и очень отвественно - существует разделение на мотивирующую и окладную часть в хороших компаниях. Чтобы отсчечь "руководителей" которые пришли на окладе просиживать штаны теша свое чсв и каждый месяц сетуя на обстоятельства и взять Руководителей - которые пришли тащить отдел, делать вещи и побеждать.
Там планы это не только и не столько про фичи в разработке - а рост отдела, рост продаж, прирост производительности на сотрудника/доллар или по отделу, устранение известных проблем если есть - например текучки кадров, или недовольства клинетов.
Т.е. планы больше про развитие.
Ну и пример - в плане увеличить производительность команды на 5% - хорошо - 5%, превосходно - 15%. Или план - увеличить точность попадания в оценки. Плохо - точность не выросла, хорошо - отклонение от оценки упало со средних 15% до 11% - превосходно - с 15% до 3%.
Вообще подбор команды и распределение задач - то чем можно очень сильно влиять на скорость и цену разработки. И собирать команду "супер звёзд" - как делают часто в бигтехе - очень нерациональный подход. У грамотного руководителя, как у хорошего спортивного менеджера - вместо 15 синьоров, может с такой же эффективностью и качеством работать 3 синьора, 8 мидлов и 4 джуна (условно) - за половину бюджета.
Это рф.
2 компании, у одной был продукт, вторая - галера аутсорс/аутстафф.
Управляющий за тем и нужен, чтобы обигрывать рынок и внешние риски. Если профизошел некий форс мажор - решения по выплатам принимаются группой владельцев компании, которые имели шкурный интерес поощрить хорошего управленца чтобы не сбежал, даже если планы не выполнены но без его вины (только про вторую компанию, первая которая продуктовая ООО - и там хз как это решали, может на собрании акционеров)
Все верно - на повышение шли люди, которые побыв в сфере поняли, что управленческая часть им нравится больше.
Не знаю как в c#, но в java в finaly можно получить исходное искоючение и что-то сделать (не перехватить но обработать).
Если у вас не так - то я не понимаю как try finaly решает проблему "нужно вывести ошибку в том ui компоненте, откуда пользователь кнопку нажал, а catch у нас где угодно но не там"
Да, и ответсвенность должна иметь денежный вес - по этому окдад меньше, но большая мотивирующая составляющая.
Просрал все зоны ответсвенности - остался с окладом ниже разработческой.
Я же написал - оклад ниже, но есть серъезный набор премий за выполнение плана. Т.е. если нигде не накосячил - выйдет примерно то-же на то-же, если результаты хорошие показал - то больше на 20 - 30%, если превосходные - может и кратно больше быть. Часть премиальных выдается долей в компании - акциями пример - чтобы руководитель имел шкурный интерес тащить компанию вперёд, часть выдаётся отложенно на 6 месяцев (теряешь при уходе) - чтобы не было мотивации сжечь все ресурсы сейчас, и сбежать с премиальными.
При этом я заметил, что по ходу работы - сами по себе находились сотрудники, которые больше любили управленческие задачи, и вот следующие 2 раза именно такие уходили в руководители, а технари (а т.ч. я) отказывались.