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

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

https://docs.google.com/forms/d/e/1FAIpQLScEsxsoXl_7R4aD5F8-B7fCCBVwU_BXBaOVJsKszbFyRHRkkw/viewform

Планирую выступать на JPoint в июне. Опять с своей любимой многопоточностью.
Ссылка: https://jpoint.ru/talks/82e4c9067a0fae2844e9d6dbc47023f1/
если вдруг кто будет из подписчиков там - буду рад любому фидбеку ну и вопросам, а если вдруг есть идеи/вопросы заранее - буду рад если зададите, а я смогу доработать доклад чтоб было интереснее и мне и вам.

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

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

Я приглашаю вас на запланированную встречу в Zoom.

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

Хотели бы послушать про бамбуковые спецификации? 😏

Упали тесты после замены

private static final Map<String, Validator> VALIDATORS = new HashMap<>();
static {
VALIDATORS.put("US", new StatesUSCodeValidator());
}

на

private static final Map<String, Validator> VALIDATORS = Map.of(
"US", new StatesUSCodeValidator()
);


угадаете в чем разница?

Ребята, а есть кто-то с очень хорошим английским?

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

Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.

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

https://hackernoon.com/principles-of-a-clean-relational-database

Пару недель назад вышел подкаст со мной на Javaswag. Бегом бронировать полтора часа на послушать разговор за Java, Clean code и собеседования 😏

https://soundcloud.com/javaswag/e34

В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях

00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind

Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI

Гость - https://t.me/Hcd5opza9bdcjid26fg

Кип сейф! 🖖

Вчера был мой 4ый рабочий день на новой работе. Вкратце как проходит онбординг:
день 1 - вводный колл с тиммейтом, получение ноута в середине рабочего дня, небольшая настройка
день 2 - еще пара коллов на полтора часа по онбордингу, изучение всяких онборд доков и настройка доступов, в конце дня получил ключик к репозиторию, стянул основную репу, поковырялся в ней
день 3 - прошел несколько онборд тренингов, получил первую таску (причем по фронтенду, с которым я никогда не работал). стянул фроненд репу, тиммейт помог быстро его запустить, начал разбираться и шерстить как это сделать
день 4 - закончил онборд тренинги, доразбирался с таской, тиммейт помог поправить пару косяков, создал PR, прошел ревью, нажал merge, через полчаса таска уже в продакшене.

Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂

В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.

По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.

В следующих постах раскрою подробнее каждый пункт.

CV - Responsibilities vs Achievements

Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.

Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.

English

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

Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.

Что делать, если хотите работать на западном рынке? Учите английский.

В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.

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

Value

И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.

Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries

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

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

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

Dependency Inversion для процессов разработки

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

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

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

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

Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.

На прошлой неделе схлестнулись мы с коллегами по одной теме о том, как же правильно писать компоненты на React, я из-за некоторых болячек пересмотрел подходы к базовому паттерну в проекте и имплементировал кое-что попроще (с моей точки зрения), но коллегам не нравилось это, хотя альтернативы были хуже и экстремальнее (с моей точки зрения). А их только одна небольшая деталь в общем-то не устраивала, но как ее сделать правильно ни я, с 6 месяцами опыта на реакте, ни кто-нибудь из них не втыкали. Вот так и просидели 4 мидло-сениора три часа на коле ничего не решив и только проспорив про подходы.

А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".

А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli