Всем доброе утро, на этой неделе с вами очередной Петя (@xd720p) из Redmadrobot SPB. В отличие от предыдущего Пети (@petertretyakov) из нашей компании, я занимаюсь Android разработкой. И также состою в программном комитете Mobius

Пока вы просыпаетесь и с теплотой и грустью вспоминаете офисную кофемашину, держите план на эту неделю:

-Как и зачем начать выступать на конференциях?

-Внутренняя кухня программного комитета

-Опыт первых месяцев лидства на проекте

-Этичность разрабатываемых приложений

(1/2)

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

Итак, знакомство)

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

Не стесняйтесь по ходу рассказа задавать вопросы)

Если вы вдруг почему-то не знаете чем мы занимаемся - мы аутсорсим мобильные приложения, поэтому ядро команды это iOs и Android разработчики. Нас в среднем по 12 человек на каждую платформу. В данный момент в команде Android над несколькими проектами трудятся 11 человек

На каждом проекте есть лид, который отвечает за проект, и один или несколько разработчиков в зависимости от сложности проекта: в среднем по 2 человека на проект, но есть и жадные проекты, которые могут съедать до 4-5 человек в свои самые активные стадии развития

Я в данный момент лидствую над Android приложением Альфастрахования - если вы им пользуетесь и у вас от чего-нибудь горит жопа, пишите мне в телеграмм (тоже xd720p), поставим вашу боль на карандашик

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

Помимо лидов на проектах, есть один тимлид, чтобы править всеми. Он занимается 1-to-1, организует внутренние митапы, следит за командой и проектами, чтобы люди не выгорали и развивались. При этом никого не тащат силком развиваться в сеньоры, лиды, качать T-shape и так далее

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

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

Чем заменяешь кофе из кофемашины в условиях самоизоляции?

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

Как я писал выше - мы аутсорсеры, но я считаю наш аутсорс очень близким к продуктовой разработке потому что мы ведём проекты по несколько лет. Например, моему проекту стукнуло уже 5 лет. И это позволяет избавиться от главной проблемы аутсорса - Huyak&VProductionDrivenDevelopment

Могу дальше рассказать как раз про технологии и архитектуру, которые используем на проекте или уже перейти к рассказу про выступления на конференциях

Поехали про используемые у нас технологии. Подход к архитектуре - стремимся в Clean Architecture, но используем архитектуру для решения проблем, а не просто следуем заповедям. Архитектура ради архитектуры - это непозволительная роскошь в продовской разработке

Например, использование RxJava в разных слоях Clean Architecture - это неправильно, а данные при передаче между слоями нужно маппить. Но из-за этого возникает огромное дублирование кода и другие проблемы. Подробнее про такие штуки тут - habr.com/ru/company/mob…

На уровне с UI используем MVP, а именно Moxy причём которая от Arello-Mobile, а не новую moxy-community. В планах попробовать новую moxy, а вообще хочется потрогать MVVM и понять стоит ли тащить это сейчас в продовские проекты или рановато

@pro2on - отвечаю на твой вопрос)

Для запросов, обработки различных событий и тп используем RxJava 2. Буквально пару недель назад в отдельной ветке мигрировал проект на RxJava 3 и решил откатиться обратно по многим причинам, которые опишу далее

Как обновление в вакууме новая версия RxJava выглядит вполне логичной: всевозможные старые операторы добавили для всевозможных классов - если раньше вы хотели в Maybe использовать какой-нибудь оператор, применимый к Single, которого не было в Maybe, то RxJava 3 вас обрадует

Также глобальный ErrorHandler научился отлавливать ошибки из цепочек, где происходит race condition, и из цепочек с внутренними потоками данных, когда внешний поток, например, откладывает ошибки до завершения как в данном примере: pic.twitter.com/66rZ9MXUPy

Дальше начинаются спорные для Android разработчиков моменты. RxJava 3 теперь поддерживает Java 8 API, а именно Stream, Function, Optional и теперь можно работать с Observable как со Stream, а потом снова возвращать Observable, создавать Maybe из Optional, но есть один нюанс: pic.twitter.com/X8QvhcMs06

То есть необходимо поднять minSdk, чтобы на все 100 воспользоваться RxJava3. Если ваше приложение выходит в России, то у нас по версиям Android всё неплохо и обновление не получат только 10% пользователей, если же вы работаете и на азиатский рынок - теряйте все 20% пользователей

Иными словами Android SDK как бы немного отстаёт от Java. При этом сейчас основной язык разработки под Android - Kotlin, где уже реализовано подобие Java Stream с бОльшим количеством операторов, без необходимости конвертации списков в Stream и обратно и зависимости от minSdk

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

Какие либы до сих пор на RxJava 2 и непонятно когда переедут на RxJava 3:

• RxRelay
• ReactiveLocationProvider
• RxBindings
• Любая другая библиотека, завязанная на RxJava 2

Для решения этой проблемы на помощь спешит - github.com/akarnokd/RxJav…

Но при этом ваш код покроется огромным количеством методов для конвертации одной RxJava в другую. И придётся при написании нового кода постоянно поддерживать между собой старую-новую версию RxJava pic.twitter.com/Sn0YcchhWq

Ах да, ещё в RxJava 3 перелопатили структуру пакетов, поэтому у вас уйдёт несколько часов на исправление всех импортов: pic.twitter.com/XjF2z8bARW

И ещё один нюанс, который выстрелит вам в ногу как только вы наконец-таки соберёте проект. Приложение с вероятностью 99.9% упадёт при первом запросе в интернет потому что ретрофитовский адаптер пытается конвертнуть Call в RxJava2 Single, а не RxJava 3

Исправляется либо написанием своего адаптера, либо затаскиванием адаптера от David Karnok - github.com/akarnokd/RxJav…

В итоге Если вы Android разработчик, то сейчас переходить на RxJava 3 не нужно, потому что это принесёт вам кучу проблем при миграции и не добавит каких-то жизненно необходимых фичей. Отсюда возникла мысль, что, может быть, время Rx на Android прошло и пора попробовать Flow

pic.twitter.com/y5ljup7u8o

Вообще я рассказывал про используемые у нас технологии, просто про RxJava 3 наболело и меня понесло.

Для навигации между экранами используем Cicerone. Для поддержки различных типов списков юзаем AdapterDelegates. Из того, о чём хотел рассказать про технологии у нас, вроде всё

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

Это не запрещает экспериментировать на проектах. У нас есть проект, где используются корутины, один проект написан на Flutter, ещё в одном пытались написать бизнес-логику на Kotlin MPP. После экспериментов мы обычно собираем внутренний митап, чтобы поделиться опытом с коллегами

Опрос к предстоящей теме про выступления на конференциях.

Выступаешь?

Итак, по результатам вчерашнего опроса 70.95 людей хотят выступать, аж 101.91 не выступают и не планируют, 23.92 уже выступают и нашлось целых 4 и 0.02 человека, которые выступают, но хотят остановиться и остальные пол-человека потерялось на офигительных округлениях

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

Что мешало лично мне:

И ещё пара пунктов:

Начнём с наверное самых распространённых проблем: мне не о чем рассказывать, обо всём интересном уже рассказано и все уже всё знают. Это всё большая проблема поиска интересной для кого-либо темы. Решается такая тема работой в двух направлениях: поиск темы и поиск аудитории(sic!)

Откуда взять тему? Самый кайфовый вариант - из своего опыта на проекте. При этом не обязательно делать адский rocket science. У вас раньше на проекте было MVP, а вы переехали на гугловский MVVM? Хоть ваши вкусы и очень специфичны, напишите статью или расскажите об этом

Поделитесь с коллегами вашим опытом на внутреннем митапе:

• Это поможет коллегам понять как внедрить тот или иной подход на своём проекте

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

• Вам дадут фидбек и зададут вопросы свои люди

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

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

Мне даже интересно узнать чего именно больше ждут от конференций:

Помимо опыта с проекта можно взять какую-нибудь новую хайповую технологию, которую показали на Google I/O или KotlinConf, и также затащить её в боевой проект, но конечно же в отдельной ветке, не бегите это сразу в master пушить, иначе вы станете не инфлюенсером, а безработным

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

Но есть один нюанс: pic.twitter.com/BJZ5m5YIiL

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

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

Главный источник таких тем - ваш коллега-сеньор или тимтехлид. У них много опыта и достаточно широкий кругозор, чтобы задумываться о действительно интересных вещах в Android разработке, но мало времени, чтобы ещё сидеть и делать презентации на все интересующие их темы

Обобщая про поиск темы и где её рассказывать - начните с поиска тем на работе и выступайте перед коллегами. Можно организовать записи выступлений, чтобы можно было оценить себя со стороны и поделиться вашими митапами с остальными как это сделали мы - t.me/rmr_spb

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

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

Основная аудитория локальных митапов - джуны и миддлы. Также один из факторов - стоимость билета. Локальные митапы чаще всего бесплатные или почти бесплатные - туда приходят вообще все, кто может. Поэтому и ожидания от локальных митапов гораздо ниже чем от, например, Mobius.

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

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

Где-то между локальными конференциями и Mobius/Appsconf стоят конференции в духе Devfest: они платные, но дешевле; при этом собирают достаточно много людей и на них приезжают интересные доклады и спикеры не только из других городов, но и из других стран

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

При этом большинство слушателей - ваши коллеги из местных компаний и компаний вашего региона, то есть аудитория пересекается с аудиторией локальных митапов, но ожидания от конференции у них тут уже выше. Но вы уже тоже не лыком шиты и уже набили руку на локальных митапах;)

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

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

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

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

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

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

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

Если я пишу слишком часто, и вам это не нравится, бахните лайк - я начну тренировать лаконичность и писать реже

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

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

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

Потому что с огромной вероятностью вам накинут вопросов по вашей теме и по смежным(а почему вы выбрали гугловский MVVM против реализации MVP от Moxy?). И вряд ли на докладе про архитектуру вас начнут спрашивать как работает хешмапа или джавовский GC

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

Следующий страх - “Меня завалят вопросами”
Вы не на экзамене и даже не на собеседовании. Цель слушателей не завалить вас и даже не проверить ваши знания. Они пришли в первую очередь узнать что-либо новое и полезное для себя. Большинство вопросов можно описать так:

Технические вопросы:

Общие вопросы:

• Почему нам нужно воспользоваться именно тем, о чём ты рассказывал, а не другим устоявшимся вариантом?
• В чём практическая польза твоего доклада?
• Кому пригодится то, что вы рассказывали?

Такие вопросы возникают, если кто-то не убедился почему вы сделали круто

При этом есть шанс получить очень необычные вопросы от людей, которые мимокрокодилили и случайно забежали на ваш доклад: вопросы от фронтендеров, менеджеров и просто людей, которые не интересовались вашей темой до этого

Так что делать с вопросами-то?

Ваша цель предусмотреть большинство вопросов. Найдите слабые моменты своего доклада:

К сожалению, в одиночку продумать все моменты достаточно сложно, но если вы собираетесь выступить на крупной конференции, то с вопросами вам помогут в ПК. Также нужно рассказать ваш доклад вашим коллегам или знакомым из профессии - они накидают вам вопросов

Целитесь на не самые мелкие конференции? Расскажите ваш доклад в упрощённой форме с упущенными подробностями(чтобы не потерять эксклюзивность) на мелком митапе. В любом случае ваша цель до ключевого выступления уже собрать какой-нибудь фидбек по докладу

При этом после получения фидбеков есть два варианта:

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

Ну и серебряная пуля для ответов на вопросы - это честный ответ: “Спасибо за вопрос, отличное замечание, но в эту сторону я ещё не копал, обязательно изучу этот момент”. Аудитория вполне понимает и принимает такие ответы, но тут есть два правила:

Чего делать нельзя - отмахиваться от вопросов и игнорировать их. Если не смогли ответить на какой-нибудь вопрос на выступлении и нашли решение - поделитесь ответом в чатике конференции. Аналогично с ошибками в докладе - вас не съедят за ошибки, если вы расскажите как правильно

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

Я также хотел попасть конфу спикером. И также не мог придумать о чём рассказать. Но потом понял, что нужно всего-лишь……

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

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

Также на финальном этапе подготовки доклада я обнаружил огромный кусок кода, который упустил при подготовке - по нему можно было ещё подробнее рассказать про DiffUtil. И этот доклад с кучей косяков всё ещё доступен для всеобщей критики - youtube.com/watch?v=uhtYuv…

Огромный плюс иметь канал с записью митапов - их может увидеть кто-нибудь из организаторов или ПК конференций (или вам будет что скинуть, когда подаётесь на конфу). Мне очень сильно повезло - этот доклад увидел @int02h и предложил доработать доклад и выступить с ним на Appsconf.

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

Вышло около 6 прогонов с ПК. Спасибо, @nonewsss за то, что слушал все мои записи. Чтобы довести доклад до хорошего состояния, я провёл несколько десятков прогонов: рассказывал доклад стене, стиральной машине, в камеру ноутбука и под конец начал мучать прогонами своих знакомых.

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

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

Например, первые 19 прогонов всё ещё получалось полное говно, на котором уснут даже люди после 2 литров эспрессо. А вот на 20 прогон резко стало лучше и уже после этого начался плавный рост рассказа

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

В итоге я попал в митапную секцию Appsconf и выступил перед 40-60 людьми, что меньше чем в других залах, но поверьте, к моменту выступления у вас будет такое состояние, что вам для счастья хватит и 20 человек)

Несмотря на слабую практическую применимость моей темы(серьёзно, самое практически полезное, что вы узнаете, это что у DiffUtil есть флаг detectMoves), судя по отзывам и оценкам, большинству понравился доклад.
И, конечно, меня спросили про пользу доклада -youtube.com/watch?v=G05bQI…

После выступления нужно бежать подавать заявки на конференции в другие города и более мелкие конференции. Прикрепляйте к этим заявкам запись своего предыдущего выступления - это повысит ваши шансы. С одной темой можно кататься минимум сезон - пока она не надоест вам и всем вокруг

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

Чего вы не получите на своём первом(втором, третьем) выступлении:

• Бабло

• Личный бренд 80 уровня и тыщу подписчиков в твиттере

• Толпу поклонниц ваших выступлений(а вот поклонники могут появиться, гендерный баланс, всё такое)

• Приглашение вас спикером на следующий сезон

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

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

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

И ещё один небольшой хак. Когда посреди выступления вы забудете, что вы там рассказываете дальше, вам на помощь придёт бутылка с водой - никто не заметит, что вы тупите, пока пьёте воду. Это поможет вам отвлечься и собраться с мыслями. Поэтому моё первое выступление выглядело так pic.twitter.com/yJVdKBMOKa

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

Как ты стал лидом?

У меня ситуация “компании понадобился лид” возникала дважды:

Начну со второго случая потому что он менее экстремальный, и тут я стал лидом по-нормальному, а не “лидом на час”, пока компания судорожно ищет настоящего.
Что же меняется, когда становишься лидом? Пока идёт текущий спринт - ничего. Но когда начнётся планирование следующего...

Первое, что сразу высасывает из вас всё время - встречи. Помимо грумингов(дев-ревью) и планирований будет ещё миллион встреч на 15 минут обсудить какую-нибудь фичу с аналитиком, дизайнером, продактом. Если терпеть не можете встречи, одумайтесь, пока ещё не согласились на лидство

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

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

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

Это происходит из-за того, что ты привык писать код, а теперь у тебя новая область ответственности. Теперь сходить на встречу, обсудить задачу с аналитиком или UI с дизайнером - это твоя работа и твой непосредственный вклад в проект

Чтобы было легче увидеть результат дня(недели), я начал записывать в блокнот абсолютно всё, что делаю. Полчаса обсуждал с дизайнером UI? Записал в блокнот. Спланировал спринт? Записал в блокнот. Впервые за неделю исправил баг на две строки кода? Поплакал и записал в блокнот

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

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

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

Вашим спасательным кругом в таких ситуациях также будет документ с код стайлом на проекте - в любой ситуации можно сослаться на него и тогда обосновывать дискуссию/код придётся уже разработчику. У вас ещё нет документа с код-стайлом? Составьте его, облегчите себе жизнь)

Немного материалов, которые помогут вам выжить на код ревью

How to do a code review от гугла:
google.github.io/eng-practices/…

Кому удобно в формате видео, вот вам митапчик, построенный вокруг этой статьи:
youtube.com/watch?v=O4lcyG…

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

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

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

На другой платформе хотят сделать такую же фичу, которая была сделана у вас пару лет назад? Угадайте, кто будет подсказывать как эта фича делается)
В самые весёлые моменты ко мне выстраивалась очередь из трёх человек с разными вопросами

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

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

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

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

Что вы получите от лидства?

• Денюжку - но тут зависит от компании и вашей предыдущей позиций. Если вы были сеньором на 300 кк/сек, то вряд ли вам поднимут зарплату

• Новые обязанности и задачи. Это очень помогает, когда вы ощущаете, что засиделись над одними и теми же задачами

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

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

Интересное и очень холиварное выступление на эту тему- youtube.com/watch?v=wMuD9S…

Пятничного утра всем, сегодня расскажу про внутреннюю кухню программного комитета на примере ПК Mobius(думаю, тут многое похоже на другие крупные конференции): какими инструментами пользуемся, как проходит работа со спикерами и на что обращаем внимание при просмотре докладов pic.twitter.com/cMOgndeCM4

Всё начинается с подачи заявки спикером и нулевого созвона. Созвон длится в среднем 15 минут, и на нём спикер рассказывает о себе, о теме своего доклада и кратко раскрывает какие-то его ключевые моменты. Задача ПК на этом созвоне узнать следующую информацию:

(1/7) На какую аудиторию ориентирован доклад. Достаточно часто подают очень интересные доклады, которые просто не подходят для основной аудитории конференции - мобильные разработчики.

(2/7) Выступал ли спикер с этим докладом ранее? Крупным конфам очень важна эксклюзивность на доклады - не хотелось бы, чтобы доклад светился в публичном поле до конфы(локальные митапы не в счёт). При этом после конфы спикер может распоряжаться своим докладом по своему усмотрению

(3/7) В каком реальном проекте использовалось рассматриваемое в докладе? Возможно, это один из самых важных пунктов, который помогает отсеять пересказы документации и применение технологий на искусственных примерах, которые выводятся первой странице поискового запроса в гугле

(4/7) Актуальность доклада. Вы написали свою крутую библиотеку для реактивного подхода, когда есть RxJava и Flow? Нужно объяснить почему это нужно другим разработчикам прямо сейчас, а не 5 лет назад. Важно, чтобы доклад решал какую-нибудь вечную или актуальную сейчас проблему

(5/7) Практическая применимость доклада. Какие знания и практики сможет применить слушатель из вашего доклада в своих реальных проектах, узнает ли он интересные подробности применения хайповой технологии? Может, он сможет избавиться от каких-нибудь bad practices в своём коде?

(6/7) Длительность доклада. Аудитория на больших конфах настроена слушать длинные доклады 40-50 минут и с большим непониманием реагирует на доклады минут на 20-30. Для них на конфах отводятся митапные секции/BOFы - отличная площадка для старта выступлений на крупных конфах

(7/7) Есть ли у докладчика опыт выступлений. Кто-то умеет сходу рассказывать свои доклады интересно, у кого-то это получается хуже. Докладчикам без опыта выступлений, но с хорошим материалом, помогают в оттачивании навыков подачи материала.

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

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

Продолжаем про внутреннюю кухню ПК. Перед нулевым созвоном за каждым спикером закрепляется кто-нибудь из ПК: выбираем либо по интересу к тому или иному докладу; либо вызывается тот, кто хорошо шарит в теме доклада. Если оба пункта мимо, то в ход идёт великий рандом

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

Цель первого прогона - познакомиться непосредственно с докладом, чтобы понять подходит ли доклад для конференции и определить точки роста доклада. К этому этапу не обязательно иметь идеальную презентацию и идеальный рассказ на 40-50 минут - главное показать core часть доклада.

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

В целом после первого прогона доклады можно разделить на 3 категории:

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

Можно брать после доработки.

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

Доклад требует серьёзной доработки.

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

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

Доклады в программу принимаются поэтапно: примерно 30-50% программы формируется до закрытия CFP, остальная часть в течение 3 недель после закрытия подачи заявок. Поэтому чем раньше подаётся заявка, тем больше времени на проработку доклада => больше шансов попасть в программу

Всем хороших выходных в эти нерабочие дни! На неделе ушло много времени на треды про выступления, поэтому на выходных будет единый рассказ из нескольких тем: из ВУЗа в разработчики => как вкатиться в Android => аутсорс vs продукт => когда менять работу.

Зачем вы пошли в ВУЗ?

Твиттер не позволяет делать длинные описания для опросов, поэтому раскрою каждый пункт:

2. Мама сказала, что надо. Вы закончили 11 классов, потому что в ПТУ идут лохи, а каждый уважаемый себя человек должен получить высшее образование, если не хочет стать дворником. Кем вы хотите быть вы ещё не знаете, но точно не срочником.

3. Переезд в большой город. Мама сказала, что нужно пойти в ВУЗ, но вы начали подозревать, что ваш родной город вам как-то надоел как и жизнь с родителями под одной крышей. А вот большой город - больше возможностей и свобод, а ВУЗ даст вам почти бесплатное жильё и стипендию

4. Вы решили не продлевать своё состояние школьника ещё на 4-6 лет поступлением в ВУЗ и сразу приступили к этапу взрослой жизни. При этом вы лишили себя возможности ныть о бесполезности высшего образования, чтобы набирать классы от других дипломированных специалистов

Поэтому и пошёл на специальность "Программная инженерия" в надежде, что за 4 года меня из разработчика QBasic черепашки сделают разработчиком QBasic черепашки за 300 кк/сек. И ровно с этого момента начались жёсткие недопонимания между мной и ВУЗом

Студент вне зависимости от цели поступления в ВУЗ все же ожидает от ВУЗа получения скиллов для успешного устройства на работу после выпуска. Например, в ВУЗе он изучит современные направления продовской разработки: от сурового банковского бекенда до Android/iOs

Но, сорян, в 80-х не было ваших Android и iOs, зато был ассемблер. Поэтому у нас было аж три семестра изучения программирования на ассемблере, из которых целый семестр мы писали код на ассемблере под систему z/OS, о которой вы сейчас слышите впервые и больше никогда не услышите.

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

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

Это огромная ошибка с нашей стороны, потому что среди кучи ненужных и устаревших предметов примерно треть дают отличную базу для будущего трудоустройства, а вместо получения знаний мы просто начали делать отчёты по лабам, когда поняли, что ВУЗ интересуют подписанные бумажки

И с забиванием на получение знаний я упустил такие важные темы как:

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

Самые интересные лекции и практики и самые полезные знания мы получили от преподавателей-практиков. Не тех, кто безвылазно просидел в вузе последние 30 лет и вписывал своё имя в студенческие работы, набивая себе количество научных публикаций

А тех, кто совмещал преподавание с работой, смог вытащить нас из состояния вечного студента и заинтересовать в реальной разработке. И к моему выпуску таких преподавателей на кафедре становилось больше. Возможно лет через 10 в твиттерах начнут советовать всем поступать в ВУЗы

И я не пытаюсь этим сказать, что "ВУЗ - говно, не идите в ВУЗ". Тут дело именно в том, что студент хочет от ВУЗа то, чего ВУЗ не даёт, а ВУЗ ничего не знает про современный IT рынок и что за написание отчётов денег уже никто не платит. И иногда и правда лучше пройти курсы

После которых вы попадёте на целый год курсов по покраске травы и заправлению кроватей, но это совсем другая история

Что же реально ВУЗ даёт и что не так просто заметить с первого взгляда: переезд, связи, жизнь без армейки, базовые знания и мифическое умение учиться

1. Переезд. Поступление в ВУЗ - это самый дешёвый способ перебраться в другой город для бывшего школьника. Дешёвое жильё, стипендия в зависимости от успеваемости(да она очень маленькая, но всё же) и 10к от родителей на месяц, пока вы не захотите заработать себе ещё денег

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

4. Базовые знания, которые помогут углубиться в конкретную область IT, к счастью ещё не успели устареть.

Нужно ли идти в ВУЗ? Думаю, что в текущих российских реалиях ВУЗ даёт крутую базу для развития, но не в тех областях, которые я от него ожидал изначально. Не получится просто учиться по ВУЗовской программе и сразу вбежать на уровень хотя бы Junior разработчика

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

На этом перейду как раз к вкатыванию в Android разработку, хватит уже пинать наше остывающее высшее образование)

Когда я начинал изучать Android в 2016 году, все рекомендации сводились к изучению Java и Activity Lifecycle, после чего можно было отправляться делать своё приложение метчы.

Как выглядят очень настойчивые рекомендации гугла для юных андроид разработчиков сейчас: pic.twitter.com/HLehFwaXRK

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

После первого приложения, где запросы летят из Activity, а при повороте экрана оно крашится, уже есть смысл изучить всякие MVP и MVVM

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

После переезда на Kotlin, обратно на Java не хочу. Стоит учитывать, что в Android разработке не используется вся мощь Java 8. Но после некоторых танцев с бубном и desugaring можно и Stream, и остальное заюзать. А вот без танцев с бубном это всё уже есть в Kotlin, да ещё и удобнее pic.twitter.com/5xuLycJM22

Итак, к воскресенью закончили ВУЗ, вкатились в Android и пора определиться где лучше работать: в аутсорс разработке или продуктовой разработке?

Лучше работать в продуктовой разработке

Всем спасибо, всем хороших выходных

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

1. Проще влиять на сам продукт и на техническую часть: хотите Корутины? Дядя-заказчик не скажет “ой, на это у нас нет бюджетов, нам надо ещё 20 новых кнопочек покрасить, чтобы поднять retention”. Появилась идея для фичи? Вам не нужно убеждать менеджера продавать её заказчику

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

Но и аутсорс разработка предлагает пару интересных фишек:

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

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

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

Когда следует увольняться?
Если вам перестали платить зарплату и начали кормить обещаниями "через 2 недели", "пойми, сейчас всем тяжело". Это дикое капитанство, но всё равно куча людей продолжает работать в течение нескольких месяцев за бесплатно.

Я сталкивался с таким дважды и оба раза не уходил из-за огромных сомнений в том, что моего скилла хватит найти новую работу. В первом случае я два месяца просидел без зарплаты. Причём ситуация доходила до такого дикого абсурда, что
(1/2)

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

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

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

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

Следующая причина сменить работу: вы каждый вечер рассказываете домашним как на работе вы катаетесь на горящем велосипеде, всё вокруг горит и вы в аду. Это ни разу не нормально и дружная команда вместе с большой зарплатой опять же не стоит выгорания 24/7 pic.twitter.com/OQqtG6nuGd

Или обратная ситуация, когда вокруг ничего не происходит и вы просто занимаетесь поддержкой старого приложения и пилите небольшие фичи: очередной экран с двумя кнопками. После пары лет такого опыта вы станете профнепригодным, потому что рынок бежит вперёд с большой скоростью pic.twitter.com/Fjju7DtdAQ

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

Например, если не отвечать на письмо на почте хорошему HRу, то к тебе в телеграмм придёт плохой HR и будет разговаривать с тобой совсем по-другому pic.twitter.com/WU1PEqHOgh

Когда у хорошего/плохого HR не получается схантить, то приходит HR-гопарь, который изучает твой стек технологий по понятиям pic.twitter.com/sKQsdv5Afr

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

Тесты на мотивацию!

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

Что Вас больше замотивирует выполнить сложное сверхурочное задание?

Если бы Вы были руководителем, то какой способ награды вы бы использовали?

1. премия
2. награждение званием «Лучший…» и публичная похвала
3. дал бы большую свободу в действиях
4. включил бы в состав группы, участвующей в принятии важных решений

Это уже back to USSR прям

Какую компанию Вы скорее выберете?

1. где больше платят
2. где лучше коллектив
3. где будут интересные для вас задачи
4. с которой совпадут ваши убеждения и ценности

То есть при устройстве в конкретную компанию у вас спрашивают в какой компании вы хотели бы работать ¯\_(ツ)_/¯

С каким руководителем Вам бы НЕ хотелось работать?

Что бы вы хотели получить от продвижения по карьерной лестнице?

1. хорошие деньги
2. признание
3. свободу
4. возможность влиять на развитие компании

Повышение зарплаты раз в 5 лет, а вот свободу можно получить только в Юрьев день

На ваш взгляд хороший руководитель это тот, кто

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

Наиболее значимое для вас слово

Ну и лучший вопрос

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

Какой из этого вывод?
Хорошо, что наш айтишный рынок умудряется создавать такое огромное и разнообразное количество тем на покекать.
Не вижу смысла относиться к этому всему серьёзно и бежать строчить миллион статей на ebanoe.ит о том как всё ужасно плохо и не профессионально pic.twitter.com/sE1ZHIIFQT

На этом моя неделя подошла к концу. Надеюсь, мой опыт и мои кулстори были вам интересны и даже в чём-то полезны, а мемы заставили вас знатно покекать(how do you do, fellow kids?)

В телеграмах и твиттерах меня можно найти по нику xd720p

Всех люблю pic.twitter.com/gV20Jnw4as