при повторении желания это будет квалифицироваться как заболевание:
МКБ-11 (актуальная версия с 2022 г.)
6C70 Расстройство контроля импульсов — включает повторяющиеся эпизоды неспособности контролировать агрессивные импульсы, приводящие к нападениям на людей или разрушению имущества (интермиттирующее взрывчатое расстройство).
6E70 Оппозиционно-вызывающее расстройство — у детей/подростков: гневливость, споры, провокационное поведение, но без серьёзного физического насилия.
6E71 Расстройство поведения — повторяющееся и устойчивое агрессивное поведение, нарушающее права других (включая физические нападения).
и куда нужно ударить, если нагенерированный ИИ код не собирается в сборку из-за несогласованности зависимостей? — мой реальный кейс на днях с моделями Source Craft Code Assistant
во-первых, вы используете устаревшую лексику из прошлого века
во-вторых, вы видимо таким образом пытаетесь обесценить «пользователей» профессиональных инструментов: — композитор, который использует ПО для создания музыки — «оператор ЭВМ, обезбьянка, вводящая команды» — инженер-строитель, который использует ПО для прочностных расчётов — «оператор ЭВМ, обезьянка, вводящая команды»
в любом случае попытка обесценить указывает на болезненную уязвлённость и неготовность принять новую реальность
я например классический инженер со знанием физики, высшей математики, химии, электротехники, механики, материаловедения, сопромата, дискретной математики, программирования структурного, декларативного, функционального и объектного, теории баз данных, теории управления производством, теории автоматического управления, искусственного интеллекта версии 2000-го года (фреймы, семантические сети, нечёткая логика, параллельные генетические алгоритмы)
но образование это помогает мне примерно никак, когда я делаю мобильное приложение на Котлине с помощью ГенИИ
необходимые для эффективной работы в таких задач практические знания можно получить за 50-100 часов опыта и изучения, 5000 часов вузовской дедовщины не нужны
большинство разработчиков ПО в мире УЖЕ не имеют инженерного образования и ваша охранительно-дедовская позиция им никак не поможет, нет никакого доказательства, что в современном мире для создания работающего софта нужны 5 лет отсидки
но если разработка кода автоматизирована, значит пора менять свою роли и отношение к разработке.
зачем сохранять роль именно "разработчика"?, можно перейти в роль заказчика или хотя бы генерального конструктора. генеральный конструктор знает в деталях, как работает вся конструкция? нет. ему надо? тоже не очень.
те. страшно? или что значит «контроль за кодом»? то, что происходит в «мозгах» стиральной машинки или даже сотрудника вы тоже не особо контролируете.
в управлении даже есть такие виды контроля — как контроль по результату, контроль по квалификации, контроль по процессу. вам видимо нужен контроль по процессу. зачем?
Для максимального сходства с известным персонажем на фото выше,
Это не персонаж, а культовый продюсер Рик Рубин, ответственный за альбомы Beastie Boys, Slayer, Danzig, RHCP, Джонни Кэша, System of a Down, Rage Against the Machine, Limp Bizkit, Slipknot, Linkin Park, Metallica, ZZ Top, Eminem.
Я понимаю, что вам образ Оззи и Мастейна знакомей, но развитому человеку полезно иметь широкий культурный кругозор, а не только гордиться флюсом инженера.
проблема именно в том, что подряд предполагает (и заказчик часто именно так и хочет), что бы затраты на поиск правильной комбинации были переложены на подрядчика
это можно частично решать тем, чтобы выстраивать с заказчиком работу по проведению им же прагматичного минимального бизнес-анализа, хотя бы через чек-листы вида:
□ Да / □ Нет — Цель проекта сформулирована через решение проблемы, а не как задача в воздухе (не «внедрить CRM», а «сократить цикл/ошибки/затраты»).
□ Да / □ Нет — Есть 1–3 измеримых KPI успеха: baseline → target → срок (и источник данных).
□ Да / □ Нет — Расчетные эффекты существенны для заказчика — ROI превышает ROI других возможных инициатив по автоматизации заказчика.
□ Да / □ Нет — Проведены натурные эксперименты, показывающие достижимость целевых эффектов.
это всё зависит от маржинальности бизнеса. если она < 10%, то да, такие скачки для него могут быть смертельны. у нас она была порядка 10%, поэтому сильно упадёт, но за счёт именно АУСН — не в 0.
но да, нас гораздо сильнее задело падение спроса в разы, чем прямые налоги
мне за 30 лет в интернете надоело такую херню читать
это вам не чатик со смех****чками
при повторении желания это будет квалифицироваться как заболевание:
МКБ-11 (актуальная версия с 2022 г.)
6C70 Расстройство контроля импульсов — включает повторяющиеся эпизоды неспособности контролировать агрессивные импульсы, приводящие к нападениям на людей или разрушению имущества (интермиттирующее взрывчатое расстройство).
6E70 Оппозиционно-вызывающее расстройство — у детей/подростков: гневливость, споры, провокационное поведение, но без серьёзного физического насилия.
6E71 Расстройство поведения — повторяющееся и устойчивое агрессивное поведение, нарушающее права других (включая физические нападения).
по МКБ это заболевание: https://www.findacode.com/icd-11/code-1430296724.html
у меня нет просьбы, мне интересно, как рассуждает Wesha
и куда нужно ударить, если нагенерированный ИИ код не собирается в сборку из-за несогласованности зависимостей? — мой реальный кейс на днях с моделями Source Craft Code Assistant
ничего вы не огорчили
во-первых, вы используете устаревшую лексику из прошлого века
во-вторых, вы видимо таким образом пытаетесь обесценить «пользователей» профессиональных инструментов:
— композитор, который использует ПО для создания музыки — «оператор ЭВМ, обезбьянка, вводящая команды»
— инженер-строитель, который использует ПО для прочностных расчётов — «оператор ЭВМ, обезьянка, вводящая команды»
в любом случае попытка обесценить указывает на болезненную уязвлённость и неготовность принять новую реальность
я например классический инженер со знанием физики, высшей математики, химии, электротехники, механики, материаловедения, сопромата, дискретной математики, программирования структурного, декларативного, функционального и объектного, теории баз данных, теории управления производством, теории автоматического управления, искусственного интеллекта версии 2000-го года (фреймы, семантические сети, нечёткая логика, параллельные генетические алгоритмы)
но образование это помогает мне примерно никак, когда я делаю мобильное приложение на Котлине с помощью ГенИИ
необходимые для эффективной работы в таких задач практические знания можно получить за 50-100 часов опыта и изучения, 5000 часов вузовской дедовщины не нужны
большинство разработчиков ПО в мире УЖЕ не имеют инженерного образования и ваша охранительно-дедовская позиция им никак не поможет, нет никакого доказательства, что в современном мире для создания работающего софта нужны 5 лет отсидки
это всё понятно
но если разработка кода автоматизирована, значит пора менять свою роли и отношение к разработке.
зачем сохранять роль именно "разработчика"?, можно перейти в роль заказчика или хотя бы генерального конструктора. генеральный конструктор знает в деталях, как работает вся конструкция? нет. ему надо? тоже не очень.
Инструкция классная, ещё было бы интересно увидеть примеры, что, с каким качеством и за какое время было сделано по этой технологии.
Думаю в ближайшие полгода подход станет стандартом де-факто для многих разработчиков и команд.
те. страшно? или что значит «контроль за кодом»? то, что происходит в «мозгах» стиральной машинки или даже сотрудника вы тоже не особо контролируете.
в управлении даже есть такие виды контроля — как контроль по результату, контроль по квалификации, контроль по процессу. вам видимо нужен контроль по процессу. зачем?
Это не персонаж, а культовый продюсер Рик Рубин, ответственный за альбомы Beastie Boys, Slayer, Danzig, RHCP, Джонни Кэша, System of a Down, Rage Against the Machine, Limp Bizkit, Slipknot, Linkin Park, Metallica, ZZ Top, Eminem.
Я понимаю, что вам образ Оззи и Мастейна знакомей, но развитому человеку полезно иметь широкий культурный кругозор, а не только гордиться флюсом инженера.
а в заголовке обобщение
это один из типовых грехов начинающих аналитиков — избыточное и необоснованное обобщение
Каких аналитиков? Маркетинговых аналитиков, финансовых аналитиков, SOC-аналитиков?
в языке и инженерии давно уже есть похожие концепции;
где тонко, там и рвётся
ГОСТ 9.707-81: Единая система защиты от коррозии и старения. Материалы полимерные. Методы ускоренных испытаний на климатическое старение
Но видимо руководители не считали важным принципом управления, пришлось целую теорию очевидного-невероятного придумать
в заголовке опять пропущено слово «... аналитика ДАННЫХ...»
это можно частично решать тем, чтобы выстраивать с заказчиком работу по проведению им же прагматичного минимального бизнес-анализа, хотя бы через чек-листы вида:
□ Да / □ Нет — Цель проекта сформулирована через решение проблемы, а не как задача в воздухе (не «внедрить CRM», а «сократить цикл/ошибки/затраты»).
□ Да / □ Нет — Есть 1–3 измеримых KPI успеха: baseline → target → срок (и источник данных).
□ Да / □ Нет — Расчетные эффекты существенны для заказчика — ROI превышает ROI других возможных инициатив по автоматизации заказчика.
□ Да / □ Нет — Проведены натурные эксперименты, показывающие достижимость целевых эффектов.
и т.д.
недолго мучалась старушка
Вторая схема ГОКа так и не показала, что происходит между добычей руды и её переработкой)
Ложь начинается прям с первой строчки.
Он использовал диаграммы для планирования и организации (мелкосерийного) производства, а не проектов. Там даже на первой иллюстрации видно.
Вы понимаете разницу между производством и проектами?
это всё зависит от маржинальности бизнеса. если она < 10%, то да, такие скачки для него могут быть смертельны. у нас она была порядка 10%, поэтому сильно упадёт, но за счёт именно АУСН — не в 0.
но да, нас гораздо сильнее задело падение спроса в разы, чем прямые налоги
малые бизнесы узнали-вспомнили, кому не охота попадать на НДС + УСН сразу