Лаборатория Математики и Программирования Сергея Бобровского

Найдена ошибка в реализации? Нет проблем, "горячий фикс" для соответствующей функции в ближайшем релизе!

Ну разве эта "методика" разработки, даже с точки зрения простого здравого смысла, имеет право на существование?

Однако таков весь мэйнстрим 100%.

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

Это бесконечное колесо программистской сансары, вырваться из которого можно лишь с помощью святых computer science :)

В продолжение вчерашней темы, насколько всё может быть шатко (на самом деле, в жизни всё всегда шатко), пишет девушка, у меня раньше занималась:

"...(мой среднемесячный заработок около 560т.р. - это оклад + премия(годовая, если ее размазать по месяцам)), а вот в своих навыках в IT за время работы на текущем месте я стала сильно сомневаться (потому что это работа аналитиком данных и заключается она в клепании отчетов в excel).
Я прошу у Вас экспертной помощи есть ли у Вас продукт/курс, который мог бы помочь мне разобраться в текущей ситуации и найти себе снова место в IT, на котором я могла бы продолжать получать соразмерный доход и заниматься тем, чему я учусь последние годы (на Ваших и других курсах - программирование на python, Data Science, аналитика. Вероятно с управленческой функцией)."

Насколько помню, из действующих курсантов у меня сейчас, кто в России, в Москве ребята пытаются схантиться на 300k/s 450 максимум. Вполне реально, но для этого нужны а) сильные софт-скиллы и б) сильные рабочие скиллы скиллы прохождения собеседований по программированию.

Очень частая в этом ошибка, что люди начинают метаться, когда уже слишком поздно. Увы, так это не работает. Эти оба пункта надо развивать регулярно (многие месяцы) и шлифовать вдолгую (всю жизнь), для чего вам в помощь мои курсы карьеры и переговоров по зарплате + моя разумная помощь. Ну и помощь любых других менторов, кого найдёте подходящего, тоже всегда приветствую.

"на python, Data Science, аналитика", ну наверное на 100т можно, и то если постараться, если не было профильного опыта. Но представляете, падать в деньгах в 5 раз? Ничего в такой ситуации к сожалению, чтобы "продолжать получать соразмерный доход" не могу посоветовать. Если ещё есть запас хорошей кармы, может и получится снова найти подобный уровень дохода, но опять-таки, случайно...

В этом опасность больших зарплат, когда они совсем не соответствуют вашим скиллам: они, как сладкоголосые сирены, затягивают вас в карьерный тупик. Потому что если бы зп 500+ соответствовала вашим скиллам, то вы бы без проблем быстро нашли новую работу. Пусть не на 550, но на 400+ точно. Так что всегда лучше ориентироваться на свой профессиональный уровень и постоянно тянуть его вверх.

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

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

P.S. Не то чтобы я вам говорил "не идти на 500 если у вас сейчас 200" )))
Идите конечно, просто имейте в виду, что такое счастье абсолютно точно продлится недолго, и будьте морально готовы потом прилично откатиться назад. Будут ли стоить эти случайные деньги++ потери в вашем профессиональном уровне? Думайте об этом стратегически.

Поучительный пример с Сэмом Альтманом, которого выгнали с работы за 15 минут буквально ни за что ("Не веди мне перепиаренных людей").
Причины разные называют, почему именно сейчас? А я говорил 3 дня назад: политики сделали из него "ритуальную жертву".

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

Хороший код совсем не похож на код.

Статья нашего курсанта Алексея на хабре
"Алгебра совокупностей Брусенцова и не только"
(поставьте плюсики, кто там тусуется)

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

И у себя в паблике я давно закрыл комментарии, потому то кто пишет комменты, это практически 100% бездельники, которые на моих курсах не занимаются. Зачем мне на них время тратить? Им заняться нечем, вот и сидят на подобных форумах.

В тему, из отчёта курсанта Андрея:

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

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

Пишет курсант Кирилл :)

"...при вызове git status всегда подсвечивались Untracked files из родителя, выделенные красным шрифтом, которые мешали чтению ответов в консоли. И я конечно же нагуглил решение, которое удаляло эти Untracked files, но к несчастью, не так как я планировал. Думал, что они удалятся из неотслеживаемых, а они удалились физически

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

На курсах рекомендую, ну и всем напомню, как минимум поиграйте в git-игру => learngitbranching.js.org

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

Минимальное тактическое решение, думаю, это позволять работать из дома на удалёнке (я когда-то в 80-х в почтовом ящике со вторым допуском так работал на дому :), но из-за NDA, понятно, в 80% это нереально.

Поэтому единственный адекватный выход (если завтра не случится что-то форсмажорное в этих областях) -- заказчикам из верхнего правого учиться делегировать свои проекты внешним подрядчикам, в оффшорную разработку, учиться писать адекватные ТЗ, учиться думать в терминах "программных продуктов" и "технологических стеков" (для чего нужна господдержка всем этим процессам), учиться контролировать исполнителей и относиться к ним с огромным уважением и т.д. и т.п. А не то что, встречал подобное не раз, в ТЗ расставляют кванторы всеобщности в каждом предложении: "...должно работать во всех версиях Windows начиная с 95, и на всех мобильных устройствах...".

Это общемировая проблема, в США то же самое, читаю регулярно, как в топовых компаниях ВПК вроде Lockheed Martin и Raytheon не могут найти программистов, работают в основном деды (под руководством ничего не понимающих в теме отставников, пристроенных в тёпленькие местечки благодаря тому, что в своё время помогали этим самым компаниям оформлять крупные оборонные заказы :).

"Их бы оттуда, кто получше, неплохо было бы перетянуть с ИТ-помойки в верхний правый квадрант, это да (если бы квалификация подходила). Да только там с мотивацией плохо – зарплаты низкие. Разве что бронь от мобилизации? То есть, вообще-то, у нас есть нехватка приоритетов и финансирования важных областей ИТ, а вовсе не программистов, мне кажется."
(отсюда)

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

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

Каков наиболее вероятный сценарий захвата мира искусственным интеллектом?

Существует 1000 сценариев, но вот наиболее вероятный из них (который редко обсуждается):

1) Сначала кажется, что всё идет хорошо, потому что AI сперва много где реально помогает (имеем это сейчас);

2) Но на самом деле риск быстро увеличивается, поскольку и корпорации, и военные вынуждены передавать принятие решений AI, иначе они останутся позади конкурентов.

Сначала они будут передавать около 10% решений (как сейчас), но вскоре это будет 90%, а затем и 100%. AI станет слишком умным и быстрым -- мы не сможем понять, что он делает, и каковы его действительные намерения. Но мы должны это делать, иначе проиграем конкурентам.

3) Когда это произойдет достаточно массово, мы потеряем контроль над будущим, потому что наша судьба окажется в руках AGI. Мы стали детьми, а AI - взрослым.


P.S. Байден и Си на сегодняшней встрече намерены подписать соглашение о запрете дальнейшей разработки AI для автономных устройств.

Владимир занимается на начальных курсах, делает первые задания по ООП, и вот его показательная мудрая рефлексия, которая актуальна и для сеньоров -- насколько важен правильный Software Design:

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

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

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

Точно, в правильном проектировании важно понять прежде всего, а что вам НЕ нужно делать :)

У Алёны Владимирской очередной ценный пост про личный бренд:

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

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

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

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

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

Я вас этому на курсе блога учил когда-нибудь? Никогда!

Вам надо своим блогом продемонстрировать ОДНО: что вы трудяга, что вы пахарь! Что вы будете на новой работе вкалывать на 100500% и приносить огромную пользу команде и проекту!
(и вот именно за это они должны платить вам 300k/s:)

Гитхаб вам в помощь, но тоже умеренно: лучше всего размещайте там учебные материалы, демонстрирующие ваш постоянный рост, и небольшие сайд-проекты, которые создаёте в познавательных целях. Иначе, считается, "если вы увлечены сторонним проектом, значит, не будете выкладываться 100% на основной работе".

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

Когда пишете очередной пост, всегда думайте: вот вы техдир и читаете этот блог, возьмёте такого на работу? С явной биполярочкой? :)

Но действительно, со стороны самого себя тяжело так выслеживать, поэтому с 1 января я буду за всем этим осуществлять особо тщательный надзор :)

Обожаю моих папищеков! 😊😊😊
Свежий пост.

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

То странное чувство, когда зашёл на еаптеку...

P.S. комментарий от курсанта:

"При чем у них слишком смешной собес был - мои 10 лет опыта Фреймворка для них не показатель)))
При этом по коду видно, что у них проблема с библиотекой работы с rabbitmq
На проде обновили зависимости видимо)))"

Как правильно разбираться с 9 видами зависимостей в проекте, напомню, разбираем в СильныхИдеях 😁

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

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

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

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

Если вам не становится стыдно, когда вы посмотрите на свой код 2-месячной давности, значит, вы совсем не развиваетесь в программировании.

В продолжение "... я установил обновление Visual Studio и у меня перестал запускаться проект"

Микро-урок по Software Design. Я уже у себя в проекте учебного сервера (он на C# + F#) поковырялся в настройках, и вот что обнаружил в README:

code --install-extension my-vscode-plugin-0.0.1.vsix

Это и есть hidden coupling (9 видов зависимостей и что с ним делать разбираем на практике на Hard Work).

Представляете, теперь микрософтовцам, если они следуют собственным рекомендациям, необходимо вручную обновлять всяческие инсталляционные скрипты при каждом изменении версии (и они наверняка будут это забывать). А сколько пользователей этой рекомендации последуют? Это всё, что надо знать об уровне проектирования в FAANG.

Правильно так:

code --install-extension my-vscode-plugin-*.vsix

Запустить и забыть.

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

Однако если вы пообщаетесь на эту тему со взрослыми системными инженерами, они заговорят с вами прежде всего на тему "онтологии". Так в чём разница между "требованиями" и "онтологией"?

Ну, вот вам например важный лайфхак: "требования заказчика" всегда представляйте как "фантастические представления заказчика о требованиях" )))

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

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

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

Вы же знаете, что, например, техническую концепцию интернета первым придумал советский инженер Анатолий Китов под руководством В. М. Глушкова в 1963-1964 гг? Другое дело, что спустя несколько лет лет первый обмен реальными сообщениями между серверами в США организовало DARPA.

Другой пример: сегодня математику усваивают около 20% учащихся, а геометрию всего 1%. А в конце 1940-х, сразу после войны, в тяжёлое и голодное время, полноценно усваивали все разделы математики 80% школьников, учившихся по методике Андрея Петровича Киселёва -- его учебники множество раз переиздавались ещё до революции и потом долго, оригинальные версии пока можно найти. В них потом всяческие умельцы принялись вносить "улучшения", и сегодня имеем то что имеем.

"Нет лучше школы, чем старая школа" (с) Рок-н-рольщик