+ Ещё немного прогнозов от Metaculus (платформа прогнозирования научно-технических достижений)

- Когда выйдет GPT-5? Декабрь 2024 г.

- Насколько вероятна "зима AI" (заморозка всех исследований) к 2025-му году? 4%

- Будет ли первый AGI основан на глубоком обучении? 90%

- Будет ли один из первых AGI "сознательно" претендовать на наличие сознания? 70%

- Когда мы создадим "слабый AGI", сколько времени пройдет до появления сверхразумного AI? 9 месяцев

- Когда AI пройдёт IQ-тест MENSA (в мире таковых около 150 тыс. человек)? Июнь 2025 г.
Попробуйте кстати пройти, а вдруг вы действительно считанный гений?

- Создадим ли мы AI человеческого уровня к 2040-му? 92%

- Когда AI сможет писать программы для самоулучшения? 2026-й

- Будет ли GPT-5 обладать способностью автономной репликации? 22%

- Убьёт ли AI онлайн-покер? 12% (хоть это хорошо :)

P.S. Из этого всего, кстати, следует важный нюанс: гонка технологий AI между странами -- это полная противоположность гонке вооружений. При гонке вооружений одна из сторон выигрывает, а при создании AGI выигравших не будет: мир сразу захватят неорганические существа с невероятным интеллектом. Пока же топовые научные команды, конкурируя, спешат изо всех сил поскорее создать Разрушителя Миров...

На днях уважаемый Максут Шадаев сообщил, что ширится программа массового обучения программированию, и само по себе это безусловно хорошо:

- в прошлом году на курс по изучению современных языков программирования были зачислены 130 тыс. школьников с 8 по 11 класс. В этом году рассчитываем зачислить еще 140 тыс. человек...
-- количество ежегодно открываемых бюджетных мест в вузах на ИТ-специальности -- 117 тыс. Всего сейчас обучается почти 350 тыс. будущих ИТ-разработчиков и инженеров...
- на цифровые кафедры в вузах было зачислено 112 тыс. студентов...
- за время работы Школы-21 обучение прошли 25 тыс. человек, сейчас учатся еще 5 тыс...

Всего в российском ИТ работает 740 тыс. человек, и нехватка составляет 500-700 тыс. человек.

Скилл программирования по жизни весьма полезный в любом случае.

Но есть нюанс.

"На выходе мы получаем разработчиков высокого класса, которые без проблем трудоустраиваются в ведущие ИТ-компании..."

Вам в это верится? Моё оценочное суждение такое, что проблема российского ИТ совсем не в том, что не хватает 700 тыс. разработчиков, и надо готовить на всевозможных курсах всё больше и больше человек. Проблема в том, что ребят, потенциально готовых для работы в ИТ, полным полно (и число их быстро растёт), однако устроиться на первую работу джуниором без опыта сегодня крайне сложно. Причина ровно в том, что 98% компаний сейчас боятся инвестировать в развитие, в набор малоопытных ребят, в дальнейший рост которых надо вкладываться. И через сколько лет у компаний этот страх роста пройдёт, никому не ведомо.

Поэтому готовить новые и новые толпы кандидатов с прицелом "на работу в джуниоры", из которых в итоге работу находит один из ста (если не из тысячи), ну такое себе.

Сэм Альтман подался в инфоцыганы, в тему успешного успеха? :)

13(!) правил how-to-be-successful

Самая гениальная рекомендация (серьёзно), которая только была у Альтмана -- это легендарная статья "Внимание -- это всё, что вам нужно" 2017-го года, про огромный потенциал архитектуры трансформеров. Но по жизни, буквально, любому программисту важнее всего просто сам этот заголовок как лозунг.

Темплейты C++ статически утинно типизированы )))

Попробуйте помучить разные GPT в плане соответствующих примеров (и чтобы никаких тайпкастов), они совсем слабенько справляются, после неоднократных подсказок и уточнений. С таким пониманием программирования до захвата мира AI пока далеко :)

Хорошая человеческая заметка.

Нередко ребята, ищущие работу миддлом, жалуются, что не получают отзывов на резюме вообще, хотя опыт работы 2-3 года у них есть (или был выдуман :).

Лайфхак: я иногда тестирую адекватность спроса в ИТ, и публикую выдуманные резюме. Пока один из лучших результатов получается, когда я в дополнение к стандартному списку скиллов пишу, что самостоятельно с нуля написал клиент-серверный проект на 30,000 строк кода на C# с использованием MS SQL Server.
(Так то я писал и на 300 тыс. строк, но когда ставишь всего 2-3 года опыта, надо соблюдать адекватность :)

За полдня получил пять офферов. причём один был такой добрый и вкусный, что мне прям жалко было отказываться ))))

Главное тут -- чтобы вы действительно сделали проект подобного объёма, и в идеале, развивали его на гитхабе, где виден весь процесс разработки, и могли бы его быстро из докера стартануть. Очень полезно при этом понаступать на грабли, на собственной шкурке осознать ряд анти-паттернов, а потом про них рассказать.

Техдира/тимлида впечатлит именно ваш не очень удачный опыт (кто говорит, что всё было хорошо, врут 98%) + объём кода: раз вы более-менее успешно нафигачили десятки тысяч строк, значит точно сможете нормально долгосрочно трудиться.
Но 3-5 тысяч строк будет маловато.

Есть и другой лайфхак: для курсантов я выложил материал "9 крутых и необычных сайд-проектов", после которых рекрутеры будут ползать за вами на коленочках :) Они по объёму меньше, но зато впечатлительны в плане сложности. Например, написать свою среду запуска контейнера (container runtime).

Лучше всего, конечно, сделать и то, и то.

Если для того, чтобы проверить, работает ли программа правильно, нужно приложить множество усилий, то, скорее всего, она работает неправильно.

Как говорит Тони Хоар, можно написать настолько простой код, что в нём явно отсутствуют ошибки -- или настолько сложный, что в нём вообще нету очевидных ошибок (но есть множество неочевидных и ждущих своего звёздного часа).

При работе с хорошим кодом думать почти не нужно.

Сервер -- это бесконечный цикл, в котором вертятся воркеры -- по одному на каждый входящий запрос.

Традиционная разработка бэкенда по сути своей ориентирована на серверы: мы мыслим в парадигме серверов.

Однако по мере распространения безсерверных систем нам необходимо учиться мыслить в терминах воркеров.

Мой курс "Ясная архитектура" в помощь.

В Java реализована динамическая диспетчеризация, которая "сама" решает непосредственно во время выполнения программы, какую реализацию метода запускать. Узнать это с помощью статической типизации невозможно.

В чистых функциональных языках вместо интерфейсов предлагается концепция тайп-классов, рассказывал:
Тайп-классы и алгебраические структуры
Тайп-классы

Своим названием однако эта концепция только запутывает. Просто знайте, что тайп-класс имеет очень мало общего с "типом" или "классом".

Если интерфейс в языках ООП говорит "этот класс может выполнить этот метод", то тайп-класс говорит, что "существует нечто, что может выполнить этот метод на этом классе" (где понятие класса совсем абстрактно). Интерфейс обычно "прошивается" в коде в заголовке класса, а экземпляр тайп-класса существует как отдельная "физическая" сущность -- реализация метода не привязывается к "классу рантайма". Компилятор вытаскивает нужный экземпляр тайп-класса, основываясь на эксплицитном типе в исходном коде, а не на конкретном типе во время выполнения. Этот подход конечно не так гибок, как динамическая диспетчеризация в ООП, но имеет то безусловное преимущество, что просто посмотрев на код, мы можем точно сказать, какая реализация метода будет выполнена.

Да, но как тогда мы можем рассуждать о коде в Java на третьем логическом уровне, если не знаем точно, какой код будет выполняться? На помощь приходит принцип подстановки Лисков (точнее, его идеология). Подробнее эту тему разбираю для курсантов в материале "LSP с т.зр. ФП".

Вкратце, абстракция LSP гласит: разработчик! не удивляй своих коллег! )))

То странное чувство, когда увидел, что питон -- лидер функционального программирования... действительно, почему бы и нет.
(а хаскель вообще не видать на горизонте)

Кстати да

В 90-е знакомый ставил банкам "опердень", который переставал работать через 90 дней, если ему не заплатили. Один банк не заплатил, а на 91-й день к нему приехали суровые пацаны с разбитыми кулаками, и жёстко потребовали, чтобы опердень у них быстро заработал. На его возгласы что не заплатили, они сказали, что это твои проблемы, решай с бухгалтерией.
Пришлось запускать...

Через несколько месяцев этот банк к нему уже вежливо обратился с просьбой обновить на новую версию, сделать доработки, ну он запросил двойную цену, и те согласились.

А потом на этот рынок пришли взрослые интеграторы-автоматизаторы, и это уже совсем другая история (разборки были на порядок круче)...

90% правильного программирования -- это молчаливое думание.

LLMs эффективно убивают своих оппонентов, мастерски обманывают других, создают тщательно продуманное алиби и перекладывают вину на других. Речь про игру Hoodwinked, напоминающую Мафию, статья университета Южной Калифорнии. Это в тему странных споров, сможет ли грядущий AI, умнее нас в 100 раз, обманывать человечков ))) уже.

Вы можете поиграть в Hoodwinked по ссылочке из этой статьи.
Напомню, что интеллект AI в конкретных задачах потрясающий: в Go (значительно сложнее шахмат) AI научилось играть на топовом уровне за три дня, просто играя миллионы партий само с собой. И, пока по слухам, мета обещает выложить грядущую GPT-5 (лламу-4 ?), которую можно крутить локально, в опенсорс (я только за :).

Shane Legg (Google DeepMind's Chief AGI Scientist) даёт 30% вероятности, что AGI (сильный ИИ) появится в ближайшие 3 года. И даже главный AGI-скептик Gary Marcus даёт 35% шанса, что оный явится в ближайшие 13 лет.

Однако пока автоматизация разработки ПО с помощью AI -- это в основном производство ещё более дерьмового и практически не сопровождаемого кода :) Никаким переосмыслением и демократизацией производства программного обеспечения тут совсем не пахнет.

Маск на днях заявил, что новая версия Tesla V12 содержит единичные тысячи строк кода по сравнению с предыдущей версией в 300 тыс. строк кода — за счёт активного использования AI.

"drop >300k lines of C++ control code by ~2 orders of magnitude"

Что-то крайне подозрительно.

Лет 10 назад Toyota была оштрафована на $1,2 миллиарда за баг в софте автомобилей, насчитывавшего тогда около миллиона строк кода. Получилось около $1200 за 1 строку кода -- дороже, чем стоило ПО тех времён в самых дорогих американских космических проектах.

К сожалению, в мэйнстриме сегодня вполне достаточно писать код, который "просто работает", и получать за это 300k/s.

В этом году в Вышку на "программную инженерию" конкурс был 305 баллов из 300. Напомню в этой связи, с трека "Элитный программист", что

"Люди поступают в университет не для того, чтобы получить какие-то новые навыки. Практически всё, чему учат в университете, можно получить бесплатно в интернете, или на гораздо более дешёвых и компактных в сравнении с университетом курсах профессиональной переподготовки, как мои. Люди идут в университет прежде всего для того, чтобы погрузиться в определённую социальную среду. В элитных университетах существуют закрытые университетские братства, состоящие в которых потом всю жизнь помогают друг другу. И именно эта особенность делает университетское образование таким ценным."

Как это всё правильно использовать в карьере, рассматриваем на ЭП подробно.

Случайно наткнулся на "I've been trying to code up the Eilenberg-Moore category for a monad in Haskell."

Я не математик, очень слабо к сожалению в этом разбираюсь, но вот подумал, что если мы сделаем DSL по заветам метапрограммиста Алана Кэя, в котором все типы будут моноидами, то для всех них соответственно будут определены моноидные операции. И тогда мы сможем писать код, как если бы мы находились в категории моноидов Эйленберга-Мура (наверное).

"Eilenberg–Moore Monoids and Backtracking Monad Transformers"

Весь код, который я пишу, работает за O(1).

Жить надо так, чтобы вы с гордостью могли сказать, что за последние 10 лет программирования в вашем коде ни разу не возникла ошибка.

"Надо помнить и о том, что на сегодняшний день нам пока не удалось нащупать "потолок" в какой-либо области человеческой деятельности. С развитием обучающих методик появляются все новые рекорды, и люди из самых разных сфер все более совершенствуются в своем деле. И пока что незаметно никаких признаков того, что это когда-нибудь прекратится. С каждым новым поколением горизонт человеческого потенциала отодвигается все дальше."
"Максимум. Как достичь личного совершенства с помощью современных научных открытий"
-- Андерс Эрикссон

Я знаю пару ребят, совершенно фантастических программистов, а по жизни они реально сильные PhD в математике, и им пока 35 лет!

Увы, в России их больше нету.

От девушки, занимающейся на одном из начальных курсов (занятие по знакомству с системами отслеживания тикетов):

"Ранее на работе я сталкивалась уже с джирой, в принципе, идея ясна. Разве что скажу честно, что обычно там не задачи на 2-3 часа, а такие что делаются по несколько дней. Наверное тогда лучше дробить их, но обычно сотрудникам не охота расписывать каждое действие."

Именно так: если вы сеньор или тимлид, и ваши подчинённые всеми фибрами души сопротивляются дроблению их тикетов по точности до 2 часов (идеальная точность -- до получаса), значит, дела с успешной сдачей проектов в срок и в бюджет в вашей конторе весьма печальны :)

Вполне типична ситуация, когда разработчик мычит "ннну... дня три потребуется на эту фичу...". В таких случаях просите/требуйте декомпозировать тикет на более простые.
Подзадача на 4 часа максимум -- это предел в любой ситуации.

Некоторые задачи действительно трудно сперва оценить, ну значит пусть человек оформляет тикет на 0,5-1 час для предварительного изучения темы, насколько будет трудоёмко.

При этом совершенно ничего страшного, если люди будут ошибаться в оценках. Накосячить в 2-3 раза дольше вполне нормально, и ругать за это ни в коем случае нельзя. Просто фиксируйте себе буферный коэффициент по каждому из разработчиков.

Но есть нюанс...

...Если вы будете пытаться измерять "продуктивность" разработчиков, отслеживая количество закомиченных строк кода, число исправленных ошибок, среднее число комментариев по каждой правке кода и т.д., то люди сосредоточатся на игре в такую систему, чтобы набирать в ней баллы, вместо того чтобы учиться правильным вещам и делать свою работу хорошо.

играть в глупые игры, выигрывать глупые призы...