Услышал сегодня короную фразу от devops: "Все что произошло в облаке, остается в облаке". Ведь эта херня не воспроизводится локально, вне облака!

Понедельник. Схуяли ли тишина такая? Ну-ка проснулись! Сейчас я продолжу душнить про алгособесы.

В дополнение к шаблонам я хотел накидать ещё пару своих авторских советов, которые могут пригодиться.

Не пытайтесь делать всё в одном цикле. Есть лайфхак, который работает для многих задач: разделите задачу на две части. Одну часть решаете в одном цикле, вторую — в другом. Сложность всё равно останется O(n), но решение может стать в разы проще. Многие погибли на пути построения жутких условий, чтобы сделать всё "красиво" в одном проходе.

Иногда лучше идти не с начала, а с конца массива. Для части задач это избавляет от необходимости в дополнительной памяти.

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

Лучше потратить немного времени на проработку кейсов (прям пишите вот это на вход, это на выход, чтобы все было перед глазами) и требований перед тем, как писать код — это реально может спасти. Кстати, и в работе отличный совет!

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

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

Я сейчас делаю свои первые, неуверенные шаги в изучении Data Science и уже наткнулся на крайне занимательную статью. Для матерых DE и DS, которые есть у меня в канале, она, разумеется, может показаться банальной, но для таких же новичков, как и я – весьма интересной.

Статья про обнаружение выбросов в данных с помощью метода опорных векторов. Как и положено в сфере машинного обучения, алгоритмы представляют не так много интереса, как сами данные. А данные – уф, моё почтение.

В качестве набора данных для анализа в статье использовался файл с информацией о 604 девушках месяца журнала Playboy. Согласитесь, искать выбросы в таких данных куда интереснее, чем в результатах билда gradle (хотя и тут все связано с сексом).

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

P.S В статье есть фотографии моделей тех лет и на совеременный лад они прям очень кринжовые)

Если бы у меня было 3 желания, то самым первым желанием я бы загадал не бессмертие, железное здоровье, нереальное богатство или мир во всем мире, нет…

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

«Если ты видишь скамейку в спортзале, рядом с которой стоит вода и гантели, то ОНА БЛЯТЬ ЗАНЯТА, сучара ты не внимательная!»

В QA есть такой принцип, который называется "Скопление ошибок". Я делал про него пост, если вкратце, то принцип звучит так: "Если вы обнаружили баг в какой-то фиче, то с высокой долей вероятности в этой фиче есть ещё баги."

Мне кажется, этот принцип выходит далеко за границы тестирования ПО. Я бы назвал его принцип "Скопление бед": в периоды жизненной турбулентности плохое событие редко приходит в одиночку – почти всегда рядом будет поджидать ещё одна мразь!

Возвращаясь к теме метода опорных векторов. Я также наткнулся на очень бородатый доклад Бобука (настолько бородатый, что Яндекс еще был в прайме) о том, как, используя этот метод, они значительно увеличили конверсию лендинга. Суть там такая: у них был продукт с продающим лендингом, на который они вели людей из Facebook*.

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

Они пошли дальше и собрали кучу статистики – в каком случае лендинг продаёт лучше, в зависимости от пола, возраста, времени суток, локации и примерного уровня заработка.

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

Самое интересное в этом докладе – последний вопрос, где кто-то спрашивает: «Каким, нахрен, образом вы собрали информацию о посетителе лендинга? Facebook* же просто так не выдаст ни локацию, ни уровень заработка, ни какую-либо другую личную инфу».

Вопрос и правда интересный – и вот тут оцените уровень их смекалки.

Большинство рекламных систем в соцсетях позволяют настроить ну прям невероятно точный таргетинг. Я где-то слышал, что в Instagram* есть таргет на «пару, которая встречается, но в данный момент в разлуке».

Итак, что они сделали: они запустили 61 тысячу (тысячу Карл!) рекламных кампаний, каждая из которых с очень узким таргетом. И каждый раз, когда человек приходил к ним на лендинг, они тупо по идентификатору кампании понимали буквально всё об этом человеке.

Меня приводят в восторг подходы, когда просто отсутствует чека безопастности. Чего ограничиваться парой компаний, давай 50 тыс. фиганем!

Не знаю, пофиксили ли эту дыру в Facebook*, но сам подход меня просто поразил своей гениальностью.

* Кстати, Facebook и Instagram в РФ считаются экстремистскими, так что вы это... не балуйтесь!

За последние 3 года работы, я сегодня впервые услышал звук кулера на маке! Это значит, что сейчас не просто жара, это испепеляющее душу дыхание ада

Кто-нибудь скажет дизайнерам Яндекса, что черный текст на темном фоне это слегка не удобно?

Итак, отпуск.

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

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

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

Итак, Казахстан

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

Первые 18 лет своей жизни я прожил в небольшом городке возле Караганды. Первое, что удивляет при переезде в Россию, – это то, что многие думали, будто Караганда – это просто набор букв, а не название реального города: «Где? Где? В Караганде!».

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

Теперь просто перейдём к списку интересных фактов:

👉 Все здороваются двумя руками, а не одной! Потому что здороваться одной рукой – это показатель неуважения.
👉 Очень много фамильярности. Особенно это чувствуется после жизни в Питере, где даже гопники обращаются к тебе на «вы».
👉 Все очень свободолюбивые, поэтому никто не любит пристёгиваться в машине, даже водители.
👉 Таксисты гораздо агрессивнее, чем в России. Если чуть-чуть дашь слабину – уедешь в Шымкент против своей воли.
👉 Национальная кухня – прям жирная. Я на своей диете уже отвык от большого количества жиров, поэтому с бешбармака меня просто вынесло. Мой ЖКТ приходил в себя несколько дней.
👉 В Казахстане два самых больших города – это Астана и Алматы. Это буквально аналоги Москвы и Питера, только если бы в Питере жило больше людей. Мне как в России больше нравится Питер, так и в Казахстане больше нравится Алматы.
👉 "Астана" с казахского переводится дословно как "столица". С названиями тут не сюсюкаются.

Ну и парочка стереотипных вещей:

👉 Насвай. В моей школе многие баловались этой темой. Именно в моём городе популярность этот продукт имел по причине того, что градообразующим предприятием были шахты. А в шахте курить нельзя – и тут на помощь приходил этот аналог снюса.
👉 Блюда с кониной и правда продаются почти в каждом заведении. Я всё детство жил в Казахстане, и для меня это всегда было очень привычной вещью. Мне до сих пор сложно привыкнуть, что многих людей из России это прям удивляет.
👉 Ну и тот факт, что казахи используют маты как междометия – далеко не всегда правда. Те, с кем я поддерживаю связь, наоборот, используют в речи довольно мало мата. Однако, возможно, это просто у меня такой круг общения...

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

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

Например, недавно в очередной раз объявили зашкваром использование utils. Типа, там всегда хаос и бардак, типа, признак плохого кода. «Технический долг».

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

Или Эндрю Келли, создатель языка Zig, объясняет, почему в Zig нет приватных полей. Люди с опытом побольше в основном соглашаются — ну да, ну да, все поля по факту публичные, границы размыты, и т.п. А люди, которые только начали программировать и знают один язык, в котором есть приватные поля, сразу — как же так? Как без приватных полей жить-то? Это ж ни одной программы не получится написать? А все кто не согласны — дураки!

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

Только вернулся из отпуска – и сразу наткнулся на процесс ревью: отзывы, результаты задач и всё такое. Вообще, это интересный период, чем-то напоминает сессию в универе или школьное сочинение "Как я провёл лето".

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

Бизнес обожает метрики и цифры. Нужно всегда показывать: "до задачи было X, а после стало 3X". И никого не волнует, что иногда эти цифры вообще ничего не значат для реальности.

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

В итоге получаем две крайности:

👉 Мы не собираем никаких метрик и вообще не понимаем, делаем ли мы лучше или только вредим.
👉 Мы собираем всё подряд и в итоге сами себя путаем.

Я нашел несколько советов, которые помогают не отрываться от реальности и вообще выжить в корпоративном мире:

👉 Думать о метриках ещё до старта задачи. Желательно уже на этапе проектирования спросить себя: "Как мы поймём, что не сделали фигню?" Совет банальный, но на практике это, пожалуй, самая сложная часть. Зато потом проще на всяких ревью.

👉 Использовать научный метод. Сначала выдвигаем гипотезу, а потом проверяем её данными. В IT часто делают наоборот: собирают тонны данных через A/B-тесты, а потом из этого хаоса что-то пытаются понять.

👉 Пробовать опровергнуть себя. Когда получаешь данные, очень хочется их "подогнать" под хороший результат. Но полезнее наоборот – попытаться найти слабые места и раскритиковать себя. Если не выходит – значит гипотеза реально рабочая.

Ну что там с AI?

Мне в последнее время попадается много роликов на YouTube о том, что профессия программиста исчезнет через 5-10 лет. Как один из ярких аргументов приводится то, что рынок найма сейчас стал похож на дикие джунгли. Тот факт, что у нас экономика еле-еле дышит, в этих видео почему-то не упоминается.

С одной стороны, понятно, что обращать внимание на дурачков вроде CEO Anthropic (по прогнозу которого мы уже должны генерить 90% кода через ИИ) не стоит. С другой стороны, считать, что в IT совсем ничего не поменяется с приходом агентов, тоже не лучшая стратегия.

В одном из подкастов я услышал мнение на этот счет. Я не знаю, насколько оно окажется правдивым, что-то предсказывать в текущее время вообще абсурдно, но мысль мне нравится (цитата не точная):

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

Что вы думаете? У меня лично пока нет понимания, как LLM может полноценно заменить разработчика, потому что даже самые новые модели все еще сильно тупят и не могут выдать полностью рабочее решение

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

Помимо советов которые я привел в посте, я также хочу посоветовать канал моего коллеги и друга Сани. Он у себя в канале «Я Delivery Manager 🚀» простыми словами разбирает:

👉 Как метрики (Lead Time, Cycle Time, WIP) реально помогают?
👉 Зачем нужны процессы (и когда не нужны 👀)?
👉 Как сделать так, чтобы задачи закрывались, а не тухли в бэклоге?
👉 Что работает в продуктовой и заказной разработке?

Помимо этого у него также можно спросить как выбрать "Ниву", ну это так к слову @iDeliveryManager

erid: 2VtzqwpX7WA

За последние 3–4 месяца у меня как минимум пятеро знакомых разработчиков уволились «в никуда», просто в свободное плавание. Именно сами ушли, а не под сокращение попали.

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

Во-вторых, у меня, конечно, это немного в голове не укладывается: с одной стороны, у нас сейчас очень суровый рынок, но при этом часть разрабов такие – «а похуй, я на каникулы».

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

Изучая системный дизайн, у меня родилось ещё одно определение слова "Архитектура ПО". Архитектура ПО – это ответ на вопрос: что будет, когда отъебнёт X. Не если, а когда!