BASCODE
139 subscribers
114 photos
5 videos
61 links
Судя по кругам под глазами, прод выжил!
Download Telegram
Channel created
Привет! Меня зовут Димой 😎 и на сегодня мне 34 года.

Работаю лидом команды в Uzinfocom, где мы цифровизируем медицину Республики Узбекистан. После 14+ лет в разработке решил наконец завести канал и делиться своим опытом, как профессиональным так и житейским. Сейчас активно программирую на Go и каждый день сталкиваюсь с интересными техническими задачами.

В канале буду рассказывать про:
- Реальные инсайды из ежедневной разработки
- Работу с Go в энтерпрайз проектах
- Свой вклад в опен-сорс
- Фейлы и то, как их исправляли (сломали, починили, сломали)

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

Добро пожаловать! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
В 34 года наконец-то принял: аниме — это не стыдно

Долго был скептиком. В детстве начинал Наруто — бросил. Блич — тоже. Ванпанчмен уже взрослым смотрел, но считал исключением.

Всё изменил "Клинок, рассекающий демонов" — настоящий шедевр во всём: рисовка, звук, сюжет, идея. После него понеслось: Рубеж Шангри-Ла, Поднятие уровня в одиночку, О моем перерождении в слизь. С женой даже Монолог фармацевта посмотрели!

В разработке точно так же. Вспомни сколько раз ты отвергал технологии без честной попытки? "Go слишком простой", "Kubernetes избыточен", "микросервисы — хайп". А потом один проект меняет всё восприятие.

Мораль: не стоит ко всему относиться скептически. Иногда нужно дать честный шанс — может приятно удивить.

P.S. На постере изображен я, вчера на очередном тренинге по изучению международных стандартов для медицинских систем.
🔥2❤1
Как штурм идей превращается в штурм методологий

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

А когда подключился еще один участник с предложением "сначала определиться с принципами определения подходов"... тут процесс окончательно ушел в философский сюрреализм 😄

Ощущения похожи на те что получаешь во сне, когда ты пытаешься бежать, а ноги вязнут. Сколько бы сил ты не прилагал, бежать все никак не получается и убежать/добижать так и не удается.

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

Наблюдение
Предложения по улучшению процесса - это хорошо. Но есть время и место. Менять правила игры прямо во время игры - это как редактировать сценарий фильма прямо на съемочной площадке.

Что работает
- План встречи фиксируем до старта
- Роли и правила озвучиваем в начале
- Методологические предложения собираем для следующего раза
- Держим фокус на изначальной цели

Хороший мозговой штурм - это дисциплинированное творчество, а не творческая анархия.

P.S. Детали истории изменены, но смысл остался 🕵🏻‍♂️
🔥1
Как офисная культура адаптируется под редкую удаленку

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

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

Ответ оказался простым: дело не в процессах, а в людях. Коллеги подключили меня через Google Meet и вывели на тот же большой экран, вместо JIRA. В итоге я стоял в кругу вместе со всеми, просто через монитор. Полное ощущение присутствия в команде, как будто физически был рядом.

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

Правильная команда не ломает устоявшиеся традиции ради одного удаленного участника, а находит способ органично включить его в существующий ритм.

Спасибо ребята за то, что даже удаленная работа с вами ощущается естественно! 💙
❤1
"Spring разработчики" и нужно ли их бояться?

На прошлой неделе был в походе, где с руководителем департамента разгорелась интересная дискуссия. Его позиция жесткая: большинство современных разработчиков деградируют. Они умеют только бизнес-логику писать, а как всё работает под капотом - не понимают. Spring или Laravel разработчики, нет никакой разницы, идея в том что фреймворк всю работу берет на себя и инженерная экспертиза пропадает.

Свежий пример из жизни: соседняя команда неделю билась с проблемой - база данных неадекватно жрала CPU. Не могли понять в чём дело, попросили парня из моей команды помочь. Тот за полчаса локализовал проблему благодаря пониманию архитектуры БД и навыкам инцидент-менеджмента.

Моя позиция кардинально другая: а что здесь плохого? Проблема не в разработчиках, а в составе команды. Нет 1-2 сильных специалистов - вот и весь корень зла. Остальные пусть спокойно пишут бизнес-логику под контролем code review старших товарищей. Такие разработчики рынку тоже очень нужны. Бизнесу важна в первую очередь скорость для быстрого результата, а о эффективности и оптимизации продукта можно подумать потом. Ну или нанять дорогого, бородатого интроверта, пусть он думает.

Думаю, мы оба правы, просто смотрим на ситуацию с разных сторон. Это обычная эволюция профессии. Если ты не успеваешь развиваться - тебя заменят инструменты или те, кто успевают. К томуже AI уже дышит в спину некомпетентным «коллегам».
⚡1🔥1
Как не превратиться в упертого старика-разработчика 🧠

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

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

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

Что не зашло:
❌ Белая тема системы. пробовал трижды, глаза до сих пор в шоке. Но не сдаюсь 😄

Главное понять, что пользу многих вещей понимаешь только спустя время. В первые дни работает правило "где заканчиваются силы, начинается характер". По этому стоит давать себе время на то чтобы привыкнуть.
🔥3👍1
Datomic база данных с философией

Недавно слушал подкаст, где обсуждали базу данных Datomic, якобы она рок-звезда среди всех БД со своей интересной философией. Мне стало настолько интересно, что последние дни провёл в теоретическом знакомстве, и остался в лёгком когнитивном шоке (в хорошем смысле).

Во-первых, она не удаляет данные. Никогда. Вообще! Каждая транзакция - это не просто "обновление", а добавление нового факта во временной поток. Получается встроенный time-travel: можно спросить у базы, как она выглядела на прошлой неделе в 17:42, и она честно ответит. Для задач с историей, аудитом и регуляторными требованиями - золото.

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

Datalog (язык запросов) тоже порадовал - что-то между SQL и Прологом, но ближе к логическому мышлению. Особенно хорошо ложится в проекты на Clojure. И вот тут начинаются минусы...
👉 В Go мире Datomic - как гость с другого континента. Нет нативной библиотеки, всё взаимодействие только через REST или EDN. То есть, хочешь использовать - ставь JVM, пиши прослойку, парси EDN. В общем, костыли.
👉 Datomic плохо подходит под высоконагруженные сценарии с частыми записями. Один транзактор = одна очередь. Не жужжит как Kafka, увы.
👉 И главный вопрос: а тебе точно нужна вечная история всех данных? Если да - это шанс. Если нет - может, стоит просто логировать изменения в Postgres.

💡 В целом, Datomic - как японская керамика: красиво, нестандартно, требует уважения к философии. Но чашку кофе в неё не нальёшь, если ты пишешь микросервисы на Go и хочешь всё просто.
Оставлю пока как архитектурную идею и источник вдохновения. А вдруг когда-нибудь соберусь на проект с Clojure и решу пожить немного вне времени 😉

P.S. Если интересно расскажу подробнее в следующих постах: про плюсы/минусы или как это всё сравнивается с Mongo и PostgreSQL?
🔥3
🎮 Clair Obscure: Expedition 33 - игра, о которой я чуть было не забыл рассказать.

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

Когда покупал Clair Obscure: Expedition 33, ожидания были завышены до предела. Про игру много говорили в подкастах: кто-то восторгался, а кто-то ворчал, мол, «слишком пафосно». Я всё-таки решил рискнуть, и вот мой вердикт: она превзошла даже мои, казалось бы, нереалистично высокие ожидания.

Clair Obscure - это просто визуальный, музыкальный и сюжетный экстаз! Причём не из разряда «вау, красиво», а именно гармоничный и выверенный до мелочей. Каждый кадр - отдельная картина, музыка идеально дополняет сюжет, а персонажи настолько колоритные и живые, что запоминаются сразу и надолго. Каждый уникален, причём именно с большой буквы.

Да, кто-то жаловался, что всё слишком серьёзно и театрально. Но лично я этого даже не почувствовал. Когда попадаешь в деревню жестралей, вся эта «театральность» мгновенно рассеивается. Ты просто сидишь, наблюдаешь за местными жителями, разговариваешь с ними, смеёшься вслух и совершенно не хочешь уходить. Хочется исследовать каждый уголок и погрузиться в эту атмосферу ещё глубже.

И главный инсайд напоследок:

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

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

P.S. Я выбрал концовку Версо. На мой взгляд это было справедливо по отношению ко всем.
🔥4
Системный подход к проблеме энергии: тестирую гипотезы на себе

Четвертую неделю экспериментирую с утренними силовыми тренировками в 7 утра. Гипотеза простая: если начать день с физической нагрузки, энергии хватит до самого вечера.
Пока результаты впечатляют. К концу рабочего дня сохраняю почти утреннюю эффективность в коде и ревью (хотя с ревью по честному получается хуже). После обеда обычно "плыл", а сейчас остаюсь в тонусе.

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

А как вы боретесь с энергетическими провалами в течение дня? 💪
🔥5👍1
Критика - это опасность или сигнал роста?

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

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

Результат: вместо ожидаемых 15 минут, митинг затянулся на час. После вопроса "Получилось сделать быстрее?" получил обвинение в токсичности.

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

Зрелость команды измеряется не отсутствием ошибок, а способностью их признавать и исправлять. Критика - это не враг, это компас для роста 🧭

P.S. Обложка поста: старая форма разрушается, давая рост новой жизни.
❤4⚡1
Как "очередное обучение" оказалось "особенным".

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

К нам приехал Вадим Перетокин - специалист из Швеции. С первых минут стало понятно, что это не "лектор", это гик в самом хорошем смысле. У человека Linux на ноутбуке, и не просто какой-нибудь Lenovo, а самостоятельно собранный Framework. Причем не ради фетиша, он реально коммитит в open source, продвигает FHIR по всему миру и живет этой идеей.
Интенсив прошел как на одном дыхании: мы не просто разобрали стандарт, а поняли, зачем он нужен и какие реальные проблемы решает.

Особенно порадовало, что Вадим постоянно выносил нас из теории в реалии: примеры, кейсы, и дальше несколько локальных шуток в квизах. Радует что пользу получили не только разработчики, но и люди далекие от разработки.
К середине недели стало ощущение, что мы не просто учимся, а участвуем в чем-то большем.
И тут случился вообще неожиданный момент. Вадим связался с самим Грэмом Гривом, создателем стандарта FHIR, и рассказал ему про наш прогресс. И… Грэм заинтересовался. Он реально выразил желание поддержать наш проект, а возможно и приехать.
А теперь просто вдумайтесь: Центральная Азия, Узбекистан, команда разработчиков и к нам едет один из самых влиятельных людей в digital healthcare.

Вот так скепсис превращается в мотивацию, а интенсив в шаг на мировую арену 👀 Может быть в следующем году мы даже выступим на DevDays и расскажем о своих успехах.
🔥5
Повышение, от которого стало тревожно.

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

Если тебе предложили подобное повышение, то это может вызывать тревогу. Особенно если ты впервые сталкиваешься с таким шагом. Ты вроде бы силён в своём деле, тебя ценят, а внутри мысли: «А если не справлюсь?», «А если выгорю?», «А если меня не будут слушать?».

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

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

Мой вывод простой:
- Если боишься - не бойся.
- Если не хочешь - откажись.

Ну и да, даже если сам пока не уверен знай, кто-то в тебя уже верит. Как минимум твой руководитель, ведь он не просто так предлагает тебе вырасти.
💯1