Под моей статьёй про работу с Codex отметились "специалисты" от IT, которые объяснили мне, что я ни хрена не понимаю в программировании. Очень рад за них. Сегодня у меня конкретные примеры из жизни с такими специалистами и пару вопросов.
Сразу вопрос: как получается, что практически те же люди, которые рассказывают мне про программирование, на том же сайте спрашивают, где это я в России видел зарплаты выше двухсот или трёхсот тысяч рублей? Ну просто если Вы настолько умны и круты, ну не пишите плиз что в России нет таких зарплат. Ну я больше четырёхсот тысяч на руки в месяц получал ещё семь лет назад в ИТ. А двести тысяч на руки мне предлагали в Москве в 2011 году, когда я ходил по собеседованиям. Причём предлагали в нескольких конторах. На мой взгляд, люди, которые готовы были платить мне такие деньги из своего кармана, имели некоторое представление о моей квалификации. Только еще раз отмечу: я себя не позиционирую как программиста и разработчика. Платили мне не за это.
В «Сахалинской энергии» я работал и ведущим специалистом, и руководителем сектора. Кому интересно, это легко проверить, у меня в конце концов запись в трудовой книжке есть. В нашей компании процентов девяносто жителей города хотели работать. Кто жил в Южно-Сахалинске поймет о чем речь. У наших айтишников зарплаты были одними из лучших в городе, и с подбором людей у нас была довольно приятная ситуация. В мой отдел на позицию специалиста как то взяли руководителя департамента из банка, у которого до этого было больше 20 ИТишников в подчинении. Зарплата у нас была хорошая и соц пакет.
Человека обычно сначала брал к себе подрядчик (не всегда как с бывшим руководителем департамента из примера выше). Он работал на наших проектах, мы видели, что ему можно поручить, сколько времени у него это займёт и что он в итоге сдаст. Потом, когда у нас освобождалось место, мы уже знали, кого хотим к себе забрать. Напрямую с рынка брали редко. Так как текучка минимальная - освобождения любой позиции ждали годами.
Казалось бы, при таком выборе какие вообще могут быть сложности с поиском толкового программиста? Так вот, сложности были.
Возьмём тот самый SharePoint, про который я писал. Когда я пришёл руководить сектором, его уже внедрили, лицензии оплатили и всякого говна на нём успели наделать до кучи. Сам я бы это говно от Microsoft у себя ни за что не внедрил, но меня на тот момент никто и не спрашивал. Два программиста тоже достались мне в наследство. Оба начали заниматься SharePoint уже после того, как его внедрили. Руководителя того проекта, кстати, впоследствии дважды понижали в должности. Он остался на позиции главного специалиста и был самым опытным разработчиком в этом самом шарепоинте (и не моим подчиненным. То есть руководить я им не мог. Только согласовывать). А нам оставалось работать с тем, что купили. Обосновать покупку другой платформы, когда за эту уже заплачено, я даже не пытался.
Менеджеры Microsoft, в том числе через Softline, регулярно пытались продать мне ещё и их Teams и другие облачные сервисы. Я их динамил, в частности ссылаясь на вопросы по персональным данным и 152-ФЗ. Мол ни одного сервера Microsoft в России нет и перс данные в нарушение российского законодательства будут храниться за границей, что недопустимо. Мне объясняли, что данные за границу передаются в зашифрованном виде и на зарубежных серверах тоже лежат в зашифрованном виде. Я говорю, ребята, не гоните. Я ведь могу приехать за границу, зайти в свой аккаунт и прочитать переписку, которая лежит у вас на сервере за границей. Какая нахрен трансграничная передача данных?!!. Что вы мне тогда рассказываете про шифрование при передаче? Правда, я бы с удовольствием воспользовался возможностью отдать предпочтение российскому разработчику. Правда, ничего путного из российских решений под эту задачу я тогда на рынке не нашёл. Один из начальников отдела на очередном совещании сказал как то: блин, мы тут все такие патриотичные но в очередной раз внедряем иностранный софт. (и это была текущая реальность).
Теперь про задачу, которую привожу в пример. Нам понадобилось перенести в SharePoint учёт инцидентов по безопасности. По части программирования задача довольно простая. Несколько связанных таблиц, справочники, уведомления по почте (уведомления настроены в SharePoint). А для производства вещь серьёзная, потому что речь шла о заводе по сжижению природного газа. Пожар на СПГ-заводе, если кто не понимает, это п***ец. Это, если что, техногенная катастрофа. Катар не даст соврать.
По самому процессу: я сразу попросил программистов сделать базовый трекер, чтобы потом можно было взять его, добавить несколько полей и получить следующий трекер уже для другой задачи. Условно поля на память: дата начала, срок, критичность, название, описание, ответственные есть в любом трекере. Вот это и надо добавить в базу.
Процентов сорок, а то и пятьдесят всей мелкой разработки (small development) в нашем секторе приходилось на такие задачи. Менялось то, что надо учитывать, менялась часть полей. А трекер нам всё равно в очередной раз предстояло делать. Вот чтоб не заниматься этим дрочевом нужно было стандартизировать работу и в дальнейшем на одной базе уже хреначить всем эти самые трекеры.
Вроде как для меня крайне прозрачная задача. Но я сразу сталкиваюсь с тем, что наш главный специалист по SharePoint (а он типа выступает архитектором для моего программиста) начинает меня динамить и всячески от этого отказываться. Я был уверен, что он решил "этого выскочку на место поставить". Меня в смысле. Ок. Перед вторым совещанием я отдельно поговорил с другими участниками проекта. В том числе привлек двух наиболее опытных и грамотных программистов в компании. Реально начал даже в себе сомневаться в какой то момент, но один хрен разобрались. Со всеми по постановке задачи у нас взаимопонимание. Устраиваю общее большое совещание. В том числе с начальником начальника этого специалиста (благо уже грамотного Айтишника). Выяснилось, что, кроме этого ведущего специалиста, все понимают, зачем нам нужна общая основа. Ему ещё раз объяснили, договорились и с ним. Решение я записал в протокол, протокол разослал всем участникам и приложил к материалам проекта. Когда мы сдали трекер инцидентов, почти сразу встал вопрос о разработке следующего. Я говорю, ну тут у нас всё готово, база есть, добавим пару полей, и будет нам счастье. А программист мне отвечает, что базового класса нет. Разбираемся - реально нет. Он проигнорировал ТЗ, согласованное до этого. (Признаю мою вину на этапе разработки что я не проконтролировал, но мне мои программисты дали некорректный ответ. Они посчитали что база сделана. Я сам в потроха не полез да и не шарю в этом шарепоинте и не моя это задача. В общем классика. Но у меня головняка и без них было в тот момент куча. Запиши в ТЗ, проверь и еще раз перепроверь. ТБМ)
После долгих препирательств до меня дошло, что наш ведущий специалист в принципе не понял, зачем я просил сделать базовый класс (базовый трекер). Трекер инцидентов работает? Работает. Он считает что все ок. А то что для следующего, получается, опять надо делать то, что мы только что делали несколько месяцев его уже не особо то и интересует. И вот этот человек тоже получал сильно больше чем получают по рынку. В компании, которая могла выбирать практически из всех айтишников города и имела возможность посмотреть на большинство кандидатов в работе задолго до того, как предложить им место.
Я к тому моменту начинаю анализировать другие его поделки и у меня волосы встают дыбом. Я то думал он меня динамит и пытается дискредитировать или просто саботирует мой проект. А он оказалось тупо не шарит. В частности, был сделан им календарь для руководства компании. Всем понравилось - все классно. Говорят: нам для продакшена такой же нужен. ЧТо он делает ? Он (ТБМ) копирует и делает второй точно такой же проект (второй был до меня). Я его поймал на том, что его попросили сделать трекер для СПГ завода. Он уже успел сделать проект, благо не сдал его. ОН для СПГ завода делал точную копию предыдущих двух разработок.
То что секретарю директора СПГ завода потом надо было вносить рабочий календарь в ТРИ (!!!) системы его не смущало. (директор СПГ завода входит в руководство компании и в руководство продакшена, то есть попадает в оба предыдущих трекера). ТБМ, ТБМ, ТБМ. Мол попросили же быстро сделать. ну я и делаю.ТБМ. А то что этот календарь правильно вообще то было сделать по производственному табелю ему вообще даже не мыслимо. Вы как это потом поддерживать гавно собираетесь ? !! Когда сделаете 20 календарей и надо будет вносить изменения? - "...Я чет об этом не подумал...". А то что секретарь как обезьяна будет в три календаря информацию вносить (и гарантировано появятся расхождения и не только у секретаря директора СПГ завода и у остальных ...)? - "... ну я об этом не подумал...". То что надо тупо доработать базовый календарь и все делать в одном приложении ему даже в голову не пришло. И это прошу заметить ведущий специалист. Вернее ГЛАВНЫЙ.
Сейчас уже не помню, но я и в других его проектах такие же проблемы сразу раскопал. Меня тогда это закусило, но начальник этого "специалиста" не отдупляет вообще о чем я. А вот уже начальник начальника мне говорит: "Да я уже ТБМ с ним! Зря думаешь его что ли дважды понижали?!! Чо делать? Давай его уволим?!!" - "...твой сотрудник, делай что хочешь...". Но я его буду гнобить за его косяки. А их до хрена. Ок - гноби. Прошу заметить: зарплата, отбор и т.д. А на выходе имеем просто ... ТБМ. Я сейчас даже когда пишу - материться начинаю. Хотя прошло уже 6 лет.
Когда я пишу, что полтора месяца поработал с Codex и оцениваю его стартовый уровень выше, чем у программистов, которые делали мне этот трекер, работали по контракту, те с кем я работал в свое время в консалтинге, я имею в виду вполне конкретных людей. Я им ставил задачи, согласовывал решения и принимал у них работу. Также как у Кодекса. При этом кодексу вообще похрен на чем писать. А наши программисты обычно знают очень короткий стек технологий.
В предыдущей статье я, между прочим, подробно описал, как сам Codex поменял мне архитектуру и сколько времени у меня ушло, прежде чем я понял, что он натворил. (от трех до пяти дней. Как считать). То есть у меня нет иллюзий. Только вот у меня в жизни была возможность посмотреть, как с согласованной архитектурой обходится живой ведущий специалист. Его я ещё и на два совещания позвал. И зафиксировал на бумаге согласованное правильное решение. И если вы думаете что такие претензии у меня к одному программисту - вы глубоко ошибаетесь. Помнится я просил у начальства командировку в Казань, чтоб замочить нафиг одного программиста в Казани. Обычный типовой модуль на 200 строк кода этот мудак умудрился захерачить через классы, в них осталось куча неиспользуемого кода, ненужные библиотеки, непонятные циклы и я не могу не принять это гавно, потому что "оно ж работает". В ТЗ и в договоре нет понятия "нормальный код". Когда пришло время внести правки в модуль, вместо обычных 15 минут у меня это заняло пол дня, потому что написано коряво было и внести правки было мне лично непонятно как. Ну там вместо обычных 200 строк кода была несколько тысяч, какие то циклы непонятные и т.д. Вот тогда я и просил командировку.
Есть старая шутка, что если бы водители устраивались на работу примерно так, как программисты, то в резюме бы писали:
- умею ездить на всех типах автомобилей
- умение выйти из аварийных ситуаций без царапины
- экстремальное вождение
- участвовал в гонках формулы один
- испытания новых типов автомобилей
- чемпион мира
- и т.д.
У нас и с писателями в комментариях похожая история. Людей, которые нахватались профессионального жаргона и готовы объяснить, как надо писать, я встречал много. На сайте афтершок в том числе таких в комментариях уйма. С программистами мне такое попадалось регулярно. Пока человек рассказывает, что он умеет, всё звучит убедительно. Проверить это мне обычно удавалось потом, когда приходило время забирать у него работу. По комментарию от 4orever видно что это опытный матерый программист. Просто людей, которые считают себя хорошими программистами, я за двадцать лет в IT встретил гораздо больше.



Комментарии
Мир корпоративного программирования изменится очень сильно - это факт.
Их и раньше индусы вполне устраивали, тем более сейчас они полностью перейдут на ИИ - хотя бы из-за иллюзии суперконтроля. Плохой контроль над программистами их всегда очень раздражал.
Разработка у них полностью перестроится под ИИ. Дебагинг уйдет в прошлое, проще добавить правило. Читать код люди перестанут совсем.
И таки да - хорошие кодеры корпорациям будут не нужны, это умение будет считаться за минус.
Интересно тут только одно - насколько им сильно удастся прижать вайб-кодеров по зарплате и прочему.
PS.
Не важно лучше ли ИИ в конечном счете обычных программистов или хуже. У корпораций другие приоритеты
Не думаю, что роль программистов упадет в корпоративном секторе. Скорее наоборот, вырастет. Все больше будут задач передавать ИИ, и все больше будет требоваться грамотная постановка задачи.
Да спадет нагрузка на код, но станет больше задач на постановку задачи.
Я по нам вижу: фактически, растет нагрузка на архитекторов и аналитиков. Причем аналитики все больше требуется как full stack (БА + СА).
Т.к. постановка задачи на ИИ требует подхода doc first - то те, кто с этими документами работает, получают приоритет
Нет, не требует. Вы можете написать запрос на пару абзацев, а ИИ его развернёт, превратит. спецификацию, проведёт эксперименты и так далее.
Зачастую дешевле и проще сделать прототип (или даже дюжину), перед тем как написать окончательный документ.
А смотреть на код вообще нужно начинать только тогда, когда прототип работает: зачастую код ужасен, иногда вообще приходится выкидывать его и начинать писать всё заново — но вы уже знаете, на этом этапе, что вам таки реально нужно… обычно doc first упирается в то, что заказчик очень редко имеет хоть малейшее представление о том, чего он хочет, обычно вы долго всё согласовываете, делаете — а он потом на это смотрит глазами невинного оленёнка и говорит, что вы забыли дюжину “очевидных” вещей, про которые он даже не подумал вам что-нибудь сказать, так как думал что “все про них знают”.
Нет в тз- отличный повод для увеличения сметы :).
Еще ест тз на тз
Да, но нет.
Потом править будет дорого и стоить очень много токенов.
Ну... там получилось с точностью до наоборот... люди думали, что это ИИ им кодит, а оказалось - толпа индийских программистов...
Не скажу, что это стало прямо трендом, но показательное видео... В перспективе и инфобезопасностью, причем не такой уж и дальней также будут заниматься специализированные ИИ-шки..
Но то, что нейронки серьезно сместили акценты в IT буквально за последние пару лет и многие потеряли работу и не могут найти другую в данной сфере - это факт..
Имхо.
https://youtu.be/x8doDrDNBcU
00:00 Введение
• Руслан, 33 года, работал фронтенд-разработчиком 6,5 лет.
• Сокращён из-за искусственного интеллекта.
• Более 4 месяцев не может найти работу, отправил более 1000 откликов.
00:31 Путь в IT
• Руслан — программист-самоучка, с детства мечтал стать разработчиком.
• Работал в компании с демократичным коллективом и отсутствием давления.
• До IT работал механиком в троллейбусном депо.
02:26 Изменения на рынке труда
• На LinkedIn много людей ищут работу, многие ищут по 8 месяцев.
• Рынок перестраивается, программистов становится меньше из-за нейросетей.
• Работа разработчиком изменилась: теперь много работы выполняют нейросети.
04:17 Решение стать курьером
• Руслан ищет свободу и ментальный комфорт в работе.
• Не хочет работать в условиях давления и конфликтов.
• Курьерство кажется ему вариантом с большей свободой.
05:08 Альтернативные вакансии
• Рассматривал вакансии слесаря и работника склада, но они не подходят из-за атмосферы и условий труда.
• Работа на складе ассоциируется с рабством и отсутствием карьерного роста.
07:19 Карьерные планы в курьерстве
• Планирует начать с работы на электровелосипеде, затем перейти к мотоциклу и машине.
• Рассматривает возможность работы в такси или дальнобойщиком.
• Стремится к постоянному развитию и чувству движения вперёд.
08:59 Подготовка к работе курьером
• Заказал нагрудную камеру для создания контента о курьерстве.
• Необходимые вещи: электровелосипед, дополнительный аккумулятор, тёплая одежда, багажник, телефон, гофры, зимняя резина, шлем.
• Готовьтесь к возможным поломкам электровелосипеда и необходимости самостоятельного ремонта.
10:35 Опыт с электровелосипедом
• Купил электровелосипед на Авито, столкнулся с проблемой разболтанного руля.
• Продавец отказался ремонтировать по гарантии, предложил приехать в мастерскую.
• Починил велосипед самостоятельно, потратив 6 часов.
11:23 Заключение
• Призывает курьеров делиться лайфхаками в комментариях.
• Прощается с аудиторией.
У курьеров, конечно, офигенный карьерный рост просматривается! Аж до таксиста и дальнобойщика! Вангую, что и их заменят. А так же работа в жару, холод, осадки и с неадекватными клиентами (временами). Пора чинить тролейбусы.
Как говорил знакомый дальнобойщик - все мне в профессии нравилось, пока грузовик не сломался на зимнике.
Мир погромированния уже изменился. Но с сожалению количество пока не перешло в качество. Куча нейрослопа, где каждый лепит свой велосипед, который подходит именно ему по цвету, размеру колёс, размаху руля, высоте рамы и т.п. Найти что-то стоящее трудно, написать самому ещё труднее. И дело не в программирование как таковом - анализ проблемы, постановка задачи и тому подобные вещи ИИ без человека не сделает, по крайней мере пока. Но это и не работа программиста. У меня перед глазами пример директора небольшого предприятия, который "сам" сделал в клоде свою небольшую систему (веб-приложуху) для бюджетирования, учёта движения денег и обработки заявок на оплату. Раньше его(директора) хватало на пару табличек в Excel, а теперь он может делать вот такое сам. Правда, с практически готовым ТЗ, на разработку которого тоже ушло время. Под капотом в коде тихий ужас местами, местами неплохо, местами прям хорошо, но снаружи что видно пользователю - всё чики-пуки, красиво и даже удобно с мелкими правками. И обошлось ему всё это по подписке - около бакса и пару часов тупняка в чат. Большой вопрос, что будет с поддержкой этого кода на долгой дистанции, но тут больше вопросов к используемым языкам и технологиям, а с поддержкой и внесением изменений ллм сама справится вполне. Узкозаточенным программистам-кодерам точно карачун, многостаночникам/аналитикам - пока нет, для них ллм спасение от постоянно нарастающей сложности задач.
Сам постоянно теперь использую агентов, это мега удобно как ни крути, даже в небольших задачах.
Аналогично. Год назад обратился к знакомым программистам с задачей. Сказали возиться не охота. Ок. Сам сделал месяц назад за час с агентом.
Дел.
Ув. автор, не ругайтесь с программистами. Ставьте их перед проблемой, и дальше само все рассосется.
Вот например, касаемо проблемы, когда все работает, но написано плохо: надо было просто в спецификации обозначить модифицируемость. Причем это даже расписывать не надо, просто указываете в требованиях ISO/IEC 25010
Конкретно -
Вы четко пункт про базовый трекер в статье прочитали? Я специально отдельное совещание собирал, чтоб включить данный пункт в ТЗ и включил его в ТЗ!! Еще и обьяснить программисту (архитектору ТБМ) для чего он нужен).
Ну второй момент: чтоб составить правильно ТЗ - надо обладать компетенцией соответствующей. ЧТо тоже часто не просто.
Люди не из ИТ часто не очень понимают даже, какие надо вопросы задать и о каких моментах подумать
О чем и речь.
Мне публикацию видео в разных соц сетях делал программист удаленый. (Не просто публиация)
Я понимаю, что теоретически с ии сделал бы эту задачу. Но у меня ушло бы на нее куча времени, пока я бы определил правильный стек технологий и правильно поставил задачу (несколько дней пытался. Не особо успешно).
То что он гонял ИИ 99%. Но то,как он их гонял, за это и надо было заплатить.
Он и отвечал за работу.
Даже если бы ИИ накосячил.
Кроме того. держать человека на поддержке и сопровождении (любой проект изменяется и модифицируется) проще и надежнее, чем безликий ИИ,
Да, составление ТЗ дело непростое и требующее определенной квалификации и опыта. Любое требование в ТЗ в обязательном должно содержать описание того, каким образом будет проверяться то, насколько корретно оно реализовано, т.н. acceptance criteria. Это делается для того, чтобы ошибки/огрехи/баги можно было выявить как можно ранее на этапе тестирования. Причем само требование должно не допускать никакого двоякого толкования (есть и другие характеристики хорошо сформулированого требования). Это необходимо для того, чтобы не было ситуаций "я/мы поняли это так".
На мой взгляд проблема не в том, куда пойдут "крутые" разработчики - не пропадут, работа найдется, а в том, откуда возьмется смена тем, кто, на сегодняшний день, квалифицирован и востребован. На сегодняшний день "джуны", вроде, никому никому не нужны - базовые операции ИИ выполняет легко. Но как тогда становится опытным разрабочиком? Это из разговором моих коллег, СА и БА, которые говрят о том, что если что, то заменить их будет не очень просто. С точки зрения работы это, вроде, и хорошо, а с точки зрения дела - значительный рост будущих рисков.
А кто им задачи будет ставить и внедрять результаты?
Кто будет отвечать за проект?
Пушкин?
Я ведь именно об этом и пишу. ИИ, как инструмент, требует наличия квалифицированного работника для постановки задачи и контроля результата. А вот механизм подготовки квалифицированной смены, на сегодняшний день, если и не сломан окончательно, то буксует, это точно.
По поводу же ответственности за проект существует два контура - административный и технический. Там, где деньги, ответственный есть всегда. По меньшей мере - крайний ) Опять же, ИИ - инструмент, принятие управленческих решений никто не отменял.
То есть, нужен "водитель кобылы", такой шофер при ИИ.
Но что у него будет за квалификация?
Сможет он без ИИ что-нибудь делать?
Или тут нужен просто мигрант, вчерашний курьер?
Или пенсионер дома за компом?
Или мамочка в декрете?
Нет, это некорректно определение. Для эффективного использования ИИ в качестве инструмента требуется достаточно высокая квалификация. Чем выше квалификация пользователя, тем выше "КПД" использования ИИ. Сам по себе ИИ не может "делать" ничего . Необходим человек для постановки задачи и контроля выполнения. Кроме того единовременного контроля может быть недостаточно. Т.к. LLM, по сути своей, системы недетерминистские с течением времени может получитс результат который вам не подходит. Это, в первую очередь, касается задач нестандартных. Кроме того, доверять ИИ выполнения задачи без должного контроля крайне опасно и безответственно.

В случае же выполнения каких-то стандартных задач, легко поддающихся автоматизации, то да, возможно использование ИИ с минимальным "присмотром". Тут ваш список вполне подошел бы, но остаётся вопрос. А что будет, когда вам понадобится вносить осознанные изменения в процедуру работы ИИ? Дешевый "вахтер" может не справится. А вопрос ответственности?
Опять же даже быть "водителем кобылы" дело непростое. Много ли людей сейчас могут вот взять да и правильно запрячь лошадь в телегу? А её и кормить надо и ухаживать за ней надо. Да и норов у них разный
То есть, ИИ сейчас - это помощник каретного мастера из известного фильма.
Я вижу ИИ помощником врача при анализе анализов(!), геолога при анализе сейсмограмм и прочего, что они используют.
Инженеру - для поиска аналогов, дизайнеру - тут полный простор для творчества.
Программисту - нет, это дисквалификация для программиста и уничтожение профессии.
Сейчас все идет к тому, что "программистЫ" будет неактуально. Один человек может делать практически любую задачу "под ключ" - за разное время, конечно. Но суть в том, что на коммуникациях и донесении деталей идей можно ооочень много экономить.
Уже сейчас есть история с вайб CTO. Т.е. команда из маркетолога и вайбкодера-вайбадмина пилит стартап "под ключ".
В общем, узкий программист - дело прошлого. Будут продуктоделы. Вот их будут ценить. А просто программисты, тестировщики, аналитики - уйдут в прошлое.
Ну вот что-то из реальности, наконец-то. В подавляющем большинстве предприятий, сидящих на самописных, или сильно модифицированных типовых системах, ситуация примерно такая. Если у всего кода один-два хозяина, то рано или поздно они обязательно начинают безбожно костылить. Проверить-то их некому, а делать надо всегда "вчера"
Дубль вышел, но не корысти ради а ISE из-за...
Написал, если я правильно понял, специалист-управленец. "Казалось бы, при таком выборе какие вообще могут быть сложности с поиском толкового управленца?"
Много текста про дурака-программиста, ну и мимоходом (курсивом, в скобочках)
Азы любого управления - поставь задачу-назначь сроки и ответственных-проконтролируй-прими решение по результатам (премировать или кремировать
). Автор (опытный управленец, вроде как, ну по его словам) пропускает достаточный контроль и, как минимум, не рассказывает, какой эцих с гвоздями получил разраб и те, кто доложили автору "все сделано". И, скорее всего, никакого (прогеры, они ж ранимые и обидчивые как дети, даже если из просто громко кроешь гуями, а уж если премии лишаешь, так и вовсе, надуваются, затаив обиду - дети, короче
).
Дальше-больше.
и не сделал, не исполнив приказ начальства. Ну, безусловно, если бы он понимал зачем, было бы лучше. НО! То, что он решил, раз не понял, то можно и не исполнять приказ (кстати, а он вообще был? Или так, в курилке ТЗ набросали?) и это сошло с рук и, судя по изложенному, не в первый раз, много говорит о качестве управления. И я бы еще понял, если бы это был стартап прогеров-друзей пилящих очередной арканоид для мобилы, но завод СПГ, опасное производство, где ИТ - обслуживающее основной процесс подразделение чтобы так себя вел - я куей от этого зоопарка... И реакция его "начальника начальника" тоже много говорит о "какчестве управления"
Кстати, уволили? Что-то мне подсказывает, что нет
Это же стресс. Для обеих сторон, причем, ага, и для увольняющего начальника - тоже!
А сверху все это еще приправлено:
Ну тут я вижу два варианта - или это (элитная) богадельня (таких овердофига я насмотрелся), для программеров в данном случае, или в этом Южно-Сахалинске прогеры были в количестве первых десятков на весь город, тогда смысл писать "напрямую брали редко" - тупо некого было? Кстати, этот принцип найма только к рядовым сотрудникам относится?
Сам автор-то как на должность начальника попал? 
Ну, если почитать резюме управленцев (читано в товарных объемах), будет примерно то же самое:
Поднял количество сделок в 3 раза! (скинув цены в 5 раз, разорив контору, поэтому и ищу работу...)
Оптимизировал поставки и сэкономил на себестоимости продукции компании 100 млн.руб. (и "заработал" конторе 200млн. на рекламациях по качеству - но это другой отдел разгребал!)
Сократил издержки на персонал в 2 раза (уволившись сам, оставив директора одного в конторе!)
и т.д.
Ну, в принципе, в самом начале статьи автор чем-то таким и размахивает (своей прошлой з/п)
Итого - кмк, тут все стороны (прогеры vs управленцы) друг друга вполне достойны и выпячивать "заслуги" какой-то одной более чем другой оснований не имеется.
P.S.
Минейджеры MS милейшие люди и вопросы решают мягко, а то и вовсе финансово.
Так что послать их - не подвиг, ну если только в смысле - героический отказ от отката
Бывают и более другие методы работы, когда на неугодного сотрудника, ставшего на пути впаривания своего барахла его начальству строчатся письма о саботажнике и тормозе прогресса, скорее всего из корыстного интереса, да от интересных персон, типа "действительный государственный советник ... класса" - генерал же, хоть в данном контексте и свадебный
P.P.S. А Internal Server Error при попытке послать камент - это уже следствие вайбкодинга или еще происки злобных хакеров, которым героически ежечасно противостоит владелец ресурса?
Второе, конечно. Хотя, отчасти, и следствие вайб-кодинга со стороны тех, кто снаружи Internal Server
Это настолько ХАЛТУРА описана, что слов нет.
Тут, понимаешь ты, для всего ТРЁХ приложений стараешься всё стандартизировать и сделать общую базу, вплоть до стандартизации алгоритма создания пакетов, не говоря уже о.
Вот ещё раз повторю максиму моей когда то начальницы КБ: "Лучше инженер без диплома, чем диплом без инженера".
И в советские времена весьма большая часть выпускников ВУЗов получали дипломы потому что их было НЕ ЗА ЧТО ВЫГНАТЬ. Ну и отчётность в министерство никто не отменял.
:-))
Про таких Программистов и писал :)).
Тут дело не в кодерах, а в ПОДХОДЕ.
Я то не профессиональный кодер, делаю всё это в режиме хобби.
Но общий подход, заложенный когда-то, сидит накрепко в "подкорке".
Систематизация и стандартизация здесь основа.
+
Изволь. Задай лишь мне задачу: Без дела, знаешь, от тебя
Не смею отлучаться я — Я даром времени не трачу.
- Всех утопить
Тогда не надо спорить с программистами на эту тему.
+
Надо писать функциональные и нефункциональные требования к системе, как к черному ящику.
Но и это, к сожалению сложно, да и цикл идея-внедрения небыстрый. Потому в некритичных областях Agile процветает. С говнокодом.
Сервер бомбили боты с хуллиард запросов и айпи. Сервер падал. Понятно, что банить по айпи нет смысла, там надо диапазоны банить целыми континентами.
Загрузил логи в ИИ. Он их прочитал за пару секунд (мне наверно надо было бы их неделю читать). И расписал мне, кто бомбит, сколько бомбит, когда бомбит, куда бомбит. Вместе с ним решили проблему как это прекратить. Он мне написал небольшой код, который заглушил пару фильтров на сайте, по которым меня и бомбят, сказал куда код залить на сервер. И вуаля. И все это бесплатно, в бесплатной версии chat gpt. Собственно программисты больше не нужны. Ну как минимум на низком уровне. Где нужно какой-нить обходной код написать. Сам я не программист. Могу калькулятор на Паскале написать, на этом мое познание программирования кончается. Раньше мне пришлось бы искать программиста для написания кода. Так что да, ИИ победил. Со временем 50% кодеров на улицу.
Программисты программы пишу, а не обслуживают систему безопасности.
Вот если бы программисту заказали такую программу, эта программа сама бы логи анализировала и заплатки вставляла.
А тут - просто дыра в безопасности, которую ИИ помог закрыть.
Ну а кто обслуживает систему безопасности? Сетевики? Я как сетевик php не знаю. Все же эта дыра - дело рук программиста. И да, ИИ помог закрыть эту дыру, написав код.
Да нет же.
Оттого, что я знаю ПДД не следует, что я должен палочкой на перекрестке разруливать.
Для систем безопасности есть специальные программы, которые пишут и продают специальные люди.
Программисты, но другие.
Вы не понимаете это другое?
Типа вы сеньер помидор, а c палочкой джуниор чиполлино должен стоять?
А то посмотришь требования нынче к сетевикам - проще пойти курьерить. И программист, и сисадмин ,и тестировщик, и юрист и.т.д Все в одном лице. Супермен короче...
Ну слава Богу, что вы хоть сисадмина в незнании php не обвинили... Уже хорошо.
Тут нужен коробочный продукт, написанный специалистами по безопасности.
А не местные с огнетушителем.
Кодеров - возможно, программисты будут ещё более востребованы.
Как сварщики сейчас.
Потому, что их останется мало. Программистам перестанут платить, и останутся только фанатики.
ИИ выродится из-за отсутствия пищи.
Сами у себя будут учиться.
Автору поможет ИИ.
С живыми программистами ему нелегко, он их пытается ломать и переучивать, вызывая раздражение и отторжение.
Пусть лучше автор задумается - нужны ли будут такие специалисты, как он, при наличии ИИ, который и людьми в таком стиле может легко руководить.
Любопытно, спасибо.
Тут скорее более общий вопрос. Куда девать массы людей, не задействованных в продуктивной экономике?
Не так давно ответ был - Использовать людей там, где требуется интеллект. Отсюда и все призывы - становиться программистами, дизайнерами и блоггерами.
Сейчас жеж ИИ выдавливает людей из подобных сфер.
Автор справедливо указал, что потребность в программистах уменьшается.
Куда народ девать? Или мы и движемся к техноапокаллипсису, где будет постепенное плановое уменьшение народонаселения земли с заменой людей более эффективными роботами?
И кстати вот мое предсказание на будущее. Следующими будут заменять менеджеров среднего звена на ИИ. Причем массово, по всей планете.
плановое уменьшение уменьшает размер проблемы но пропорция востребованных/не востребованных в большинстве направлений не улучшится (а с прогрессом ИИ и ухудшится)
Поэтому и получается, что с сохранением текущей системы мы обречены либо на вымирание, либо на бесконечные войны.
Страницы