А какие задачи должен, по-вашему, решать человек в отключенном от электричества доме?
На мой взгляд, тут одно из двух.
1) Либо электричество отключилось не надолго (час, день), и тогда вся задача состоит в том, чтобы с комфортом дождаться включения электричества.
2) Либо электричества не будет в ближайшие месяцы, потому что случилось ...(а что собственно случилось?). И вот тогда вам обязательно пригодится знание, в каком году родился Лев Толстой.
Тут проблема в границе применимости аналогии между строительством и программированием.
В строительстве стандарты описаны гораздо четче, и меняются гораздо реже. Поэтому следовать таким стандартам - это хорошо.
В программировании, наряду со стандартами, есть и просто хайп. Который двигают в массы под лозунгом "теперь все так делают, а кто не успел, тот ретроград". За таким хайпом следовать нет смысла.
Ну кстати в защиту бизнеса - бизнес едва ли потребует "сделай мне все на микросервисах, для отдела из 10 человек". Бизнес обычно скажет "делайте как знаете, лишь бы работало"
1) Да, есть такие проекты, где 2/3 IT отдела можно уволить без потери качества продукта
2) Но тогда IT менеджменту не кем будет руководить. Останется 1/3, которые и так понимают, что нужно делать.
3) И даже если 2/3 "экспериментаторов" уволить, а 1/3 "практиков" оставить - "практики" от этого больше денег не получат. Поскольку зарплаты по грейду.
Ну, пока все что языковые модели реально умеют, это "пересказать своим языком". Если запрос по общим темам, то пересказ википедии, если по кодированию, то пересказ StackOverflow.
Плюс, они очень терпеливы. Поэтому готовы решать задачи про "бокра здруга". Это специальный тип школьных задач, где условие составлено максимально сложно. Подавляющее число людей, которые уже закончили школу, если у них спросят про "бокра здруга", в ответ просто пошлют.
P.S. Языковые модели - очередной повод задуматься об адекватности школьного образования. Так ли нужно 10 лет натаскивать детей на запоминание фактов и решение "задач с подковыркой", если с этим отлично справляется модель?
Очень похоже. Аналогично БИ, появляются ИТ "школы", замороченные определенной архитектурой ("школа микросервисов") или даже определенным сценарием взаимодействия сотрудников ("школа аджайл"). У этих школ есть свое "писание", в виде известных книг или "манифестов". Есть уверенность во всемогуществе принципов школы, и в том, что вне школы все криворукие дураки.
А если что-то пошло не так - "школа" не может быть виновата. Просто конкретный адепт недостаточно хорошо упражнялся, и еще не постиг сути школы. Надо больше ката делать.
К сожалению, человеку на эмоциональном уровне в 99% случаев не нужны 3 из 4 итоговых пунктов. А если человек на рациональном уровне про что-то знает "да, это правильно", но эмоционально это его не волнует - не стоит ожидать и активных действий по этому поводу.
Если человек сейчас здоров, то ни продолжительность жизни (1), ни продолжительность здоровой жизни (2) его сильно не волнует.
Вот социализация (3) - это да, это важно. Но вы же сами отметили, что для социализации человеку достаточно своего "племени". Поэтому задачи социализации отлично выполняются и в мире, расколотом на тысячи племен и языков. При этом лучше всего с социализацией у тех народов, которые живут бедно, но не работают с 9 до 18. "Раньше у нас было время, теперь у нас есть дела". А у масаи или кочевых монголов по прежнему времени полно, и свободное время тратится преимущественно на общение.
А современный горожанин, с работой с 9 до 18, чтобы найти свое "племя" заводит какое-нибудь хобби. Туризм, спорт.
Также и связность (4) не слишком нужна. Кто хочет и может социализироваться - уже социализировался вместе со своими ближайшими соседями.
В двух словах - удачная карьера для разработчика, это стать менеджером.
Только тогда непонятно, зачем с разработки начинать, это слишком окольный путь. В IT полно менеджеров без опыта разработки, и это им врод как не мешает
Модель может предложить использовать решение, которое кто-то когда-то использовал для похожей задачи. В некоторых случаях этого может оказаться достаточно, что и обеспечивает популярность так называемого ИИ.
Мозгу не надо "делать больше вещей". Мозг человека был сформирован в эпоху охоты и собирательства. Для мозга комфортно делать то, смысл чего человеку ясен.
Сегодня человек успевает "делать больше вещей" вместе с ИИ копилотом, не вникая в суть. А завтра - идет на прием к ИИ психологу, с вопросом "как мне жить эту жизнь, чтобы не было так противно".
По пункту 3. Люди занимались групповой охотой почти на всем протяжении своего существования как вида. Поэтому можно считать эволюционным приспособлением готовность к рискованным действиям в составе группы. Причем эта способность характерна преимущественно для мужчин. Идея равенства М и Ж возникла относительно недавно, а вот половые различия у Хомо Сапиенс - объективный факт.
По пункту 5. Полное подчинение действий человека абстрактной идее - пока все же выглядит как редкий пограничный случай. И отнюдь не всегда результаты такого подчинения нам могут понравиться. Террорист самоубийца тоже действует ради абстрактной идеи (сверхидеи).
Сейчас уже и на то, как рассказывать о прошлом опыте, есть свой шаблон. Побольше "якать", употреблять обороты "я сделал, я добился". Такому "речекряку" научиться каждый может.
Все верно, плюс можно добавить: "не ведитесь на премии". Премию могут либо дать, либо не дать, в том числе и по независящим от вас обстоятельствам.
Если цифра указанного в договоре оклада является приемлемой - с остальными деталями можно разобраться по ходу. Разумеется, соблюдая правило "не работать больше 8 часов".
По большому счету, если в переработки не впрягаться, все остальное не так уж страшно.
Работал я как-то в конторе, где разработчики больше половины рабочего времени были на созвонах. Сначала бесило, а потом я подумал примерно так: Ну ок, если контора настолько богата, что готова мне платить не за разработку, а за говорение слов - почему нет?
Разве что профессиональные навыки на такой работе стагнируют. Поэтому в долгосрочной перспективе все таки лучше в таких местах не засиживаться.
Такие разработчики если и встречаются, то неудобны для менеджмента. Если человек и вправду может собой целый небольшой отдел заменить - это только на первый взгляд выглядит круто. А со стороны менеджера - гораздо престижнее руководить целым отделом из фреймворкщиков и CI/CD, чем руководить одним человеком (который и в руководстве не нуждается).
Этому в школе не учат....
А какие задачи должен, по-вашему, решать человек в отключенном от электричества доме?
На мой взгляд, тут одно из двух.
1) Либо электричество отключилось не надолго (час, день), и тогда вся задача состоит в том, чтобы с комфортом дождаться включения электричества.
2) Либо электричества не будет в ближайшие месяцы, потому что случилось ...(а что собственно случилось?). И вот тогда вам обязательно пригодится знание, в каком году родился Лев Толстой.
Тут проблема в границе применимости аналогии между строительством и программированием.
В строительстве стандарты описаны гораздо четче, и меняются гораздо реже. Поэтому следовать таким стандартам - это хорошо.
В программировании, наряду со стандартами, есть и просто хайп. Который двигают в массы под лозунгом "теперь все так делают, а кто не успел, тот ретроград". За таким хайпом следовать нет смысла.
Прикольно. Одной БД и пары программистов хватило бы за глаза. Пару программистов - чтобы было кому подменить, когда другой в отпуске.
Ну кстати в защиту бизнеса - бизнес едва ли потребует "сделай мне все на микросервисах, для отдела из 10 человек". Бизнес обычно скажет "делайте как знаете, лишь бы работало"
1) Да, есть такие проекты, где 2/3 IT отдела можно уволить без потери качества продукта
2) Но тогда IT менеджменту не кем будет руководить. Останется 1/3, которые и так понимают, что нужно делать.
3) И даже если 2/3 "экспериментаторов" уволить, а 1/3 "практиков" оставить - "практики" от этого больше денег не получат. Поскольку зарплаты по грейду.
Ну, пока все что языковые модели реально умеют, это "пересказать своим языком". Если запрос по общим темам, то пересказ википедии, если по кодированию, то пересказ StackOverflow.
Плюс, они очень терпеливы. Поэтому готовы решать задачи про "бокра здруга". Это специальный тип школьных задач, где условие составлено максимально сложно. Подавляющее число людей, которые уже закончили школу, если у них спросят про "бокра здруга", в ответ просто пошлют.
P.S. Языковые модели - очередной повод задуматься об адекватности школьного образования. Так ли нужно 10 лет натаскивать детей на запоминание фактов и решение "задач с подковыркой", если с этим отлично справляется модель?
Очень похоже. Аналогично БИ, появляются ИТ "школы", замороченные определенной архитектурой ("школа микросервисов") или даже определенным сценарием взаимодействия сотрудников ("школа аджайл"). У этих школ есть свое "писание", в виде известных книг или "манифестов". Есть уверенность во всемогуществе принципов школы, и в том, что вне школы все криворукие дураки.
А если что-то пошло не так - "школа" не может быть виновата. Просто конкретный адепт недостаточно хорошо упражнялся, и еще не постиг сути школы. Надо больше ката делать.
К сожалению, человеку на эмоциональном уровне в 99% случаев не нужны 3 из 4 итоговых пунктов. А если человек на рациональном уровне про что-то знает "да, это правильно", но эмоционально это его не волнует - не стоит ожидать и активных действий по этому поводу.
Если человек сейчас здоров, то ни продолжительность жизни (1), ни продолжительность здоровой жизни (2) его сильно не волнует.
Вот социализация (3) - это да, это важно. Но вы же сами отметили, что для социализации человеку достаточно своего "племени". Поэтому задачи социализации отлично выполняются и в мире, расколотом на тысячи племен и языков. При этом лучше всего с социализацией у тех народов, которые живут бедно, но не работают с 9 до 18. "Раньше у нас было время, теперь у нас есть дела". А у масаи или кочевых монголов по прежнему времени полно, и свободное время тратится преимущественно на общение.
А современный горожанин, с работой с 9 до 18, чтобы найти свое "племя" заводит какое-нибудь хобби. Туризм, спорт.
Также и связность (4) не слишком нужна. Кто хочет и может социализироваться - уже социализировался вместе со своими ближайшими соседями.
В двух словах - удачная карьера для разработчика, это стать менеджером.
Только тогда непонятно, зачем с разработки начинать, это слишком окольный путь. В IT полно менеджеров без опыта разработки, и это им врод как не мешает
Чувак, завязывай с наркотиками
Модель может предложить использовать решение, которое кто-то когда-то использовал для похожей задачи. В некоторых случаях этого может оказаться достаточно, что и обеспечивает популярность так называемого ИИ.
Мозгу не надо "делать больше вещей". Мозг человека был сформирован в эпоху охоты и собирательства. Для мозга комфортно делать то, смысл чего человеку ясен.
Сегодня человек успевает "делать больше вещей" вместе с ИИ копилотом, не вникая в суть. А завтра - идет на прием к ИИ психологу, с вопросом "как мне жить эту жизнь, чтобы не было так противно".
По пункту 3. Люди занимались групповой охотой почти на всем протяжении своего существования как вида. Поэтому можно считать эволюционным приспособлением готовность к рискованным действиям в составе группы. Причем эта способность характерна преимущественно для мужчин. Идея равенства М и Ж возникла относительно недавно, а вот половые различия у Хомо Сапиенс - объективный факт.
По пункту 5. Полное подчинение действий человека абстрактной идее - пока все же выглядит как редкий пограничный случай. И отнюдь не всегда результаты такого подчинения нам могут понравиться. Террорист самоубийца тоже действует ради абстрактной идеи (сверхидеи).
Сейчас уже и на то, как рассказывать о прошлом опыте, есть свой шаблон. Побольше "якать", употреблять обороты "я сделал, я добился". Такому "речекряку" научиться каждый может.
Чтобы адекватно отразить корпоративную шизофрению, надо еще пару деталей на картинку добавить:
1) Гребцы из разных "аджайл команд" гребут в разные стороны.
2) Над палубой с гребцами еще один этаж - с менеджментом.
Все верно, плюс можно добавить: "не ведитесь на премии". Премию могут либо дать, либо не дать, в том числе и по независящим от вас обстоятельствам.
Если цифра указанного в договоре оклада является приемлемой - с остальными деталями можно разобраться по ходу. Разумеется, соблюдая правило "не работать больше 8 часов".
По большому счету, если в переработки не впрягаться, все остальное не так уж страшно.
Работал я как-то в конторе, где разработчики больше половины рабочего времени были на созвонах. Сначала бесило, а потом я подумал примерно так: Ну ок, если контора настолько богата, что готова мне платить не за разработку, а за говорение слов - почему нет?
Разве что профессиональные навыки на такой работе стагнируют. Поэтому в долгосрочной перспективе все таки лучше в таких местах не засиживаться.
Такие разработчики если и встречаются, то неудобны для менеджмента. Если человек и вправду может собой целый небольшой отдел заменить - это только на первый взгляд выглядит круто. А со стороны менеджера - гораздо престижнее руководить целым отделом из фреймворкщиков и CI/CD, чем руководить одним человеком (который и в руководстве не нуждается).
А как вы за пару часов проверяете такое качество как "ответственность"?