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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну что там с AI?

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

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

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

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

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

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

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

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

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

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

Меня очень забавляют разрабы, которые страшно гордятся тем, что сделали проект "без единой библиотеки". Как вид спорта – выглядит интересно, для пет-проектов даже прикольно. Но если речь про рабочий продакшн – это очень сомнительная история.

Моя философия в этом плане простая: всегда по максимуму использовать готовые решения, если они закрывают задачу. Чтобы писать своё – нужна железная аргументация, а не в стиле "да проще своё накидать, чем что-то тащить".

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

Писать своё стоит тогда, когда у вас уже есть бюджет и вы чётко понимаете, почему готовое вас не устраивает.

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

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

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

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

Мне довелось участвовать в проекте, где решили написать свою RxJava. Итог – 10 из 10. Разумеется, я про количество свечек за здравие того разработчика, который это придумал.

И всё равно вы никак не избавитесь от сторонних зависимостей, как бы ни хотели. Вы же не будете писать свой HTTP-клиент с нуля? Или своё решение для асинхронщины? Или собственную БД?

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

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

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

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

Ещё парочка инсайтов с проведения алгособесов.

Если во время решения у вас возникает желание сделать более двух-трёх флагов, с вероятностью 99% вы двигаетесь не туда. Большая часть задач решается максимум с одним флагом – и то не всегда.

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

Начинайте с прописывания тест-кейсов. Это один из самых важных пунктов, а то большинство ограничивается только happy path и забивает на граничные условия или негативные сценарии. Потом приходится всё переделывать и тратить время.

Ладно похихикали и хватит, верну название с кумысом когда опять приеду в Казахстан

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

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

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

К сожалению мудрость не работает с мобилками, там есть упало то аминь, жди обновления!

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

Зацените решение: есть плейлист, в нём список треков. Я хочу удалить несколько треков в конце плейлиста, но, видимо, по мнению UX-дизайнеров Яндекса, я должен после каждого удаления перемещаться в начало списка! Сука, ну это же базовое правило: не трогайте скролл. Если мне надо – я сам перемещусь в начало. Или сделайте отдельную кнопку для этого, если уж вам так нужно что-то на ревью представить!

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

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

"Не извиняйся! Стань лучше!"

Вот я вроде уже прям долго работаю в IT, но все равно, в какой бы команде я не работал, у меня всегда этот диалог так и выглядит, слово в слово