Встреча-обсуждение Sensible Defaults 15 Июля (ПН) 19:00

В следующий Понедельник, 15 Июля в 19:00 собираемся на стрим обсуждать Sensible Defaults: кодекс поведения четких разработчиков.
В этот раз начнем с разрабов, секьюрити и девопса
Формат: Встрерча в Zoom, бурное обсуждение. Лимит 1.5 часа, приносить свое пиво, чай, кофе. Приготовьтесь живо участвовать в обсуждении!

Записываться у бота

Кто уже в последних 14%? Мы вот уже близко.

Сережа, правда, на бахчу еще не согласен. Видимо не довыгорел еще

Новый поток курса Разработка без боли и сожалений. стартует уже 26 июля!

- На нем детеально разбираем DDD на реальном коммерческом проекте,
- Разбираем как чистая Архитектура работает в настоящем приложени.
- На созвонах в Зуме разбираем сложные темы такие как TDD, построение CI
- Работаем с настоящим экпсертом на event storming’е

До 26 июля скида 20т.р.
Записываться тут!
По возникшим вопросам обращаться к @dubrova_a
Увидимся!

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

Главная особенность. Когда что-то идёт не так, суетолог не разбирается в причинах и обстоятельствах, а сразу начинает паниковать, дергаться и наводить суету.

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

Пример 1. Человек написал код, и у него вдруг перестал проходить сквозной GUI-тест. В тесте написано: тут таймаут, кнопку не видим.
Но вместо того, чтобы посмотреть скриншот и зайти в приложение, начинается перезапуск тестов 1000 раз, попытки откатить код и т.д. без попыток понять, что происходит и в чем дело. А дело было в протухшем токене от внешней интеграции, что диагностируется за 10 секунд.

Пример 2. «А-а-а! Локальный стенд не работает» и те же самые телодвижения. А надо было всего лишь внимательно почитать лог запуска и в последней строке увидеть, что у докера закончилось место.

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

До Thoughtworks Сингапура докатился кризис, и меня сократили.

Реалити-шоу “Сможет ли Сережа найти работу за 2 месяца” начинается!

Через 2 месяца я обязан забрать детей из школы, сдать квартиру и покинуть Сингапур. Или найти новую работу. :)

Буду вести трансляцию в канале!

Впечатления пока следующие:

• Откликаться на вакансии – дело очень утомительное и бесполезное. Пока 0 собеседований. Как только вакансия открывается, в первый же день туда поступает более 100 заявок.
• Networking работает. Если видишь открытую вакансию и можешь найти хоть кого-то, кто может напрямую закинуть твоё резюме HR’у, то шансы попасть на собеседование возрастают на порядок (да, в 10 раз). А если вас могут ещё и порекомендовать, то это увеличивает шансы прийти на интервью практически до 100%.

1 августа 19:00 по мск “Learning Domain-Driven Design Часть II. Тактический замысел (Глава 5-7) / Евгений Лукьянов”

Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие программному коду «говорить» на едином языке ограниченного контекста. В этих главах обсуждаются простые паттерны, такие как транзакционный сценарий и активная запись (глава 5), сложные паттерны, такие как модель предметной области (глава 6), и её расширение с учётом фактора времени (глава 7).

Помогать в обсуждение нам будет - Евгений Лукьянов 🔥 Архитектор ПО, практикующий адепт DDD. Ведет канал https://www.group-telegram.com/stringconcat.com

Подключайтесь в четверг в 19:00 к обсуждению в Zoom или к YouTube трансляции

А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Жене ⤵️

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

Мои наблюдения за обстановкой на мировом рынке. Субъективно, но непредвзято.

1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.

2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.

3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.

4. Рекрутеры из Лондона радуются, что разрабов стало сильно проще искать. Соискатели теперь не просят офисы с массажистами, лишь бы хватало на жильё.

5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.

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

Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.

Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?

Первые 2,5 недели поиска работы из 8. Напоминаю, что я в Сингапуре, а поэтому через 8 недель безработного меня отсюда попрут.

Результаты
— Откликнулся на 25 вакансий, по рекомендациям — на 8
— Прошёл 15 собеседований
— Получил 0 (ноль) оферов

Выводы

Все колотят понты. Даже маленький стартап на 4 стула должен проводить не менее 5 раундов собеседований, иначе не солидно. Стандартный процесс: HR → вопросы по SOLID → кодинг-интервью → беседа с PM → беседа с основателем.
На контрасте видел рекламу Альфа-Банка: собеседуют в 2 этапа, а решение принимают за день. Молодцы!

Публичность помогает. Я поставил статус «Ищу работу» в LinkedIn и рассказал об этом друзьям и в соцсетях, в итоге мне передали контакты заинтересованных во мне людей.

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

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

Я ходил на собеседование в очень странный стартап. Как вы помните, я ищу работу, чтобы меня не попёрли из Сингапура, а потому хожу на всякие собеседования. Сегодня расскажу о беседе с Head of Product, который раньше работал в Гугле.

Перед собеседованием HR предупредил меня, что на этом этапе срезается большинство разработчиков, поскольку продукту не интересны истории о смене одной БД на другую. Это внушало оптимизм. Ещё впечатляло, что в стартапе работали ребята 35–50, от 10 лет в профильной отрасли. Большинство успело поработать в Google, BlackRock или Github. Поэтому было интересно посмотреть, как стратап строит найм таких специалистов.

Первое, что я услышал, было «наконец-то я вижу резюме, по которому видно что человек приносил пользу компании, а не кафки крутил». Следующий час я рассказывал истории как мы что-то улучшали в продукте, как мерили эти улучшения, а в конце ответа я не забывал спрашивать «а как у вас дела обстоят с этим?» Это было одно из лучших собеседований в моей жизни. Я вышел с пониманием что:

— Интервьюер читал моё резюме до собеседования, и оно ему пришлось по душе
— Я отвечал именно то, что хотел услышать интервьюер
— Я не потел, пытаясь вспомнить примеры из жизни, а просто доставал по одной из уже заранее заготовленных историй
— Правильно подготовил резюме, потому что перерыл кучу материала по подготовке резюме и провалидировал эти материалы с HR’ами и консультантами
— Лекция про behavior interview вполне рабочая: стоит записать по одной истории на каждый принцип, чтобы на собеседовании петь соловьём, а стрессовать и рефлексировать дома.

Вывод такой: чем сеньёристей люди, которым попадается резюме такого формата, тем больше они его ценят. Чтобы попасть на позицию рядового гребца, вам, конечно, такое резюме не обязательно, напишите java 5+ лет. Но если хочется попасть выше и зарабатывать много денег, то советую заглянуть на наш курс. Там не только про оформление резюме и собеседования, но и про выстраивание долгосрочной карьеры.

Хотел спросить, с чем вы больше всего испытывает трудности. Ставьте реакцию под постом, а мы подумаем, как вам помочь.
😱 Пройти кодинг интервью
😭 Пройти систем-дизайн интервью
❤️ Рассказать о своём опыте так, чтобы заслушались
😎 Как выбрать следующую компанию и не тратить ещё год в болотце
🙊 Другое, напишу в комментах

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

Мы обещали помочь, и вот наше предложение!

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

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

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

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

Что нужно сделать:
0. Важно: Участвовать могут только те, кто сейчас ищет работу или планирует сменить ее в ближайшие 2 месяца.
1. Оставить комментарий «Хочу карьерную консультацию».
2. Мы свяжемся с вами и отправим небольшую анкету.
3. По результатам анкетирования выберем 10 человек и назначим встречу.

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

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

Полюби легаси, %username%

Намедни листал вакансии (нет, меня пока ещё не попёрли), наткнулся на формулировку типа «проект не легаси» и задумался. В айтишной среде под легаси всегда понимают что-то плохое, древнее и такое тоскливо-мерзкое, что не хочется и палкой трогать.

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

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

Попадались ли вам такие артефакты? Верите ли вы в них? Становится ли мир лучше или будущее человечества мрачно и безысходно? Нам важно это знать

ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:

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

2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему

3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.

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

Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».

Как я получал оффер от банка

В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать.

В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но я тебя найду уже 3 человека сказали, что я обязан с тобой поговорить. Если нужна работа, приезжай в офис».

Первым рекомендателем оказался мой бывший коллега, Thoughtworker старой закалки. Он перешёл в этот банк несколько лет назад. Увидел мой пост и с утра пошёл к СТО сказать, что есть я, которого ещё вчера Thoughtworks предлагал им взять в аренду в 2 раза дороже, чем я сегодня стою.

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

Но их всех опередил мой бывший проджект-менеджер, который решил позвонить этому СТО ещё вечером накануне.

В итоге я пришёл на собеседование, где мне час рассказывали, как в банке что устроено, какие есть проблемы и как они видят будущее. Я сидел и думал, когда же начать рассказ о себе. Но хвататься расхотелось, когда СТО пожаловался, что обо мне ему уже все рассказали, и не один раз. Но бедный СТО не знал, что на следующий день его ждёт встреча с Омаром — директором финсектора Thoughtworks. Драматизм ситуации в том, что это человек, который может продать что угодно кому угодно. И именно у Омара я научился отвечать на вопросы клиента, когда напрямую ответить нельзя, и заражать клиента своими идеями. Омар встретился с СТО по другому вопросу, но тоже между делом искренне меня рекомендовал, так что у банка шансов не оставалось.

Вывод: личные контакты решают. Если у вас проблема — расскажите о ней, и помощь может прийти оттуда, откуда не ждали.

Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.

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

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

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

Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы

Несколько важных наблюдений

1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.

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

3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.

4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде

Практикуете на работе? Микросервисы уже внедрили?🙂