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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну что ж, я готов признать — Cursor прям хорош. Когда я пробовал его в последний раз, он меня так сильно не впечатлил. Понятное дело, что это заслуга не сколько самого Cursor, а того, что модели сами по себе стали куда круче, но мне прям зашло сегодня.

Я сегодня за 10 минут сделал задачу, которую бы вручную пилил примерно час. Нужно было залезть в проект, в котором я ничего не делал месяца три, и, понятное дело, уже всё забыл, как там всё устроено. Проект на next.js, и, разумеется, за это время я уже забыл, как работает React. Да и вообще по меркам фронтенда за 3 месяца ты устареваешь примерно так же, как джавист, который всё ещё пишет на Java 7.

А эта нейросетевая балалайка ничего не забывает: сама пошла, прочитала проект и добавила мне страницу – прям как нужно было, куда нужно было и прям в моём стиле. Ощущения, конечно, невероятные.

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

Про ситуацию на рынке ИТ труда

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

Хорошая штука, жизненная. Однако я бы добавил, что если мы говорим про работу в корпорации, то перед заходом в туалет он должен определить метрики, по которым поймет насколько чисто. Ну а после разумеется нужно создать meeting notes и рассказать о том, как все прошло!

Ваше регулярное напоминание, что async/await это от бедности и нужны только тем, у кого нормальных потоков нет. Если есть потоки, то делаешь блокирующие вызовы и вуаля

Итак, я наконец-то вернулся к постам. Интересный феномен: чем больше я делаю паузу, тем сложнее потом снова к этому возвращаться.

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

👉 Я НЕ стал стаффом, по-прежнему обычный сеньор. Но, объективно, я, сука, был близок – поэтому, видимо, разъвыебываюсь этим только через полгода, в лучшем случае.
👉 Ушёл из мобильной разработки. Последние три года я, в целом, был в команде инфры, которая толком мобилкой не занимается, но задачи, связанные с Android, всё равно были. Теперь же я перешёл в команду, которая вообще никак не связана с мобилкой. Про то, как так получилось, сделаю отдельный пост, а пока вкратце – я теперь Python-разработчик. Дээ, помотала меня, конечно, судьба.
👉 Влюбился по уши. Летом много из-за этого плакался в постах, но проблема с личной жизнью решилась как-то даже быстрее, чем я ожидал. Видать, вся удача сюда и ушла.
👉 Пожал 130 кг – без экипировки, фармы и моста. До КМС в моей весовой не хватает всего 2,5 кг, поэтому, возможно, в ближайший год даже где-нибудь выступлю.
👉 Повредил плечо и сломал лодыжку. Приближающаяся тридцатка даёт о себе знать.
👉 Посетил сплав в Перми, где проебал телефон вместе с Trust Wallet, на котором было баксов 500. Теперь доступ к нему лежит на дне Усьвы.
👉 Сгонял в Казахстан. Посетил Баянаул – небольшую зону отдыха на северо-востоке Казахстана в окружении гор. Для меня это больше была поездка ностальгия, ведь туда обычно ездили семьёй, когда я был подростком. Ну и, конечно, после отдыха в Дубае, Таиланде и т.д. это ощущается как пиздец какой спартанский отдых.

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

Короче, было пару вопросов — кто такой стафф, поэтому давайте пару пояснений.

Стандартный трек карьеры айтишника выглядит так:

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

Далее ты выходишь на уровень мидла. Тут уже всё индивидуально: некоторые находятся на этом этапе год-два, некоторые задерживаются дольше. В целом мидлы считаются рабочими лошадками — потому что ты ещё не успел выгореть от формочек и перекладывания JSON’ов, тебе всё дико интересно. На этом этапе все страдают страшным перфекционизмом, чётким следованием заветам Дяди Боба, SOLID и прочих аббревиатур. Мидл — уже самостоятельная единица, за ним нужен лишь небольшой контроль. И то — только для того, чтобы, если мидлу скучно, он не начал делать бесконечный рефакторинг или не затащил новую либу, которая вышла только вчера.

После идёт сеньор. Это уже больше про какие-то сложные фичи или архитектурные задачи на уровне всего проекта. Ты уже знаешь, где нужно быть дотошным перфекционистом, а где можно быстро наговнокодить, чтобы быстрее заехать в прод. На этом этапе у тебя уже есть история проёбов, и ты знаешь, какие задачи нужно делать, а на какие лучше забить. Сеньор уже больше думает про бизнес-ценность. Полностью автономная единица — закидываешь ему задачу и можно не париться: всё будет сделано норм.

Идти выше – уже опционально, потому что и на уровне сеньора вполне комфортно сидеть. После сеньора идут две основные ветки, которые можно качать:

👉 Первая, дефолтная — уходить в менеджмент. Сначала ты тимлид, потом, если повезёт и ты готов ебошить, становишься тимлидом тимлидов, а дальше движешься к CTO. Однако нужно понимать, что на высоких должностях ты забываешь про ламповое айти — и у тебя буквально начинается игра престолов.

👉 Вторая — это ветка архитектора или техлида (он же стафф). В этом случае ты не управляешь конкретной командой, но влияешь уже на несколько проектов. На этом этапе ты создаёшь какие-то best practices, подходы, которые используют все, или делаешь уникальные решения, приносящие дикий профит. Конкретно эта ветка есть далеко не во всех компаниях, да и не везде она реально нужна.

Про плюсы и минусы грейда выше сеньора я сделаю отдельный пост.

Гребаный Python, я вам сейчас опишу ощущение от языка одним предложением.

Это чувство когда ты уже 8 лет работаешь в IT, но уже два часа не можешь расставить кавычки в строке как нужно, чтобы сформировался корректный json.