Имена переменным цикла типа "iterator" вместо "i" дают люди, написавшие мало циклов за свою жизнь (это если в частности).
Если формулировать общее правило - имена переменных должны быть тем длиннее, чем больше время их жизни (т.е. больше и разнообразнее контекст, в котором они встречаются).
Так-то в условном Хаскеле : f, a, m, k - все прекрасно понимают что значит и никто не жалуется.
Упрощайте всё максимально, но не больше (бритва Эйнштейна), вы с ней не справились. Упростили поведение людей больше необходимого.
Многие-многие-многие вещи в человеческой цивилизации работают просто потому, что людям (вне рациональных причин) хочется сделать что-то хорошо.
В этом смысле у фирм - более сильная позиция, потому, что они подобными "багами человеческой прошивки" не отягощены.
П.С. Ну и в целом статья чрезвычайно дилетантская. Ну прям с ходу: часто "максимизировать матожидание выигрыша" и "максимизировать вероятность первого места" - требует разных стратегий. В стаье же излагается из презумпции, что требуются одинаковые стратегии.
То есть пройти секции на «всё отлично» и «всё супер!» недостаточно
Тоже эта "инфляция оценок" раздражает (к счастью пока только со стороны сталкивался), когда просто beyond expectations недостаточно, а надо beyond beyond beyond expectations.
Статья основана на недоказанной презумпции: - фильтр на джуновских позициях - это хорошо - фильтр на пред-джуновских позициях (в универе или когда программирование это хобби в 16 лет) - это плохо.
Между тем именно так "меня торкало писать программки, разбираться в IT и копаться в чужом SW со школы" - вход в IT работал бОльшую часть времени. А состояние "на сегодня" - создаёт огромных поток плохо пригодных для IT вкатунов, которые даже если обманули на первом собесе - выгорают через 3 года на "позиции перекладывателя JSON-ов".
20 лет назад: - в России "нужно было" 50_000 программистов. - за становление программистом тебе не платили - в профессию шли только те, кого торкало от процесса программирвоания / создания программ / разбора сложных технических софтварных решений - в результате работал фильтр - если тебя торкает от IT ты идёшь в профессию
5 лет назад: - в России 500_000 - 1_000_000 программистов - в джуны берут всех подряд после курсов (не глядя на склонности и способности) доучивают на работе за какие-то разумные деньги на позиции джуна - в професии куча людей, которая занимается совершенной рутиной, не имеет склонности к профессии, выгорает. - фильтра на входе нет, но в профессии всё равно фильтр, "расставляющий" людей по этажам
чере 5 лет: - кто не умеет программировать - всё равно может навайбкодить программку для автоматизации - в профессии "много" людей умеющих программировать не нужно - внутри профессии нет "джуновских" позиций - люди попадают в профессию либо проявив значительные навыки в универе либо развившись до миддлов в качестве хобби
Сегодня вы женились - если так продолжится и дальше через 2 месяца у вас будет 60 жён! Сегодня у вас CAPEX в дата-центры $1 триллиона, а доходов 0. Если так продолжится 5 лет - ваши расходы будут 5 триллионов.
Суть статьи - применение узконаправленных индикаторов (линейной интерполяции, корпоративных метрик ...) ко всей экономике. Прежде чем решать задачу методом Х, а потом пугаться ответа - надо узнать, а задачи такого типа методом Х вообще решаются ли (а то был такой сайт авантюрист орг - где методом технического анализа (всяких свечек и уровней отсечки) доказывался дефолт доллара, ну и что? Китай на 2/3 вышел из долговых облигаций США и где дефолт)?
Слова дёшевы. Дорого качественное решение (качественно - значит надёжное и поддерживаемое, что априорно значит - хотя бы соответствующее best practices).
Будет решение - будет смысл оценивать как "правильно" его получить. А пока это довольно дешёвые слова.
Моя 7-летняя дочка сегодня ругала Алису, что та неправильно с ней играла в "угадай животное" - название игры сказала дочь, Алиса идею как-то уловила и стала с ней играть.
Внимание вопрос - в какую из перечисленных в "исследовании" групп она попадает?
Я вообще не понимаю зачем люди (ну кроме как запутать других и по дороге себя) сравнивают маляра и программиста.
99% работы маляра красящего забор состоит из "подготовить и покрась 1 доску 1000 раз". Соответственно можно посмотреть как он красит 1 доску и это закроет большинство вопросов.
У программиста десятки разных задач. Часть из них решается железной задницей и заучиванием инструментов. Часть - просто требует обширных знаний или "острого ума" (а лучше обеих черт сразу) - чтобы понимать "как задачу Х вообще можно сделать". Что часто экономит или уйму времени или вообще разделяет варианты "можем / не можем сделать систему удовлетворяющую требованиям".
П.С. Несоклько дополнительных замечаний:
Есть программисты, которые всю свою карьеру - "перекладывали джейсоны" 10000 раз, как тот моляр. Такие люди есть, но работодатель вполне имеет право сказать - такие люди мне не нужны (собственно если просит обойти дерево - намекает, что в работе нужны минимальный кругозор или минимальная острота ума).
Собственно то, что в IT "написать минимальную программку" от "разработать систему" разительно отличается, а часть навыков необходимых для разработки системы непосредственно и объективно проверить сложно - есть одна из ключевых особенностей нашей отрасли, особенно при найме.
Заметил, что требования работодателей к кандидатам по каждой из упомянутых выше вещей: "минимальная насмотренность в IT" и "острота ума" - регулярно подвергаются критике в комментах на хабре. Не имею намерения ни кого клеймить - но в целом для меня это выглядит крайне странно (в том числе см. пункт-1).
Очень полезно детей в 12-14 лет тренировать "задачками на абстрактное мышление" (это ровно когда способность к абстракному мышлению прорезается боле-менее у всех детей).
Проблема в том, что реальных таких задачек - где дети бы тренировали мышление, а не "вход в предметную область и миллион исключений" не очень много.
А математика отлична подходит, и даже крохотной её доли, - изученной содержательно, - достаточно, чтобы абстрактное мышление, и способы решать такие модельные задачи натренировать.
Если же вы к (пусть будет пальцем в небо 25 годам) "матан не освоили" - то он вам и не нужен. Работайте над реальными задачами, толку будет больше.
Есть 2 принципиально разных вопроса: - как сделано Х? - почему выбрано Х а не, например Y?
Ответ на вопрос "как" - нужен для текущей эксплуатации системы (и обычно освещён в мануалах - иначе система вообще не считается сданной).
Ответ на вопрос "почему" - нужен для развития системы. Пишется редко, потому, что описать его ну как бы не столь же сложно, как и записать код, да ещё и непонятно с какого конца браться (и всегда можно оказаться в ситуации, когда выполнил пол-работы и нарвался на критику).
И есть ощущение что спор потому, что под "докой" одна сторона понимает "как", а другая "почему".
ИИ чудо как хорош поп "попсовым" темам. Но шаг вправо-шаг влево - начинает лажать и придумывать (*) Поэтому умение отличать гладко слепленную лажу (а если не умеешь - умение не задавать вопросов верность ответов на которые ты не сможешь проверефицировать) от реальной экспертизы - становится всё ценнее.
*) Чтобы не быть голослвным, например при просьбе объяснить некоторые нюансы реализации аппаратных кэшей - просто превращается в T9 на стероидах.
Для меня в описании статьи не хватает пояснений - почему то, что ниже не подвид генетических алгоритмов (чем оно является судя по описанию и чей пик популярности пришёлся на середину 2010х), а сравниваетс с квантовым компьютером.
В нашей терминологии это называется «популяция кандидатов». GPU параллельно оценивает каждого, отсеивает слабых, смешивает сильных и через механизм коллективной динамики (мы это скромно называем «интерференционно-подобная синхронизация») концентрирует усилия на самых вкусных областях пространства.
Вайб-кодинг - давать ИИ небольшие задачи по написанию кода.
Agentic engeneering - давать ИИ большие задачи сделать систему.
Вайб-кодинг доказуемо не работает, поскольку пока ИИ выполняет вашу небольшую задачку он может начать совершать ошибки или галюцинировать (даже просьбы покрыть написанный код тестами не помогают).
Объясните пожалуйста, если знаете - чем сопромат "продуктивнее для мозгов" чем скажем real analysis (та часть матана, где надо выводить его свойства для R)?
Вот честно - сопромат жутко унылая и тупая тягомотина (ну это как человек ходивший на олимпиады по мат-ке, IT и сопромату), те же теоретическая механика или real analisys (это "хороший" школьный матан) - в 100 раз интереснее и продуктивнее для мозгов.
нужно абсолютно везде платить исключительно чорным налом.
Ну с реалиями российских микро-бизнесов "ой терминал сломался вот только что оплатите наличкой" вы знакомы? Причём в нише ниже какого-то оборота это прямо повсеместное явление.
Из-за 3%-2.5% комиссии за эквайринг это малоосмысленно делать. А вот за 20(22) - уже норм.
Имена переменным цикла типа "iterator" вместо "i" дают люди, написавшие мало циклов за свою жизнь (это если в частности).
Если формулировать общее правило - имена переменных должны быть тем длиннее, чем больше время их жизни (т.е. больше и разнообразнее контекст, в котором они встречаются).
Так-то в условном Хаскеле : f, a, m, k - все прекрасно понимают что значит и никто не жалуется.
Упрощайте всё максимально, но не больше (бритва Эйнштейна), вы с ней не справились.
Упростили поведение людей больше необходимого.
Многие-многие-многие вещи в человеческой цивилизации работают просто потому, что людям (вне рациональных причин) хочется сделать что-то хорошо.
В этом смысле у фирм - более сильная позиция, потому, что они подобными "багами человеческой прошивки" не отягощены.
П.С.
Ну и в целом статья чрезвычайно дилетантская.
Ну прям с ходу: часто "максимизировать матожидание выигрыша" и "максимизировать вероятность первого места" - требует разных стратегий. В стаье же излагается из презумпции, что требуются одинаковые стратегии.
Тоже эта "инфляция оценок" раздражает (к счастью пока только со стороны сталкивался), когда просто beyond expectations недостаточно, а надо beyond beyond beyond expectations.
Статья основана на недоказанной презумпции:
- фильтр на джуновских позициях - это хорошо
- фильтр на пред-джуновских позициях (в универе или когда программирование это хобби в 16 лет) - это плохо.
Между тем именно так "меня торкало писать программки, разбираться в IT и копаться в чужом SW со школы" - вход в IT работал бОльшую часть времени.
А состояние "на сегодня" - создаёт огромных поток плохо пригодных для IT вкатунов, которые даже если обманули на первом собесе - выгорают через 3 года на "позиции перекладывателя JSON-ов".
===============================================================
20 лет назад:
- в России "нужно было" 50_000 программистов.
- за становление программистом тебе не платили
- в профессию шли только те, кого торкало от процесса программирвоания / создания программ / разбора сложных технических софтварных решений
- в результате работал фильтр - если тебя торкает от IT ты идёшь в профессию
5 лет назад:
- в России 500_000 - 1_000_000 программистов
- в джуны берут всех подряд после курсов (не глядя на склонности и способности) доучивают на работе за какие-то разумные деньги на позиции джуна
- в професии куча людей, которая занимается совершенной рутиной, не имеет склонности к профессии, выгорает.
- фильтра на входе нет, но в профессии всё равно фильтр, "расставляющий" людей по этажам
чере 5 лет:
- кто не умеет программировать - всё равно может навайбкодить программку для автоматизации
- в профессии "много" людей умеющих программировать не нужно
- внутри профессии нет "джуновских" позиций
- люди попадают в профессию либо проявив значительные навыки в универе либо развившись до миддлов в качестве хобби
Сегодня вы женились - если так продолжится и дальше через 2 месяца у вас будет 60 жён!
Сегодня у вас CAPEX в дата-центры $1 триллиона, а доходов 0. Если так продолжится 5 лет - ваши расходы будут 5 триллионов.
Суть статьи - применение узконаправленных индикаторов (линейной интерполяции, корпоративных метрик ...) ко всей экономике.
Прежде чем решать задачу методом Х, а потом пугаться ответа - надо узнать, а задачи такого типа методом Х вообще решаются ли (а то был такой сайт авантюрист орг - где методом технического анализа (всяких свечек и уровней отсечки) доказывался дефолт доллара, ну и что? Китай на 2/3 вышел из долговых облигаций США и где дефолт)?
Слова дёшевы.
Дорого качественное решение (качественно - значит надёжное и поддерживаемое, что априорно значит - хотя бы соответствующее best practices).
Будет решение - будет смысл оценивать как "правильно" его получить. А пока это довольно дешёвые слова.
Моя 7-летняя дочка сегодня ругала Алису, что та неправильно с ней играла в "угадай животное" - название игры сказала дочь, Алиса идею как-то уловила и стала с ней играть.
Внимание вопрос - в какую из перечисленных в "исследовании" групп она попадает?
Скорее всего то, что "библиотека распознования кодировок" и "операционная система" - ПО несколько разного уровня сложности, ну так немного ;)
Я вообще не понимаю зачем люди (ну кроме как запутать других и по дороге себя) сравнивают маляра и программиста.
99% работы маляра красящего забор состоит из "подготовить и покрась 1 доску 1000 раз".
Соответственно можно посмотреть как он красит 1 доску и это закроет большинство вопросов.
У программиста десятки разных задач.
Часть из них решается железной задницей и заучиванием инструментов.
Часть - просто требует обширных знаний или "острого ума" (а лучше обеих черт сразу) - чтобы понимать "как задачу Х вообще можно сделать". Что часто экономит или уйму времени или вообще разделяет варианты "можем / не можем сделать систему удовлетворяющую требованиям".
П.С.
Несоклько дополнительных замечаний:
Есть программисты, которые всю свою карьеру - "перекладывали джейсоны" 10000 раз, как тот моляр. Такие люди есть, но работодатель вполне имеет право сказать - такие люди мне не нужны (собственно если просит обойти дерево - намекает, что в работе нужны минимальный кругозор или минимальная острота ума).
Собственно то, что в IT "написать минимальную программку" от "разработать систему" разительно отличается, а часть навыков необходимых для разработки системы непосредственно и объективно проверить сложно - есть одна из ключевых особенностей нашей отрасли, особенно при найме.
Заметил, что требования работодателей к кандидатам по каждой из упомянутых выше вещей: "минимальная насмотренность в IT" и "острота ума" - регулярно подвергаются критике в комментах на хабре.
Не имею намерения ни кого клеймить - но в целом для меня это выглядит крайне странно (в том числе см. пункт-1).
Очень полезно детей в 12-14 лет тренировать "задачками на абстрактное мышление" (это ровно когда способность к абстракному мышлению прорезается боле-менее у всех детей).
Проблема в том, что реальных таких задачек - где дети бы тренировали мышление, а не "вход в предметную область и миллион исключений" не очень много.
А математика отлична подходит, и даже крохотной её доли, - изученной содержательно, - достаточно, чтобы абстрактное мышление, и способы решать такие модельные задачи натренировать.
Если же вы к (пусть будет пальцем в небо 25 годам) "матан не освоили" - то он вам и не нужен. Работайте над реальными задачами, толку будет больше.
Есть 2 принципиально разных вопроса:
- как сделано Х?
- почему выбрано Х а не, например Y?
Ответ на вопрос "как" - нужен для текущей эксплуатации системы (и обычно освещён в мануалах - иначе система вообще не считается сданной).
Ответ на вопрос "почему" - нужен для развития системы. Пишется редко, потому, что описать его ну как бы не столь же сложно, как и записать код, да ещё и непонятно с какого конца браться (и всегда можно оказаться в ситуации, когда выполнил пол-работы и нарвался на критику).
И есть ощущение что спор потому, что под "докой" одна сторона понимает "как", а другая "почему".
ИИ чудо как хорош поп "попсовым" темам.
Но шаг вправо-шаг влево - начинает лажать и придумывать (*)
Поэтому умение отличать гладко слепленную лажу (а если не умеешь - умение не задавать вопросов верность ответов на которые ты не сможешь проверефицировать) от реальной экспертизы - становится всё ценнее.
*) Чтобы не быть голослвным, например при просьбе объяснить некоторые нюансы реализации аппаратных кэшей - просто превращается в T9 на стероидах.
Для меня в описании статьи не хватает пояснений - почему то, что ниже не подвид генетических алгоритмов (чем оно является судя по описанию и чей пик популярности пришёлся на середину 2010х), а сравниваетс с квантовым компьютером.
Так-то вопрос по статье, а не agentic engeneering ;)
Если в статье написано - то приведите цитату, не нашёл.
Примерный пересказ статьи:
Вайб-кодинг - давать ИИ небольшие задачи по написанию кода.
Agentic engeneering - давать ИИ большие задачи сделать систему.
Вайб-кодинг доказуемо не работает, поскольку пока ИИ выполняет вашу небольшую задачку он может начать совершать ошибки или галюцинировать (даже просьбы покрыть написанный код тестами не помогают).
Выход? Выход - agentic engeneering.
Я в логике статьи ничего не напутал?
Пул в виде массива.
Запрос пула из энтри - возвращает индекс в массиве.
Толко имеет ли смысл выполнять формальные требования полностью игнорируя изначальную идею?
Объясните пожалуйста, если знаете - чем сопромат "продуктивнее для мозгов" чем скажем real analysis (та часть матана, где надо выводить его свойства для R)?
Ну блин медицина, учёба (платные садики, уже включено автоматом), приобретение жилья...
Вот честно - сопромат жутко унылая и тупая тягомотина (ну это как человек ходивший на олимпиады по мат-ке, IT и сопромату), те же теоретическая механика или real analisys (это "хороший" школьный матан) - в 100 раз интереснее и продуктивнее для мозгов.
Ну с реалиями российских микро-бизнесов "ой терминал сломался вот только что оплатите наличкой" вы знакомы?
Причём в нише ниже какого-то оборота это прямо повсеместное явление.
Из-за 3%-2.5% комиссии за эквайринг это малоосмысленно делать.
А вот за 20(22) - уже норм.