Спасибо за развернутое дополнение, мне было интересно прочитать и сам ответ и ссылки в нем.
Мы просто работаем в достаточно узком понимании биологии людей и моделей тоже, поэтому не все аналогии могут быть удачны для биофизика :) С точки зрения разметки, не совсем важно то, как именно мы назовем что именно происходит с ответом разметчика (и что стало его первопричиной) - логическая ошибка, фантазия, незнание, галлюцинация, некая "оптимизация времени трудовой деятельность" - как угодно, нам важно лишь то, чем является конечный (часто бинарный) результат.
С людьми мы неизбежно выкидываем часть их ответов, процент разный в разных типах задач, но эта величина практически постоянна на длинных дистанциях. Идеей было лишь сравнить этот феномен с моделями, то есть, неизбежность принятия лишь части ответов.
Вы подсветили интересную штуку, которую мы поизучаем дополнительно: более глубокое понимание происходящих процессов, так скажем, "генерации ответа" позволит нам сделать более серьезные инструменты анализа этих ответов, а может быть и вообще постановки изначально самого задания.
Спасибо! Все так, чем монструознее и мощнее нейронки в наличии, тем больший класс задач будет им отдавать просто потому что так можно, увы, хотя оправдано это далеко не всегда.
В мире нейросетей все очень по разному, и он точно не черно-белый, как и мотивация инженеров сводится не только к "за деньги - да". Я лично знаю людей, которых неплохо повышали за именно качественные исследования, без каких-либо kpi. И знаю обратные ситуации, например, когда сотрудников (или студентов физтеха) скупали оптом, просто потому что "они умные и пусть лучше работают у нас", после чего за ними вообще пропадает какой-то контроль, потому что этот контроль падал на других людей, у которых хватало своих корпоративных забот.
Не соглашусь, потому что мотивация "выполнено-освоено" она, возможно, более присуща менеджменту (и чем выше менеджмент, тем вероятнее там такое мышление, но все тоже далеко не черно-белое), а вот у сильных технарей мотивация работает уже по другому - вопросы просто получения немаленькой зарплаты уже давно решены и вот так это уже не работает, иначе из всех утюгов не трубилось бы о "выгорании".
Потому что все выгорающие зарплату, скорее всего, получали, зарплата по общим меркам была немаленькая, да и задачи решали и бюджет осваивали, однако ж проблема есть. Потому что она гораздо сложнее той конструкции, что вы сейчас описали.
А я их не менял, об этом не писал и на это не претендую. Я делал несколько больших проектов, часть из которых имели специфику, требующих прямого погружения (где-то глубже, где-то проще) во внутрянку других сторонних проектов и их команд.
Как правило, это правда. Но тут тоже часто нельзя давать советов по интернету, потому что все сильно зависит от конкретных условий, да и вопрос немного философский, потому что в ситуации нет времени/денег/людей, вариабельностей итоговых действий не сказать, что очень высока.
Спасибо за интересный термин (и ваши статьи)! Да, чем больше занимаюсь технологиями, тем сильнее понимаю, что мыслительная рамка вширь и вдаль, подумать и вперед и за других людей, это не менее важно, чем конкретное принятие решений исходя из просто технического опыта.
Подход "чем проще, тем лучше" - полностью справедливый. Единственное, у него часто есть сложность в определении до какого уровня "проще" можно опуститься, чтобы потом не найти проблем с архитектурой, кибербезами и не скатиться в откровенный говнокод 😀
Так мир ведь он вот какой простой, видишь две цифры - дели одну на другую и беги скорей делать выводы 😀
Вот у человека -19 карма и 98 комментариев, значит он -0.19 получает за каждый комментарий. То есть, комментарии давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
В больших структурах такое сплошь и рядом, и когда в очередной раз будет пересмотр эффективности работы всей цепочки, то безудержная лояльность даже к неудачным решениям может закончиться не очень хорошо.
Поэтому да, все сложно, и нужно индивидуально понимать насколько договорибельно руководство в целом, и уже в конкретных обстоятельствах принимать какое-то решение.
Мне кажется, такие вопросы надо задавать максимально нейтрально, потому что это может неправильно восприниматься как атака на принятое решение. Но если человек не может защитить свою точку зрения двумя последовательными вопросами "зачем", то это не очень хорошо, конечно.
Конструктивные трения это в целом очень полезно, но только если команда умеет не выходить за рамки рабочих обсуждений, чтобы это не превратилось в ругань.
Добавлю еще, что как только начинаются добавления к функциональности или усложнении системы, ну, например, не пускать определенных людей, то человеки начинают быстрее проигрывать автоматике.
Соглашусь со здравомыслием подхода! Все сильно зависит от нюансов и поставленной задачи. Если вы решаете задачу одной конкретной проходной - возможно, пенсионер-вахтер это выход, потому что люди впринципе сходу могут быстро решать целый класс задач и идеально справляться с кучей нештатных ситуаций. Люди это зачастую жирнющий плюс с точки зрения быстроты решения задачи, потому что обрабатывание внештатки в айти часто занимает астрономически много времени, денег и плюс все эти шишки набиваются только со временем.
Но у людей есть критичный недостаток, это плохая их тиражируемость. Как только проходных становится две, три, четыре, десять, сто - тиражировать человеков становится очень больно и сложно, и эта сложность сильно возрастает в зависимости от сложности решаемой функции.
Еще один недостаток - это обстоятельства, которые у человеков могут случаться чаще и менее прогнозируемо, нежели у бездушных железок. Продавщица может заболеть, быть в плохом настроении, list goes on and on, а у кремниевых список более короткий и более прогнозируемый.
Поэтому да, выбор человек или айти - это тоже выбор здравого смысла.
Спасибо! Именно эту идею мне хотелось донести. Иногда у проекта бывает масса неочевидных нюансов, которые проявляются только со временем или в процессе обдумывания того самого идеального решения [о котором, скорее всего, уже думали и которое скорее всего вот так легко сразу не взлетит].
Переписывать код - нужно. Поставлю лайк, потому главная идея "все зависит от конкретных обстоятельств" - это ровно то, что я и пытался донести написанным текстом.
Ну рефакторинг тоже бывает разным, можно понемногу переписывать все, а можно рубануть с плеча и влезать в ядро надо прям сильно сознательно и джунов туда лучше не пускать. А вот что-то малокритичное дать джуну с последующим надзором - милое дело.
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.
Спасибо за развернутое дополнение, мне было интересно прочитать и сам ответ и ссылки в нем.
Мы просто работаем в достаточно узком понимании биологии людей и моделей тоже, поэтому не все аналогии могут быть удачны для биофизика :) С точки зрения разметки, не совсем важно то, как именно мы назовем что именно происходит с ответом разметчика (и что стало его первопричиной) - логическая ошибка, фантазия, незнание, галлюцинация, некая "оптимизация времени трудовой деятельность" - как угодно, нам важно лишь то, чем является конечный (часто бинарный) результат.
С людьми мы неизбежно выкидываем часть их ответов, процент разный в разных типах задач, но эта величина практически постоянна на длинных дистанциях. Идеей было лишь сравнить этот феномен с моделями, то есть, неизбежность принятия лишь части ответов.
Вы подсветили интересную штуку, которую мы поизучаем дополнительно: более глубокое понимание происходящих процессов, так скажем, "генерации ответа" позволит нам сделать более
серьезные инструменты анализа этих ответов, а может быть и вообще постановки изначально самого задания.
Большое спасибо!
Спасибо! Все так, чем монструознее и мощнее нейронки в наличии, тем больший класс задач будет им отдавать просто потому что так можно, увы, хотя оправдано это далеко не всегда.
В мире нейросетей все очень по разному, и он точно не черно-белый, как и мотивация инженеров сводится не только к "за деньги - да". Я лично знаю людей, которых неплохо повышали за именно качественные исследования, без каких-либо kpi. И знаю обратные ситуации, например, когда сотрудников (или студентов физтеха) скупали оптом, просто потому что "они умные и пусть лучше работают у нас", после чего за ними вообще пропадает какой-то контроль, потому что этот контроль падал на других людей, у которых хватало своих корпоративных забот.
Не соглашусь, потому что мотивация "выполнено-освоено" она, возможно, более присуща менеджменту (и чем выше менеджмент, тем вероятнее там такое мышление, но все тоже далеко не черно-белое), а вот у сильных технарей мотивация работает уже по другому - вопросы просто получения немаленькой зарплаты уже давно решены и вот так это уже не работает, иначе из всех утюгов не трубилось бы о "выгорании".
Потому что все выгорающие зарплату, скорее всего, получали, зарплата по общим меркам была немаленькая, да и задачи решали и бюджет осваивали, однако ж проблема есть. Потому что она гораздо сложнее той конструкции, что вы сейчас описали.
А я их не менял, об этом не писал и на это не претендую. Я делал несколько больших проектов, часть из которых имели специфику, требующих прямого погружения (где-то глубже, где-то проще) во внутрянку других сторонних проектов и их команд.
Как правило, это правда. Но тут тоже часто нельзя давать советов по интернету, потому что все сильно зависит от конкретных условий, да и вопрос немного философский, потому что в ситуации нет времени/денег/людей, вариабельностей итоговых действий не сказать, что очень высока.
Спасибо за интересный термин (и ваши статьи)! Да, чем больше занимаюсь технологиями, тем сильнее понимаю, что мыслительная рамка вширь и вдаль, подумать и вперед и за других людей, это не менее важно, чем конкретное принятие решений исходя из просто технического опыта.
Подход "чем проще, тем лучше" - полностью справедливый. Единственное, у него часто есть сложность в определении до какого уровня "проще" можно опуститься, чтобы потом не найти проблем с архитектурой, кибербезами и не скатиться в откровенный говнокод 😀
Спасибо. Как говорится, "если тикету уже больше года, и за ним никто не пришел, может быть он и не так нужен?" 😀
Так мир ведь он вот какой простой, видишь две цифры - дели одну на другую и беги скорей делать выводы 😀
Вот у человека -19 карма и 98 комментариев, значит он -0.19 получает за каждый комментарий. То есть, комментарии давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
К сожалению да, ситуация не то чтобы прям сильно уникальная 😀
В больших структурах такое сплошь и рядом, и когда в очередной раз будет пересмотр эффективности работы всей цепочки, то безудержная лояльность даже к неудачным решениям может закончиться не очень хорошо.
Поэтому да, все сложно, и нужно индивидуально понимать насколько договорибельно руководство в целом, и уже в конкретных обстоятельствах принимать какое-то решение.
Мне кажется, такие вопросы надо задавать максимально нейтрально, потому что это может неправильно восприниматься как атака на принятое решение. Но если человек не может защитить свою точку зрения двумя последовательными вопросами "зачем", то это не очень хорошо, конечно.
Конструктивные трения это в целом очень полезно, но только если команда умеет не выходить за рамки рабочих обсуждений, чтобы это не превратилось в ругань.
Спасибо! Добавить нечего, все так 👍
Добавлю еще, что как только начинаются добавления к функциональности или усложнении системы, ну, например, не пускать определенных людей, то человеки начинают быстрее проигрывать автоматике.
Соглашусь со здравомыслием подхода! Все сильно зависит от нюансов и поставленной задачи. Если вы решаете задачу одной конкретной проходной - возможно, пенсионер-вахтер это выход, потому что люди впринципе сходу могут быстро решать целый класс задач и идеально справляться с кучей нештатных ситуаций. Люди это зачастую жирнющий плюс с точки зрения быстроты решения задачи, потому что обрабатывание внештатки в айти часто занимает астрономически много времени, денег и плюс все эти шишки набиваются только со временем.
Но у людей есть критичный недостаток, это плохая их тиражируемость. Как только проходных становится две, три, четыре, десять, сто - тиражировать человеков становится очень больно и сложно, и эта сложность сильно возрастает в зависимости от сложности решаемой функции.
Еще один недостаток - это обстоятельства, которые у человеков могут случаться чаще и менее прогнозируемо, нежели у бездушных железок. Продавщица может заболеть, быть в плохом настроении, list goes on and on, а у кремниевых список более короткий и более прогнозируемый.
Поэтому да, выбор человек или айти - это тоже выбор здравого смысла.
Спасибо! Именно эту идею мне хотелось донести. Иногда у проекта бывает масса неочевидных нюансов, которые проявляются только со временем или в процессе обдумывания того самого идеального решения [о котором, скорее всего, уже думали и которое скорее всего вот так легко сразу не взлетит].
Переписывать код - нужно. Поставлю лайк, потому главная идея "все зависит от конкретных обстоятельств" - это ровно то, что я и пытался донести написанным текстом.
Ну рефакторинг тоже бывает разным, можно понемногу переписывать все, а можно рубануть с плеча и влезать в ядро надо прям сильно сознательно и джунов туда лучше не пускать. А вот что-то малокритичное дать джуну с последующим надзором - милое дело.
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.