Дорогие, по голосованию: ну такой перекос в сторону 300k/4часа в день хочут 70% ! Ну да, я и сам такое выбрал :) Хорошо это ещё и тем, что вы можете остальное время как бездельничать, так и саморазвиваться (а при желании работать вторую работу 300/4).
Но для этого вам нужна удалёнка обязательно.

Следующий год посвящаем мощной прокачке по денежной теме, но, напоминаю, с 01.01.24 правила занятий станут ещё строже 🙈

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

=

300/4 хороши ещё и потому, что, ну, вы же знаете фундаментальный принцип теории систем -- закон Гудхарта?

Когда мера становится целью, она перестаёт быть хорошей мерой

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

В СильныхИдеях скоро расскажу маленький секретик, что тут можно поделать: три важнейших критерия по теории систем применительно к программной инженерии, как получать качественный код разумными затратами.

В мэйнстриме это никто не знает, и лучшее, до чего додумались надзиратели -- это требовать, чтобы человек выдерживал 8+ часов в день, уставившись в экран. Это сегодня основной "навык", необходимый для работы программистом.

Дорогие, вы видите результаты ↑
А это ведь одна из фундаментальных вещей в ИТ, однако мэйнстрим словно нарочно придумывает такие абсурдные названия.
Ну можно же было вместо sync/async говорить, например, блокирующий I/O или "overlapped" I/O, а самое простое -- последовательный или "конкурентный" (concurrent).

Знаете почему так? Потому что львиная доля программистов не обучалась в хороших университетах, и их понимание computer science равно абсолютному нулю :)

"Why the fuck do we let people that have no computer science backgrounds write code? Unacceptable!"
Erik Meijer, святой cs

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

И, да, в современном мире это уже андеграунд.

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

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

Вот вам изумительный пример из двух строк, в котором наличествует глубокая мудрость software design.

Мы явно различаем вывод и лог.
При этом сам код ориентирован на логирование.
Но без создания отдельного logging py
И без возни с настройкой лога.

Мы сохранили общее намерение, но делегировали фактическую работу.

Я не могу рассказать вам, что эксперт по Java знает о всём стеке Jave, но я могу рассказать вам, что (и, главное, как) эксперт по Java (или любому другому языку) думает о Java (чаще всего, криво и бессознательно).
Для этого достаточно пройти мой трек по вычислительным моделям.

.
Нулевое правило Лаборатории: никому не рассказывать про Лабораторию.

Первое правило Лаборатории: ты обязан развиваться всю жизнь.

Второе правило Лаборатории: твоё развитие как программиста должно обязательно сопровождаться постоянным ростом денежного дохода.

Третье правило Лаборатории: твоё развитие как программиста должно основываться на суперспособностях -- computer science и математике, чтобы любые веб-фреймворки, языки и технологические стеки твой сильный рациональный ум был способен изучить за неделю.

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

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

Да, но...

Регулярно читаю подобное в отчётах ребят, кто занимается на начальных курсах с нуля:

...Опять ошибка из-за невнимательности – поставил какой-то странный диапазон (300 – 401 вместо 100 – 999). Причём сейчас (через пару дней) я не понимаю, откуда я взял такой диапазон…

...Да да да, счётчик внутри условного оператора - это детская ошибка. Жалко, конечно, что я этого не заметил сам.
Опять невнимательность подводит =(

Вот вам смешно, а вы сами что, лучше, что ли? :)

Пусть не такие ошибки, но всё равно, все мы делаем глупые ошибки из-за элементарной невнимательности на своём уровне, за которые потом стыдно.

С удовольствием слушал сегодня срач экспертов обсуждение экспертами темки синхронщины-асинхронщины в промисах.

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

Но пока не было в ИТ ни одного опровержения гипотезы Фредерика Брукса ("Мифический человеко-месяц"):

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

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

Я не осуждаю их за это, но что же остается нам с вами?

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

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

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

P.S. Кстати, те, кто кричал об опасности AGI, будут уничтожены им самыми первыми :)

P.P.S. А вот такого (LeanCopilot) я уже реально побаиваюсь. Когда к LLM начинают прикручивать теорем-пруверы, языки с зависимыми типами, где написать некорректный код сильно сложнее, ну и в целом, к градиентным брутфорсам добавляется формальная математическая логика...
Рекомендую, кстати, учиться такое использовать.

Они хочут от вас SOLID, ACID, REST, DRY, TDD, OOP, паттерны проектирования и 10 лет опыта. Однако когда вы получаете доступ к их кодовой базе, оказывается, что она представляет собой бессистемную кучу файлов по 10,000 строк в каждом, с множеством перекрещивающихся зависимостей, и ни в одном из них вы не можете выделить ни одной прикладной концепции.

Поэтому будем с этим эйчаровским бредом безжалостно бороться самыми что ни на есть хакерскими способами :)

C++ всё. Он конечно ещё будет достаточно долго жить в легаси-проектах, как Java 8, но даже если стереть весь код в мире, написанный на Rust, это ему уже не поможет.

на фотке: модуль Rust заменил часть кодовой базы на плюсах

Насчёт нулевого правила Школы: никому не рассказывать про Школу.
Один из курсантов, прошедший почти все треки, сказал мне, что не хочет рекомендовать мои курсы своим коллегам, потому что это было бы равносильно передаче им чит-кодов, которые он сам использовал для достижения x2-x10 результатов. Другой сказал, что готов заплатить за формат Hard Work сто тысяч рублей (который для занимающихся у меня бесплатен).
По этой причине материалы из СильныхИдей никогда не будут открыты всем.
Я читаю отчёты ребят по Hard Work, и иногда сам офигеваю, как они теперь круто рассуждают 💥💥💥 :)

На самом деле большинство хороших функций, которым так радуются сегодня разработчики на C#, появилось в F#, а затем было урезано до императивщины.
К сожалению, F# не получает достаточных заслуг за создание всего того, что C# бессовестно присваивает :)

Раньше все университеты принуждали разработчиков к изучению Lisp. Дескать, даже если вы никогда не будете его использовать, глубокое просветление того стоит.

Что сегодня эквивалент Лиспа?

Думаю, это F# (OCaml).

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

F# -- это как научиться программировать заново.

Очень доволен, как ребята проходят мой курс по F#, десятки отзывов где пишут, что крыша едет )))

Куда мы придём по мере распространения AI-ассистантов? Университетские программы по computer science будут постепенно отказываться от узких навыков работы с кодом -- таких как алгоритмы и software desing, в сторону изучения основ работы в emacs и vim, дополненных ai-чатами.

Замораживаю все цены на мои курсы до 17 марта 2024-го ❄️❄️❄️

А с 18-го марта прям безжалостно раз в 10 повышу, и вообще будет тотальное инфоцыганство и полный хардкор! 👊👊👊

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

Недавно например с печалью наблюдал, как сильные эксперты спорят по каким-то там техническим нюансам, откровенно оскорбляя оппонента. Зачем?? Дорогие, люди десятилетиями не могут договориться, как пробелы в коде расставлять...

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

Это поразительно... Эти люди, что, сами каждый день не врут десятки раз, и по мелочам, и по крупному? Родным, знакомым, незнакомым, коллегам, начальникам, подчинённым, обществу в целом? Они не делают другие плохие вещи? Они святые? Они всю свою карьеру честно отрабатывали каждую минутку положенного рабочего времени на 100%, никогда не воровали время у своего работодателя?

Такие споры -- самое глупое, на что только можно тратить свою жизнь...

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