Comments 113
Программирование - это инженерная дисциплина. Единственное отличие, что инженеров-механиков в полёте фантазии ограничивает суровая реальность, т.к. нельзя протянуть сто рычагов через весь самолёт, а у программистов таких отрезвляющих рамок реальности нет - код всё стерпит.
у программистов таких отрезвляющих рамок реальности нет - код всё стерпит
Нет, не стерпит.
бывает кодирование модели чипа, писать ядра на VHDL, Verilog - чип не стерпит и оптимизация на 10 процентов очень заметна, в том числе денежно.
VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.
Да, это сравнение на другой стороне глобуса, просто железо ошибок не прощает - как правило, либо работает код модели, либо нет. И не факт что в реальном чипе будет работать после фпга, и как вы заметили, запустится на фпга не любой код который формально работает в симуляторе.
Но в enterprise программировании иногда не понимают что к примеру, на java изображения лучше не обрабатывать, для этого есть более эффективные языки или библиотеки - но нет, прут напролом и в итоге ставят 500 нодов вместо 100 в кластере и при этом с библиотекой на java, которую пересли с библиотеки на С! Потому что родная жрала памяти раз в 10 больше и медленнее раз в 5 чем клон сишной на жабе... На средних картинках. Вот тебе и эффективность.
Несколько лет клиент жжет электричество используя заведомо неэффективное решение.
В java даже определить хватит тебе памяти или нет чтобы развернуть изображение, нет нормальных способов. Вернее можно но очень ненадежно, с большим запасом. Ловят оом периодичеси., он кладет веб сервер...
Почему вспомнил - попал на поддержку такого чуда. Там бы архитектуру поменять а не заплатки лепить...
Код все стерпит, это точно, в enterprise так точно
Разница между программистами и другими инженерами принципиальная - программисты пишут тексты для людей
Исходный код - это конструкторская документация.
Сборка исполняемого файла - это изготовление на заводе.
Исполнение программы - это работа устройства.
Так что принципиальной разницы не вижу. КД тоже люди читают и правят при необходимости.
не совсем, КД - описание алгоритма, программирование, отладка, сборка и пр. - скорее этапы исготовления, по опыту так было, хотя возможно есть новые госты, стоило бы проверить
Отладка - это скорее что-то типа опытного производства, когда по предварительной КД изготавливают опытные экземпляры, тестируют, вносят изменения в КД, и так по кругу, пока не получится что-то жизнеспособное.
отладка разная бывает, и дело не в том на что именно похоже, а как определен рабочий цикл - ТЗ, ЭП, ТП, КД, изготовление, по старому программирование и тд. это изготовление, этап КД это алгоритмы, которые тоже конечно не на пустом месте делаются
Если бы программирование было частью изготовления - разве его не надо было бы повторять для каждой сборки?
не совсем понимаю Вас, изготовление это процесс, но специфика sw в том, что делается один раз, типа sw сертификацию прошло - изготовление закончено, версия кода заморожена, без разницы сколько надо будет копий, и как именно они делаются, полной компиляцией, сборкой - линкованием, или нет без разницы, конечно по ТЗ могут быть дополнительные требования управления конфигурацией например скриптами и т.п., но это не изготовление, также могут быть особые требования по сопровождению, по памяти примерно так, новые госты могут отличаться
Я в контексте физического производства размышляю, где изготовление - это изготовление каждой отдельной копии исполняемого файла, и оно может вестись методом сборки из исходников, либо простым копированием уже готовых бинарей.
А программирование - это процесс разработки того, из чего впоследствие исполняемые файлы будут изготавливаться. Типа как создание 3д моделей/чертежей деталей.
В этом смысле чертежи тоже один раз сертификацию проходят, так же как и код.
Если исходный код это КД, то что такое тогда документация к коду?
Можно предположить, что и то, и другое - КД. Просто разные "слои" или "уровни".
А давайте нельзя предположить и будем называть вещи своими именами. Код это код, а документация это то что описывает то как этот код работает. Потому что иначе у вас вообще все на свете это слои или уровни документации.
А вы просто не подшивали исходные коды в папочки, а я подшивал. Каждая версия - распечатывалась, подшивалась, сдавалась в архив архивариусу под акт.
А вот бинарь - нет.
Что как бы намекает, что таки да, исходный код - это тоже часть документации.
Да, оч крутой аргумент. Я могу и бинарь распечатать и подшить в папочке. Таким образом ВСЕ - документация. Поэтому этот термин бессмысленен если использовать его так как используете вы.
А давайте нельзя предположить и будем называть вещи своими именами. Код это код, а документация это то что описывает то как этот код работает
Код в классическом понимании, это такая же документация. У конструктора есть техническое задание, которое объясняет, как должна работать его, кхм, разработка. Есть спецификации разных уровней, которые это уточняют уже более детально. И есть чертежи/схемы, которые уже описывают непосредственно всю разработку. Так же и с кодом. Есть техническое задание, есть спецификации на API, структуры данных, какие-то алгоритмы. А есть собственно код, который подробно описывает всё, что должна делать программа. Это тоже конструкторская документация, всё верно.
Код это код, а документация это то что описывает то как этот код работает.
Не «как», а «почему» и «зачем (для чего, с какой целью)».
Согласен, и так даже лучше
А, например, сие - это "как", "почему" или "зачем"?
как
А зачем (с какой целью) Вы эту функцию вызывать собрались? Вы не из милиции случайно?
Много лет назад Алексей Бабий писал следующее:
Деятельность программиста не есть изготовление, а есть описание технологических процессов. Следовательно, аналогом деятельности программиста является не деятельность сборщика машин, а деятельность технолога. В частности, это означает, что для оценки производительности труда не нужно искать способ оценки количества продукции, выпускаемой программистом - поскольку никакая продукция не производится. Нужно установить категории сложности, как у технологов. (Следует отметить, что деятельности технолога предшествует деятельность по разработке технологии, т.е. деятельность научная. Собственно производственный характер работа получает только после выдачи спецификации.)
Деятельность программистов состоит из двух частей - конструкторской и технологической. Конструкторская деятельность заканчивается с утверждением спецификаций: понятия составляющие изделие, определены и определены связи между ними. Технологическая деятельность (собственно программирование) заключается в описании технологии изготовления этих понятий.
Спасибо, прочитал, надо осознать. Пока кажется автор немного не туда мысль увёл.
В (моём) машиностроительном представлении:
исходный код - чертежи
скрипты сборки - техпроцесс
компилятор - механообрабатывающий цех
линковщик - сборочный цех
программа - готовое изделие
ПК на котором работает программа - реальность в которой работает изделие
Т.е. код действительно не продукт, но и не "материализация абстрактных понятий".
Точно. Люди читают код и исполняют его, а комтьютер - это такая коробчка, где они живут месяцами и бессменно лопатят код.. )
Код-то может и стерпит. А клиенты могут и не стерпеть.
Утеря средств клиентов крипто-биржей из-за кривого кода. Упавший интернет-банк из-за кривых ручонок погромистов с тестерами и, как следствие, финансовые и репутационные убытки у достаточно крупного и зрелого банка. И это наблюдения только из моей практики. Есть и достаточно известные случаи. Например достаточно известен случай про облучение пациентов смертельной дозой медицинским аппаратом из-за кривого кода. Проблемы с MCAS у боинга связаны (в том числе) и с кривым кодом. У Тоёоты были отзывы из-за кривого софта в ABS и, емнип, с цифровой педалью газа, приводившей к неконтролируемому ускорению автомобиля.
... торговый робот, который за 45 минут спустил в трубу почти полмиллиарда
И еще один
Проблемы с MCAS у боинга связаны (в том числе) и с кривым кодом
если я не ошибаюсь, проблемы там с архитектурой и концептом самой подсистемы, а не конечным программным кодом
Насколько я понимаю, там целая цепочка проблем. В боинге захотели новые движки, которые были по размеру больше, чем заложенные в проекте. Пришлось их повесить чуть-чуть вперёд и ниже, алтернатива - всё переделывать. Решили таки не переделывать. Что сместило центр тяги и задирало нос самолёта (кривая архитектура). Как костыль приделали (перепрошили?) MCAS, который опускал нос самолёта ниже, основываясь на датчиках. Боинг, посчитав, что в случае проблем с MCAS пилоты разпознают ситуацию как "runaway stabilizer" и отключат автотримминг (или как он там правильно называеся), который в свою очередь отключает MCAS, решило не оповещать об этом авиалинии для включения в тренировки пилотов. Потому что дополнительные тренировки - дополнительные деньги.
Так вот, MCAS тоже не был должным образом протестирован, и заваливал нос самолёта тогда, когда этого не надо было делать. А пилоты тех злополучных рейсов не распознали ситуацию как "runaway stabilizer" и... в общем дальше вы знаете. Тогда как пилоты как минимум одного другого рейса смогли правильно распознать ситуацию и отключить MCAS.
Вследствие всего этого в интернете одни винят "эффективных" менеджеров боинга за неправильные решения, другие инженеров-проектировщиков за кривую архитектуру, третьи недостаточную квалификацию пилотов.
ну собственно основная причина именно в архитектуре всего решения в комплексе
то что было принято решение "пусть пилоты не делают так что будет плохо" вместо того чтобы сделать всё полностью автоматически, причем еще умудрились повесить сюда маркетинговую фишку - продавая индикацию работы системы за отдельное бабло...чтобы пилоты еще и в угадайку поиграли - чёващепроисходит.
по этому я бы инженеров как таковых бы тут не особо и обвинял бы
Вопрос в том, что если не допусти они хотя бы одну из ошибок - катастроф не было бы. Будь MCAS нормально запрограмирован - летали бы эти боинги до сих пор и в ус не дули, несмотря на остальные проблемы архитектуры. А изначальный тезис был о том, что за качеством кода надо следить, иначе клиенты пострадают
Вопрос в том, что если не допусти они хотя бы одну из ошибок - катастроф не было бы.
В Чернобыле тоже. https://ru.wikipedia.org/wiki/Модель_швейцарского_сыра
Очень интересно какого цвета банк) Со своими наблюдениями сложить
Уволен нахер. Бугага. Стерпит у него.
Исходя из вашего понимания термина, назовите пару не инженерных дисциплин
А чем вас определение с википедии не устраивает: https://ru.wikipedia.org/wiki/Инженерное_дело ?
Инжене́рное де́ло, инжене́рия (от фр. ingénierie ← от лат. ingenium — «искусность» и лат. ingeniare — «изловчиться, разработать» — «изобретательность», «выдумка», «знания», «искусный»[1]) также инжене́рная де́ятельность, инжене́рно-техни́ческая де́ятельность, инжене́рное иску́сство — область технической деятельности, включающая в себя целый ряд специализированных областей и дисциплин, направленная на практическое приложение и применение научных, экономических, социальных и практических знаний с целью обращения природных ресурсов на пользу человека[2].
исходя из него я могу программировать не "на пользу человека". И получается я не инженер.
Мне просто нужен ответ на вопрос "что не является инженерной дисциплиной по мнению автора ориг. коммента?", пусть приведет пару примеров и я притяну их к инженерии так же как он пртягивает к ней все подряд включая программирование. Потому что то чем он занимается это софистика.
исходя из него я могу программировать не "на пользу человека". И получается я не инженер.
Получается. Вообще-то никто нигде и не утверждает что любое программирование это инженерное дело. Что в общем-то относится к любым "разновидностям" инженерного дела. Если кто-то что-то паяет, то он тоже совсем не обязательно инженер-электротехник :)
Ну а вы вместо того чтобы демагогию разводить можете просто посмотреть перечисленные там отрасли. А точнее: https://ru.wikipedia.org/wiki/Программная_инженерия
пусть приведет пару примеров и я притяну их к инженерии так же как он пртягивает к ней все подряд включая программирование
Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято. Причём уже давно. Не особо понимаю что вас в этом не устраивает.
Какйо смысл тогда в утверждении "инженер программист" это инженер?
Не особо понимаю причём здесь это и откуда вы вообще взяли это "утверждение".
Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято
"software engineering это инжинерное дело" - тавтология
Ну так это у вас проблема с тем чтобы относить программирование/software engineering к инженерному делу. Не у меня.
Вы что то запутались в двух соснах. Так ВСЁ программирование это инженерное дело или только software engineering ?
Во первых я же уже выше написал:
Вообще-то никто нигде и не утверждает что любое программирование это инженерное дело. Что в общем-то относится к любым "разновидностям" инженерного дела. Если кто-то что-то паяет, то он тоже совсем не обязательно инженер-электротехник :)
Кроме того если кто-то где-то скажет что условная механика это инженерная профессия, то по вашему это будет означать что все кто занимаются механикой автоматически инженеры?
Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.
Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы
А в каком месте печатный станок избавил от интеллектуальной работы? Избавил от тупой работы. Интеллектуальной даже прибавил (ответственности) - там, где при ручном переписывании ошибка оказывалась в одном экземпляре, при печати тиражировалась на сотни-тысячи-миллионы.
А в каком месте печатный станок избавил от интеллектуальной работы?
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.
Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.
Печатный станок дал возможность большему кол-ву мнений (и авторам-интеллектуалам) доходить до широкой аудитории (Реформация, просвещение, национальные революции и т.д.). И как любое массовое производство снизил стоимость и требуемую квалификацию. Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве, говорю как специалист издательского дела))
где при ручном переписывании ошибка оказывалась в одном экземпляре
Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)
Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве
Да, только образован он получше среднего средневекового монаха-переписчика :)
Сейчас сеньорский скил кажется дешевеет стремительно.
Да, только это ведь не уровень интеллектуальности данной деятельности снижается, а общая планка повышается.
код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель
Если это одноразовый мусор, то да. В чуть более долгосрочной перспективе нагенерённый код, вероятно, и для пользователя окажется неприемлимым - найдутся и баги и дыры и нестабильности. Сейчас нет проблем без знаний как растирать минеральные пигменты для красок, сфоткать Лизу дель Джокондо и распечатать на струйном принтере. Займёт минуты. Через пару лет выцветет.
А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок
Ну, что касается этих сказаний, то там и ошибок и описок и отсебятины - море (это к вопросу о квалификации переписчиков) просто канонизирован только один вариант. Вот, вам и "отзыв тиража" - анафема на остальные варианты ;).
Автор неявно исходит из того, что нас не ждут никакие новые революции в ИИ.
Я бы просто посоветовал пропустить нынешний раунд хайпа и продолжить следить за появлением новых технологий.
Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют. По сути это новый уровень поиска с агрегацией, анализом и генерацией ответа.
Зато нас точно ждут проблемы из-за потери контроля над кодом. По сути в статье это и описано. Например, когда мой код косячит, то практически в 99% могу предсказать где этот косяк. Потому что код писал сам и знаю его структуру особенности, нюансы и вообще все о нем. А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Но с предложением следить дальше полностью согласен. Тем более что нам ничего другого не остаётся. Лишь выбор откуда смотреть. Изнутри или снаружи.
Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют.
Занудства ради, БЯМ - это и есть именно то, что мы называем термином искусственный интеллект, в соответствии с распространёнными его определениями. Просто некоторые люди ошибочно считают, что называться термином "искусственный интеллект" имеет право лишь нечто, как минимум, эквивалентное по возможностям интеллекту человеческому, но только сделанное из деталек. Но это не так, требования к ИИ куда более простые, он должен лишь имитировать некоторые аспекты интеллектуальной деятельности, с чем БЯМ прекрасно справляются.
Нет.
Интелле́кт (от лат. intellectus «восприятие»; «разуме́ние», «понимание»; «понятие», «рассу́док»[1]) или ум[2][3] — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой
(Ц) википедия
Почти ничем из этого LLM не обладают.
Это пока и те, которые уже публичны.. :)
Да. Искусственный интеллект != интеллект.
Искусственный интеллект - комплекс технологических решений, позволяющий имитировать когнитивные функции человека (включая самообучение и поиск решений без заранее заданного алгоритма) и получать при выполнении конкретных задач результаты, сопоставимые, как минимум, с результатами интеллектуальной деятельности
Всем этим LLM обладают
Вёл недавно разговор с "умной" колонкой и не смог получить ответ, как вяжется отсутствие психики у ИИ, с тем что интеллект её функция по определению)
годика через два будет просадка по качеству.
А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Что с БЯМ, что без БЯМ, бОльшая часть кода была написано до человека, и да, надо как-то прочесть и понять, что за код, что он делает, и где бага. Писать код, в общем случае, давно не является сложной задачей.
>А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
На самом деле нет. Тот же claude через cursor при достаточно чёткой постановке задачи может указать места потенциально приходящие к той или иной проблеме.
Да и про понимание кода сгенеренного через LLM-тут ведь тоже зависит от того как именно пользоваться, и насколько подробно задачу ставить. Если просто впизтвать в ту или иную агенту систему текст таски и ждать что оно само как нибудь там накодит-да, будут проблемы. Если же рассказать модели что именно она должна сделать-всё намного более предсказуемо и читабелбно получается.
Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система...
Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания...
Гмм... А ведь мы это видели!
На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, продуктивнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать... https://ders.by/pp/ps/index.html
Да, речь снова про Камень! Без понимания и люди и машины обречены вести себя как дураки:
Все мы разделены Природой на два подмножества: понимальщики и запоминальщики.
Ни понимальщики, ни запоминальщики даже не догадываются о существовании друг друга!
Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ
Это если целью является создание кода, подкреплëнного теоретическими основами, но ведь нет. Вокруг капитализм, и в 95+ процентах случаях целью является прибыль, и пока прибыль есть, заказчику пофиг, какой-там код. Катастрофой будет отсутствие прибыли, вот тогда забеспокоятся, и начнут искать новые подходы.
Но если кодовую базу совсем запустить, то со временем начнут стрелять проблемы. Time to market (TTM) бизнесу всегда важен, а с плохой кодовой базой TTM будет проседать. Исправление проблем в одних местах будет создавать проблемы в других. Там, где хватило бы двух разработчиков, придется держать команду в 20.
ну кстати это одна из причин почему часто корпорации переписывают некоторые продукты с нуля - так дешевле обеспечить ТТМ по фичам и не закапываться в рефакторинг того г-на который накропали в прошлой итерации
==
ну не забывать надо то что писать качественный код сразу - это снижать ТТМ при первом выходе на рынок, когда конкурент на коленке собрал чтото и оно работает..а у вас еще архнадзор деплой не пропускает
Никогда такого не было, и вот опять снова.. на память Стругацкие "Понедельник начинается в субботу":
-"Нам нужен программист". Внезапно сказал тот, что сидел справа.
-"Программисты сейчас всем нужны". Ответил я.
-"Вы не поняли. Нам нужен отличный программист". Поддержал разговор сзади.
-"Ну .. это вообще дефицит". Парировал я.
:)
Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта? Те же LLM-GPT - это больше предмет для скандалов и споров, чем требование современности. Даже эта статья, опять о проблемах использования ИИ в программировании.
Не пришло ли время здорового soft-консерватизма? Законсервируем новые разработки, и перепишем винду на ассемблере. Вообще все на ассемблере перепишем.
Ну а как "прекратить писать новый софт"? Сказать конкурентам - не пишите похожее, я сам допишу и будет все классно?
Проблема не в коде, проблема в капитализме. Это нормально, когда все-что-угодно "а за деньги да", и что при этом создается тонна хлама, часть из которого чуть более, чем полностью вредна, и еще бесконечная масса однотипных и околоодноразовых поделий. То есть именно это и есть основная масса продуктов.
Мне нередко снится один и тот же сон. Что мол прилетают пришельцы на планету Земля, и думают, чтобы такого тут сделать, чтобы люди никогда не стали им потенциально опасны. И дарят им идею Интернет. Вообще, чем он хорош, думаю понятно, но чем он плох тоже предельно очевидно, и вот интересно, как пошли дела у нашей планеты, в мультивселенной, где Интернет почему-то не эволюционировал/не прижился.
И дарят им идею Интернет.
+
Проблема не в коде, проблема в капитализме.
Ну действительно же — Интернет и программирование — это же просто технологии следующего строя. Поэтому текущий их не может использовать нормально, и просто гадит.
Если вы посмотрите локусы следующего строя — OSS, то там вполне хорошо и с программированием, и с Интернетом. Когда люди делают для себя, появляются прекрасные TUI интерфейсы, замечательные сайты с минимумом спама.
Кстати, туда же, в технологии следующего строя, относятся всеобщее образование, всеобщее здравоохранение. Просто мы сейчас живём в эпоху Реставрации.
Вы упустили одну базовую лемму программирования: Главный недостаток любого кода - то что он написан не тобою. Следствие в бизнесе: главный недостаток любой программы - она не твоя, а конкурента.
Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта?
Надо было сразу с козырей заходить - зачем нам столько дистрибутивов Linux?
Мы же не умерли год-два назад, с тем набором софта который мы тогда имели.
"Мы" и двести лет назад не умерли с тем набором технологий, который имели. И 2000 лет назад не умерли. Ну как вид. Так что теперь НТП не нужен?
И кстати точно так же "год-два" назад люди вполне себе умирали потому что современные технологии не позволяли их спасти. А завтра кто-то напишет код, который мог бы кого-то из них спасти.
Это где-то в мире розовых пони. Сейчас после 35 не берут на работу, всем подавай молодых рабов, авось разберутся вместе с нейросетями.
У меня куча коллег-погромистов старше 45-50, со всякими PhD и подобным. Да и я уже не молод :)
Так что нет, не везде так.
Тут очень многое от контекста зависит, где, куда, кем, итд. Но конкуренция на рынке труда серьезная, в связи с LLM. И тут еще неизвестно, кому проще, кому после 35 или кому до, поскольку они легче заменяются ИИ.
Почитаешь, сразу захочется в сеньоры. Жалко, что никто не возьмёт. Надо медленно пройти все уровни. А... так.. теория... Что может быть интереснее построения теории кода?
разработчики, высшей квалификации, ну или хотя-бы "выше средней" (middle+), возможно, ещё и нужны, но далеко не все, а только те, кто умеет проходить hr-фильтры.
если человек с опытом не умеет проходить фильтры (ну или случайно не смог, что равносильно отсутствию навыка), а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr.
а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr
Эйчары людей на работу не берут. Эйчары, это просто первичный фильтр, понравиться которому, конечно, полезно просто для того, чтобы не улететь в корзину на самом первом этапе. Но вот поспособствовать трудоустройству эйчар не в состоянии.
Промпт в ChatGPT:
"прочитай статью по ссылке https://habr.com/ru/companies/ruvds/articles/924616/и предложи свой комментарий"
Ответ:
Мои мысли
1. Полностью согласен с подходом
Вы, как крипто‑энтузиаст и поклонник минималистичных архитектур, точно подметили бы: без чётких ментальных моделей быстро возникающие компоненты (особенно сгенерированный ИИ‑код) ведут к архитектурным пузырям — видно снаружи, но непонятно, как это устроено внутри.
2. Уместное использование ИИ
Использовать LLM можно, но только как ассистента для шаблонов — бэкенд‑скелет, boilerplate, тесты. При этом senior должен:
Разобраться в сгенерированном коде,Адаптировать его под свою доменную логику,Убедиться, что он сочетается с остальной системой.
Это прямо перекликается с вашими принципами: функциональный, ясный, минимальный код управляется человеком, а не ИИ.
3. Практики для поддержки теории
Автор предлагает:
Документировать не реализацию, асмысл: зачем этот компонент, какие компромиссы были.Через code review обсуждать не просто «исправь стиль», а «как это отражает модель?».Наставничество — именно как вы делаете: делиться пониманием, не только синтаксисом.
Эти практики стоит применять регулярно — в виде архитектурных сессий, обсуждений trade‑off и прототипов — в командах, где есть пулы джуниоров.
Правда там прослеживается влияние на контекст предыдущего общения со мной, но в целом суть такая - нейронка мнение автора одобряет ))
Перплексити:
Моё мнение: статья очень актуальна и глубока, она подчёркивает важность интеллектуальной составляющей в программировании, которая не сводится к механическому написанию кода. В эпоху массового внедрения ИИ и автоматизации именно опыт и понимание старших разработчиков обеспечивают сохранение качества и смысловой целостности ПО. Это важное напоминание индустрии о том, что технологии — лишь инструменты, а основа успешной разработки — человеческий интеллект и теория.
Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта.
Прям "Закон Мура" какой-то.
Сразу можно проблему обозначить - количество разработчиков растет, а суммарный IQ остается постоянным.
Несмотря на то, что хорошая документация, запись архитектурных решений и чистый, разборчивый код всегда кстати, всё это лишь слова, которые не могут полноценно отразить то, чем наши программы являются, что делают и какой смысл несут.
Я бы тут слегка поспорил. Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.
Да, текст ограничен и не тождественен заложенным в него мыслям. Но в этом есть и положительный момент: необходимость выразить неограниченный полёт своей фантазии сухим языком технического текста (или кода) дисциплинирует и ограняет мысли. Не можете оформить свою мысль кодом или объяснить, что ваш код делает, значит, сами до конца не понимаете, есть смысл остановиться и подумать, а не подгонять по месту напильником.
Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.
Зачем нужны учителя, преподаватели, если есть книги?
Чтобы не одичать
Зачем нужны учителя, преподаватели, если есть книги?
Затем же, зачем нужны комментарии, если есть код.
Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».
Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».
То есть, комментарии частично описывают программу на языке, отличном от языка реализации (поэтому неизбежно со слегка другой стороны). Как статические типы. :-) Такое частичное дублирование. :-)
Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться
Зачастую, текущее поколение крудошлепов и рестоделов, поражденное успешным прохождением литкода, о модели и теории банально не задумывается, а пока эффективные менеджеры дойдут до старика брукса, которые выросли из этих же растоделов и крудошлепов сократят не одну сотню сеньеров.
И со своей стороны хочется доучить Си и С++ и уйти писать что-то системно продуманное, нежели, чем ломать голову об очередной модели в обычном продукте, где зачастую о дизайне никто не заморачивается.
Когда проект загнивает, то тушат джунами и/или деньгами, перематывая изолентой хибернейт, спринг веб, JPA и прочие аббревиатуры.
Безусловно есть оч. крутые спецы с богатым опытом, обширными знаниями и умением создавать продукты как с бизнесовой стороны, так и с технической, но на фоне общей массы они незаметны.
P.S. я не против фреймворков и тулов - это прекрасные инструменты в своих нишах, но если кругозор ограничен исключительно фреймворками, то точного технического решения не получить, т.к. где-то да и придется сделать свой велосипед.
Также я считаю полезным решать литкод, но это всего лишь небольшая часть из разработки.
Современный мир разработки всё ближе к серьёзной катастрофе. В чём конкретно это выражается?
В бездумном использовании джунов, которое уже стало нормой. Разработчики инстинктивно обращаются к написанным студентами-джунами решениям, не прилагая никаких когнитивных усилий, без которых получить должное понимание невозможно. Как я уже писал, это «бездумное использование джунов» лишает нас возможности роста.
В генерации беспредметного кода. Здесь всё ещё печальней. Создаваемые джунами программы не просто лишены фундаментальной теории, но и вовсе являются безличными.
В проблемах интеграции. Когда разработчики принимают написанный джунами код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения.
Если подумать, ИИ мало что изменил в процессе. До него был класс работников, занимавшихся копипастом со stackoverflow, теперь эта работа автоматизирована. Риски подхода сохранились и масштабировались вместе с самим подходом. Раньше бизнес игрался с заменой дорогих сеньоров на дешевых джунов из развивающихся стран и терял контроль над кодом; теперь потерять контроль над кодом можно еще быстрее и дешевле.
С другой стороны, статья похожа на взаимное самоуспокоение сеньорствующих, которые несколько напуганы движухой. Если предыдущие серебряные пули в виде RAD, микросервисов, Scrum еще можно было принимать, закатив глаза, и ждать, пока труп очередной метододогии проплывет мимо, то в этот раз "оппонент" определенно силен.
Ну вот автор затронул очень важную деталь, но никто не собирается ее обсуждать, точнее предлагает системный выход.
Жесткая регламентация на базе Институтов Стандартизации. Уровни, протоколы.
В тему промт для veo3: Возможно что скорость развития моделей будет нарастать быстрее (или просто будет быстрее), чем рост проблемы, и мы можем не дождаться когда синьоры будут выпущены и очищены от пыли, из старого шкафа, захламленного подвала, заброшенного здания. Уверен синьоры серьёзные люди и сами выйдут на свет новых обстоятельств, накинув лассо на дикого робомустанга пролетающего по новому хайвею рядом с этим зданием.
Спасибо за статью. Давно хотела увидеть мнение по поводу использования ИИ программистами и на сколько вообще ИИ может заменять начинающих прогеров и есть ли смысл вообще мне, скорее как пользователю python, чем разработчику развивать свои навыки в кодинге или ИИ-инструментов достаточно для решения моих задач. Замотивировали на дальнейшее освоение программирования. Благодарю!
Давно хотела увидеть мнение по поводу использования ИИ программистами и на сколько вообще ИИ может заменять начинающих прогеров
Вы так пишете, как будто многих тысяч и тысяч статей на эту же тему, порой с диаметрально противоположными мнениями, постоянно выходящих в течении последних трех лет, и не существовало :)
Очень интересная статья. Спасибо автору!
Крайне актуальная тема поднята. Особенно с моей перспективы джуна бекендера/стажера, ведущего сейчас свой первый проект, так еще и в лице младшего тим лидера(Проект на Python, WEB разработка на DRF).
Действительно, ребятам просто не хватает осознанности и это было сразу понятно, когда после утверждения ТЗ нашего проекта никто даже не показал заинтересованности и желания быть активным в разработке. Удивительно!
Раздал и расписал пошаговые таски так, чтобы если непонятно - можно скормить ИИ и он выдаст рабочий код. В какой-то момент понял, что так будет проще, чем "обучать" их тому, чему они уже обучились...вроде как. Сейчас вообще пришел к тому, что выполнить некоторую работу проще самому, чем объяснить стажеру и выдать таск. Я тоже использую ИИ, ибо приходится использовать инструменты, которым меня не обучали или о которых я вообще услышал впервые. Но прежде, чем использовать то, что выдает ИИ, обязательно ознакамливаюсь с официальными документациями, смотрю инфу на форумах и пытаюсь максимально понять и осознать, насколько подходит мне тот вариант решения, который мне предлагает ИИ. Чаще всего - чушь полнейшая.
Не хочу жаловаться, ибо то, что я делаю - важно для моего будущего. Это очень крутой проект, который я не могу позволить себе упустить из-за тимы раков. Лучшее, что я могу сделать - это вытянуть проект, вытянуть всех ребят, защитить проект и получить бесценный опыт.
Программирование как разработка теорий: почему senior-разработчики стали ценны как никогда?