Нередко ребята, ищущие работу миддлом, жалуются, что не получают отзывов на резюме вообще, хотя опыт работы 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 раза дольше вполне нормально, и ругать за это ни в коем случае нельзя. Просто фиксируйте себе буферный коэффициент по каждому из разработчиков.

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

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

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

Синхронизм двух отчётов курсантов :)

"Первые трудности были связаны с установкой фаззера на рабочий MacBook (хотел протестировать рабочий код).
Для установки требуется полноценный Clang, который содержит libFuzzer (как понял на Mac стоит урезанная версия Apple Clang).
Для решения данного вопроса потребовалось установить LLVM. Установить с первого раза не удалось. Потребовалось несколько вечеров, чтобы настроить окружение для установки Atheris."

"Вообще сложности возникли только с макбуком, который я неданво получил и все ещё настраиваю. Пришлось собирать из исходников clang; потому что apple поставляет огрызок llvm без libFuzz."

=

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

"And no, I do not have last Tuesday’s list of what is and isn’t supported under Linux, nor do I have next Tuesday’s list, which will in all probability be a different list."

-- Terry Lambert
отец FreeBSD, написавший в Apple 6% OS X kernel

C++ + его экосистема -- это уже реальная секта, порог входа весьма высокий, посторонним в :)

Конечно, секты круче исповедующих Лисп уже никогда не будет, но вот плюсисты к ним энергично подтягиваются.

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

Исключения -- это по сути современные GOTO (динамическая типизация, скрытая в статической типизации). Когда конструктор выбрасывает исключение, он пытается вернуть что-то, отличное от явно запрошенного типа.

Начинающие часто делают такую ошибку: надо написать функцию, возвращающую сумму значений из набора файлов, а если там возникнет любая ошибка (от отсутствия файла до записанного в него нечислового значения), то что с ней делать? выбрасывать своё исключение? что-то "ошибочное" (null/None) возвращать в качестве результата?

Отсюда мы плавно переходим к фабрикам и монадам :)

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

Это особенно актуально при активном использовании IoC-контейнеров, которые так любимы в мэйнстриме: если мы ждём отложенного поступления данных, а затем строим поведенческий класс, то у нас нет других вариантов, кроме явного вызова конструктора -- который ярые сторонники IoC как раз отвергают сходу.

Расскажу дальше чуть подробнее.