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

На треке Бесстрашных переговоров о зарплате я подробно, с самых первых занятий, разъясняю всё об этой тактике и о том, как её правильно применять, с готовыми скриптами. Она работает даже с чрезвычайно настойчивыми кадровиками.

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

Слева архитектура ИТ-департамента корпорации TRANSHUMANISM INC., которую делали профи.

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

Это пишет фаундер HashiCorp (infrastructure automation software helps cloud platform teams deliver better business outcomes as they provision, secure, manage, and run cloud).
Типа, вы проводите дни, выискивая какую-нибудь ошибку. Даже недели. А потом...

Это была опечатка в одной строке.

Похоже, это закон: чем больше времени занимает отладка, тем глупее первопричина.

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

Там, куда вы просто никогда не заглядываете. Там, где, на первый взгляд, всё покрыто тестами, код проходил code review, и сеньоры уверены, что всё в порядке.

Мина может быть заложена в любом месте вашего кода.

Но есть приёмы, позволяющие сделать ваш код защищённым от подобных мин. На формате hard work даю множество практических советов по их предотвращению.

Чудо какое: новый веб-стек tRPC

Типа, больше не будет разделения на бэк и фронт, и главное, что вы получаете полную поддержку типов с "автозаполнением" на сервере и клиенте + автоматическая проверка в рантайме, что ваши входные и выходные данные соответствуют спецификации вашего API.

Когда сложная логика на сервере, или highload, где много клиентов хочут данные в разных форматах, tRPC вряд ли подойдёт, но когда вы делаете проект с акцентом на фронтенде, где бэк скорее вторичен, tRPC очень хорош.

Ну и ещё прикрутить zod (TypeScript-first schema validation with static type inference)

Подъехали очередные позитивные AI-новости.
CEO Anthropic (вторая компания по продвинутости в AI) заявил, что, как он полагает, сверхчеловеческий AI будет готов совсем скоро, и шанс примерно 1 к 6, что он убьёт всех.
"люди, безусловно, будут удивлены тем, на что окажется способен AI в 2024-м году"

Ожидается, что фаза "изменения реальности" (новые научные открытия, лечение тяжёлых болезней, создание биооружия нового поколения) начнётся в 2025--2026 гг.

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

Особенно порадовал свежачок, научная статья "a powerful new capability of LLMs: recursive self-improvement"
recursive self improvement in 2025, superalignment team deadline 2027.

"Бабашка" -- метациклический интерпретатор на кложе для кросс-платформного скриптинга (вместо баша например).

Архитектура монолита, которую спроектировали не занимавшиеся в моей Школе.

"Без требований и без проектирования программирование -- это искусство добавления ошибок в пустой текстовый файл".
-- Louis Srygley, ИТ-архитектор сервиса доставки UPS

Микросервисная архитектура, которую спроектировали не занимавшиеся в моей Школе.

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

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

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

Поможет ли тут самый продвинутый AI?

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

Но для этого у меня есть полуформальный приём от ИТ-святого, который скоро расскажу курсантам в СильныхИдеях.

MVC-архитектура, которую спроектировали не занимавшиеся в моей Школе.

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

"Системе не хватает модульности, если изменение одного из её компонентов влияет на функционирование других"

Модульность -- безусловно, очень важный аспект в программировании, но её достижение требует дополнительных усилий. Стандартный подход, когда вы стараетесь отделить каждый тип от другого с помощью абстракций. Именно это и подразумевается под словами " low coupling, high cohesion".

Как уже раньше не раз говорил, если довести эти принципы до логического конца, то в итоге получатся сотни (а то и тысячи) небольших типов, которые можно вырвать из вашего приложения и бросить в любом другом месте, поскольку они отвязаны от вашего кода (этот момент рассматриваем на курсе ООАП), но в этом есть и свои минусы (много лишнего кода, объёмное и излишне детализированное юнит-тестирование...).

Поэтому для курсантов в СильныхИдеях я отдельно написал 5 заметок по принципам SOLID, как их лучше воспринимать с точки зрения функционального программирования.

Что происходит, когда во время выполнения возникают проблемы с разрешением зависимостей, волшебным образом зарегистрированных в вашем чудесном DI-контейнере?

Ричард Хикки, автор Clojure:
"Нет состояния, только снапшоты данных"

Анатта (бессамостность) в буддизме:
"Нет неизменной сущности, только процессы"

Два мира, одна интригующая перспектива.

"Из всех способов бегства от реальности математика достигла наибольшего успеха...
Все остальные побеги - секс, наркотики, хобби и т.д. - по сравнению с ней эфемерны.'
-- Джан-Карло Рота, математик, философ, МИТ

Математика самая крутая вещь в мире.

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

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

Python и PHP более производительны, чем Си.

А чем будет монада продолжения в категории эндофункторов?