Архив недели @xd720p
Понедельник
Всем доброе утро, на этой неделе с вами очередной Петя (@xd720p) из Redmadrobot SPB. В отличие от предыдущего Пети (@petertretyakov) из нашей компании, я занимаюсь Android разработкой. И также состою в программном комитете Mobius
Пока вы просыпаетесь и с теплотой и грустью вспоминаете офисную кофемашину, держите план на эту неделю:
-Как и зачем начать выступать на конференциях?
-Внутренняя кухня программного комитета
-Опыт первых месяцев лидства на проекте
-Этичность разрабатываемых приложений
(1/2)
- Что же изучать для вкатывания в Android разработку?Старое против нового
- Из ВУЗа в настоящего разработчика
- Когда следует менять работу?
- Аутсорс разработка против продуктовой
- Немного странных вакансий и общений с HR
(2/2)
Мой план не коррелирует с днями недели: какие-то темы займут у меня больше одного дня, какие-то меньше. Некоторые из тем могут исчезнуть(вряд ли), могут добавиться новые темы(менее вряд ли) или преобразоваться старые. Но начнём с небольшого знакомства со мной и компанией)
На самом деле только один Петя из Redmadrobot настоящий. Мы пока не знаем, кто. Скорее всего iOS-Петя, конечно. twitter.com/mobileunderhoo…
Настоящий тот, кто работает на проекте Альфастрахования (мы оба там работаем) twitter.com/petertretyakov…
Итак, знакомство)
Про себя - в Android разработке чуть больше 3 лет. Про весь путь подробнее расскажу в треде про "из ВУЗа в настоящего разработчика", поэтому сразу перейду к рассказу про компанию
Не стесняйтесь по ходу рассказа задавать вопросы)
Если вы вдруг почему-то не знаете чем мы занимаемся - мы аутсорсим мобильные приложения, поэтому ядро команды это iOs и Android разработчики. Нас в среднем по 12 человек на каждую платформу. В данный момент в команде Android над несколькими проектами трудятся 11 человек
На каждом проекте есть лид, который отвечает за проект, и один или несколько разработчиков в зависимости от сложности проекта: в среднем по 2 человека на проект, но есть и жадные проекты, которые могут съедать до 4-5 человек в свои самые активные стадии развития
Я в данный момент лидствую над Android приложением Альфастрахования - если вы им пользуетесь и у вас от чего-нибудь горит жопа, пишите мне в телеграмм (тоже xd720p), поставим вашу боль на карандашик
Со мной на проекте трудится один разработчик - пока что наших сил хватает, чтобы активно развивать приложение даже в те моменты, когда лид проекта вместо разработки занимается твиттером
Помимо лидов на проектах, есть один тимлид, чтобы править всеми. Он занимается 1-to-1, организует внутренние митапы, следит за командой и проектами, чтобы люди не выгорали и развивались. При этом никого не тащат силком развиваться в сеньоры, лиды, качать T-shape и так далее
Если человек хорошо справляется со своими текущими задачами и в ближайшее время хочет заниматься именно разработкой на проекте, на него не будут косо смотреть или увольнять за то, что за последние полгода ты не стал пост-сеньором 80 уровня
При этом качество кода сохраняется за счёт одного из главного правил найма в Питерский офис RMR - разработчик должен быть не ниже middle. Это позволяет быть уверенным, что спустя несколько недель, человек будет справляться с разработкой на проекте без посторонней помощи
@mobileunderhood Эх, оффисная кофемашина... Помню как я нажимал на волшубную кнопку, она делала бжжж и выдавала мне топливо на следующие пару часов.
Я на дом купил jacobs millicano, он вроде не самый плохой на вкус. Некоторые друзья купили кофемолку и кофеварку - теперь учатся быть кофейным сомелье
Кто как спасается от нехватки великолепного свежего кофе из кофемашины? twitter.com/lionskape/stat…
Чем заменяешь кофе из кофемашины в условиях самоизоляции?
Также при необходимости или по желанию разработчика, он может стать лидом на проекте или вообще начать новый. Если разработчик чувствует, что начинает выгорать на текущем проекте - он сообщает об этом тимлиду и его могут перевести на другой проект
Как я писал выше - мы аутсорсеры, но я считаю наш аутсорс очень близким к продуктовой разработке потому что мы ведём проекты по несколько лет. Например, моему проекту стукнуло уже 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, и из цепочек с внутренними потоками данных, когда внешний поток, например, откладывает ошибки до завершения как в данном примере:
Дальше начинаются спорные для Android разработчиков моменты. RxJava 3 теперь поддерживает Java 8 API, а именно Stream, Function, Optional и теперь можно работать с Observable как со Stream, а потом снова возвращать Observable, создавать Maybe из Optional, но есть один нюанс:
То есть необходимо поднять 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
Ах да, ещё в RxJava 3 перелопатили структуру пакетов, поэтому у вас уйдёт несколько часов на исправление всех импортов:
И ещё один нюанс, который выстрелит вам в ногу как только вы наконец-таки соберёте проект. Приложение с вероятностью 99.9% упадёт при первом запросе в интернет потому что ретрофитовский адаптер пытается конвертнуть Call в RxJava2 Single, а не RxJava 3
Исправляется либо написанием своего адаптера, либо затаскиванием адаптера от David Karnok - github.com/akarnokd/RxJav…
В итоге Если вы Android разработчик, то сейчас переходить на RxJava 3 не нужно, потому что это принесёт вам кучу проблем при миграции и не добавит каких-то жизненно необходимых фичей. Отсюда возникла мысль, что, может быть, время Rx на Android прошло и пора попробовать Flow
Вообще я рассказывал про используемые у нас технологии, просто про RxJava 3 наболело и меня понесло.
Для навигации между экранами используем Cicerone. Для поддержки различных типов списков юзаем AdapterDelegates. Из того, о чём хотел рассказать про технологии у нас, вроде всё
То что я описал в этом треде - наш core стек технологий для разработки, который был собран методом проб и ошибок, чтобы понять, что именно такие подходы лучше всего подходят для разработки Android приложений в нашей компании
Это не запрещает экспериментировать на проектах. У нас есть проект, где используются корутины, один проект написан на Flutter, ещё в одном пытались написать бизнес-логику на Kotlin MPP. После экспериментов мы обычно собираем внутренний митап, чтобы поделиться опытом с коллегами
Для запросов, обработки различных событий и тп используем RxJava 2. Буквально пару недель назад в отдельной ветке мигрировал проект на RxJava 3 и решил откатиться обратно по многим причинам, которые опишу далее
Сегодня я рассказал про нашу компанию - twitter.com/mobileunderhoo…
Про наши технологии - twitter.com/mobileunderhoo…
Также накинул в сторону RxJava 3 - twitter.com/mobileunderhoo…
Сегодня напоследок закину опрос про выступления на конференциях - об этом и буду рассказывать завтра
Опрос к предстоящей теме про выступления на конференциях.
Выступаешь?
Вторник
Итак, по результатам вчерашнего опроса 70.95 людей хотят выступать, аж 101.91 не выступают и не планируют, 23.92 уже выступают и нашлось целых 4 и 0.02 человека, которые выступают, но хотят остановиться и остальные пол-человека потерялось на офигительных округлениях
Свой опыт выступлений начну со страхов и сомнений, потому что это первое с чем все сталкиваются и застревают на стадии "не выступаю, но хочу". Можете смело накидывать, что мешает именно вам: добавлю ваши сомнения к своему списку и постараюсь их все развеять!
Что мешало лично мне:
- Мне не о чем рассказать
- Обо всём интересном уже рассказано
- Я не умею интересно рассказывать
- Меня завалят вопросами, на которые я не смогу ответить, и каждый джуниор теперь будет знать моё имя как синоним термина "позор"
И ещё пара пунктов:
- Все уже всё знают, ничего нового не открою (понимаю тебя, @GkFoxes)
- Мне не хватает технических скиллов, чтобы получить право нести в массы свои гениальные идеи
- На выступления уйдёт так много времени, что я перестану быть разработчиком и стану инфоцыганом
Начнём с наверное самых распространённых проблем: мне не о чем рассказывать, обо всём интересном уже рассказано и все уже всё знают. Это всё большая проблема поиска интересной для кого-либо темы. Решается такая тема работой в двух направлениях: поиск темы и поиск аудитории(sic!)
Откуда взять тему? Самый кайфовый вариант - из своего опыта на проекте. При этом не обязательно делать адский rocket science. У вас раньше на проекте было MVP, а вы переехали на гугловский MVVM? Хоть ваши вкусы и очень специфичны, напишите статью или расскажите об этом
Поделитесь с коллегами вашим опытом на внутреннем митапе:
- Это поможет коллегам понять как внедрить тот или иной подход на своём проекте
- Вы получите опыт реального выступления. При этом среди своих не так страшно лажать
- Вам дадут фидбек и зададут вопросы свои люди
- Ваше выступление создаст профессиональное обсуждение внутри команды, кто-то ещё захочет рассказать о чём-нибудь
- Пока вы готовитесь к выступлению, вы структурируете полученные знания у себя в голове, возможно, найдёте какие-то баги или поймёте как можно сделать это лучше
В целом помимо личных выгод, вы поможете развитию коммьюнити внутри команды(если ваши коллеги не законченные душнилы), что поможет развитию ваших проектов и вас самих как разработчиков, а это даст ещё больше возможных тем для выступлений
После этого вы сможете доработать свой рассказ и податься на какой-нибудь локальный митап, на котором не требуется, чтобы вы были Android GDE. Выступать на локальном митапе страшнее, чем перед коллегами, зато вы получите новый опыт выступления уже перед незнакомыми людьми
Есть куча шоупрограммистов, которые больше готовятся к конференциям чем пишут код. Они нанимают дизайнеров для подготовки през, посещают курсы спикеров, надевают костюмы гэнальфа, и в целом толкают скорее стендап, нежели доклад. На их фоне, остальные выглядят скучно.
При этом из года в год я не перестаю слышать, что люди хотят больше технических докладов. Шоу это, конечно, весело и развлекательно, но материал шоу не применишь на своём проекте, из шоу ты не узнаешь что-то интересное для себя в профессиональном плане twitter.com/tygeddar/statu…
Мне даже интересно узнать чего именно больше ждут от конференций:
Когда ты все решаешь выступить. Ты убиваешь гигантскую прорву времени, что бы построить свой доклад, подготовить хоть какую то презу, репетируешь. Проще подцепить проект на фрилансе, на вырученные деньги купит билет на конфу и дать контекстную рекламу о себе в гугле.
К тому же никто не мешает нарядиться в гендальфа, посетить курсы спикеров и подать техническую тему как стендап. И да, подготовка доклада на большую конференцию требует огромное количество сил и времени - twitter.com/tygeddar/statu…
Помимо опыта с проекта можно взять какую-нибудь новую хайповую технологию, которую показали на Google I/O или KotlinConf, и также затащить её в боевой проект, но конечно же в отдельной ветке, не бегите это сразу в master пушить, иначе вы станете не инфлюенсером, а безработным
Казалось бы зачем рассказывать об опыте внедрения гугловской технологии, ведь сам Google так красиво рассказал о ней на своей конференции, показал примеры как это всё круто работает, заводится с пол-пинка и позволяет начать писать код даже вашей бабуле
Но есть один нюанс:
Только при попытке внедрения технологии в настоящий продовский проект вы сможете оценить саму технологию, а не её маркетинговые слоганы. Это болезненный опыт, который будет интересен вашим коллегам и другим разработчикам на митапе, а иногда даже и на большой конфе
Другой источник тем - ваши коллеги. У многих разработчиков есть список чего им хотелось бы попробовать или узнать, но до чего ещё не дошли руки. Найдите из этого то, что интересно и вам тоже и также расскажите на внутреннем митапе, затем доработайте и подайтесь на локальный митап
Главный источник таких тем - ваш коллега-сеньор или тимтехлид. У них много опыта и достаточно широкий кругозор, чтобы задумываться о действительно интересных вещах в Android разработке, но мало времени, чтобы ещё сидеть и делать презентации на все интересующие их темы
Обобщая про поиск темы и где её рассказывать - начните с поиска тем на работе и выступайте перед коллегами. Можно организовать записи выступлений, чтобы можно было оценить себя со стороны и поделиться вашими митапами с остальными как это сделали мы - t.me/rmr_spb
Даже после того как вы найдёте потенциальную тему - останется страх, что все вокруг уже это знают и вы не принесёте людям ничего нового. Чтобы не произошло такого казуса, нужно определиться с аудиторией вашего доклада:
Выступление внутри компании. Основная аудитория - ваши коллеги. Тут всё просто - вы знаете ваших коллег, вы знаете их грейды, вы можете уточнить у них, что им будет интересно будет послушать.
Основная аудитория локальных митапов - джуны и миддлы. Также один из факторов - стоимость билета. Локальные митапы чаще всего бесплатные или почти бесплатные - туда приходят вообще все, кто может. Поэтому и ожидания от локальных митапов гораздо ниже чем от, например, Mobius.
Всё вышесказанное играет вам на руку - вряд ли все пришедшие избалованы крутыми докладами или сами внедрили всевозможные технологии к себе в проект. И даже если такие слушатели найдутся - они зададут вам крутые вопросы и дадут полезный фидбек.
Ещё можно вписаться в какое-нибудь местное сообщество, которое организовывает митапы для джунов или студентов. Там аудитория совсем не избалована крутыми докладами, но они могут задать вам самые неожиданные вопросы, потому что у них гораздо меньше опыта для понимания вашей темы
Где-то между локальными конференциями и Mobius/Appsconf стоят конференции в духе Devfest: они платные, но дешевле; при этом собирают достаточно много людей и на них приезжают интересные доклады и спикеры не только из других городов, но и из других стран
Требования к докладам на таких конференциях выше, чем на локальных и как раз на них стоит стремиться после локальных митапов. В худшем случае, если ваш доклад не подойдёт для такой конференции, вы получите фидбек от программного комитета, которого ещё не было на локальных митапах
При этом большинство слушателей - ваши коллеги из местных компаний и компаний вашего региона, то есть аудитория пересекается с аудиторией локальных митапов, но ожидания от конференции у них тут уже выше. Но вы уже тоже не лыком шиты и уже набили руку на локальных митапах;)
@mobileunderhood "... и на них приезжают интересные доклады и спикеры ..." - что автоматом ставит местных спикеров на соответствующий уровень
IT конференции отличаются от просто публичных мероприятий тем, что ваш опыт не может обесцениться тем, что вы ноунейм. Популярность спикера исходит из интересности его опыта для людей и гарантирует интересный доклад, но это не работает в обратную сторону twitter.com/reeve_nn/statu…
И ваш финальный босс-вертолёт - это Mobius/Appsconf и другие аналогичные конференции. Аудитория жаждет интересных докладов, потому что билеты на такие конференции стоят очень приличных денег. Но это влияет не только на вас и ваш доклад, но и на организаторов конференций
Именно из-за высоких требований к докладам ПК таких докладов будет очень внимательно оценивать ваш доклад и помогать вам прокачивать его до почти идеального состояния, поэтому не стоит переживать, что вас просто выкинут на сцену на съедение искушённой аудитории
И даже если вашу заявку в итоге отклонят, то после проработки доклада вместе с программным комитетом крупной конференции, вы с очень большой вероятностью сможете без особых усилий вписаться в любую более мелкую конференцию
В итоге после того как вы придумали тему очень важно понять какой искушённости аудитории будет интересна ваша тема. Ваш опыт как минимум может быть интересен вашим коллегам и посетителям локальных митапов
На конференциях серьёзнее с этим вам поможет ПК - либо вам помогут доработать ваше выступление, либо откажут и это поможет вам не оказаться в ситуации, когда вы рассказываете свой доклад людям, которым он малоинтересен
Тут всё точно также как с обучением программированию - пока вы не начнёте писать код, вы не станете разработчиком. И у вас были аналогичные страхи, что ваш код - говно и никому не нужен. И вы уже проходили путь от страха перед новой деятельностью до самой деятельности
На сегодня я заканчиваю свой поток твитов, завтра разберу остальные страхи, которые мешают начать выступать, и расскажу про свой опыт и что вы получите от выступлений
Если я пишу слишком часто, и вам это не нравится, бахните лайк - я начну тренировать лаконичность и писать реже
Среда
Всем доброе утро, продолжаем расправляться со страхами перед выступлениями. Начнём с проблемы нехватки технических скиллов для выступлений. По моему опыту и опыту других выступающих необходимый и достаточный уровень ваших скиллов для того, чтобы начать выступать - уровень миддла
Уровень миддла позволит вам говорить на одном языке с другими разработчиками: миддлами и джуниорами. Во время выступления не так важен общий уровень технических скиллов, как важны ваши знания по вашей и смежным темам, которые вы получите при подготовке самого доклада
Если вы рассказываете почему всем стоит прямо сейчас переехать на гугловский MVVM, вы должны шарить не только в гугловской MVVM, но и в других её реализациях а также в различных реализациях других архитектур, например MVP, понимать достоинства и недостатки каждой из них
Потому что с огромной вероятностью вам накинут вопросов по вашей теме и по смежным(а почему вы выбрали гугловский MVVM против реализации MVP от Moxy?). И вряд ли на докладе про архитектуру вас начнут спрашивать как работает хешмапа или джавовский GC
Прежде чем плавно перейти к страху завалиться на вопросах, вот вам капитанская мысль - никто не знает абсолютно всего. Люди придут на ваш доклад, потому что им интересна именно ваша тема, поэтому нужно разбираться именно в ней и пофигу, что вы так и не выучили lifecycle фрагмента
Следующий страх - “Меня завалят вопросами”
Вы не на экзамене и даже не на собеседовании. Цель слушателей не завалить вас и даже не проверить ваши знания. Они пришли в первую очередь узнать что-либо новое и полезное для себя. Большинство вопросов можно описать так:
Технические вопросы:
- Можно ли с помощью того про что ты рассказывал сделать <<описание своего кейса>>?
- Почему вот тут вы воспользовались именно этим, а не <<описание технологии>>?
- С вашим подходом не возникнет ли проблема вот тут?
Общие вопросы:
- Почему нам нужно воспользоваться именно тем, о чём ты рассказывал, а не другим устоявшимся вариантом?
- В чём практическая польза твоего доклада?
- Кому пригодится то, что вы рассказывали?
Такие вопросы возникают, если кто-то не убедился почему вы сделали круто
При этом есть шанс получить очень необычные вопросы от людей, которые мимокрокодилили и случайно забежали на ваш доклад: вопросы от фронтендеров, менеджеров и просто людей, которые не интересовались вашей темой до этого
Так что делать с вопросами-то?
Ваша цель предусмотреть большинство вопросов. Найдите слабые моменты своего доклада:
- Ваша технология не очень применима для многих команд - придумайте ответ зачем вы это всё рассказывали вообще
- У доклада слабая практическая применимость? Продумайте почему ваш доклад полезен
- Вы рассказываете о каком-то новом подходе в области, где уже есть свои короли рынка(MVVM vs MVP, Flow vs RxJava)? Не избегайте сравнений с конкурентами, покажите, что вы знаете плюсы и минусы разных подходов, обоснуйте чем ваш подход хорош для распространённых кейсов и проблем
К сожалению, в одиночку продумать все моменты достаточно сложно, но если вы собираетесь выступить на крупной конференции, то с вопросами вам помогут в ПК. Также нужно рассказать ваш доклад вашим коллегам или знакомым из профессии - они накидают вам вопросов
Целитесь на не самые мелкие конференции? Расскажите ваш доклад в упрощённой форме с упущенными подробностями(чтобы не потерять эксклюзивность) на мелком митапе. В любом случае ваша цель до ключевого выступления уже собрать какой-нибудь фидбек по докладу
При этом после получения фидбеков есть два варианта:
- Доработать доклад, чтобы такой вопрос больше не возникал у слушателей - тут вам могут накинуть новых вопросов
- Оставить всё как есть, чтобы вам задали именно такой вопрос, к которому вы уже подготовились
Не торопитесь сходу давать ответ на вопрос - если нужно немного времени на подумать - так и скажите слушателю. Если вы понимаете, что на подумать нужно несколько минут, перейдите к следующему вопросу, а на предыдущий отвечайте позже, но "забывать" вопросы тоже нельзя)
Ну и серебряная пуля для ответов на вопросы - это честный ответ: “Спасибо за вопрос, отличное замечание, но в эту сторону я ещё не копал, обязательно изучу этот момент”. Аудитория вполне понимает и принимает такие ответы, но тут есть два правила:
- Не злоупотребляйте этим. Иначе у людей сложится ощущение, что вы пробежались по верхам и побежали сразу всем рассказывать (вы же так не делали, правда?)
- По-настоящему разобраться в заданном вопросе - поможет разобраться в сопутствующих вопросах и в целом улучшить доклад
Чего делать нельзя - отмахиваться от вопросов и игнорировать их. Если не смогли ответить на какой-нибудь вопрос на выступлении и нашли решение - поделитесь ответом в чатике конференции. Аналогично с ошибками в докладе - вас не съедят за ошибки, если вы расскажите как правильно
@mobileunderhood Пиздить людей, которые спрашивают
Пойми, вы докопались до тех, доклады кого вы слушаете. Мы вам готовим выступления, изучаем за вас Android Jetpack, обслуживаем ваши вопросы, вводим bullshit driven development, охраняем чистоту вашего кода нашими пересказами документации по архитектуре. Не надо злить нас. twitter.com/xotta6bl4_/sta…
Как начинал выступать я - это для меня очень свежий опыт, много над чем ещё работать и работать. Сейчас будет история успешного успеха от Петра Успеха.
Я также хотел попасть конфу спикером. И также не мог придумать о чём рассказать. Но потом понял, что нужно всего-лишь……
Подойти к тимлиду со своей проблемой - он поделился со мной списком того, что ему было бы интересно узнать. Меня заинтересовала тема про то как работает 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 уровня и тыщу подписчиков в твиттере
- Толпу поклонниц ваших выступлений(а вот поклонники могут появиться, гендерный баланс, всё такое)
- Приглашение вас спикером на следующий сезон
Ну и раз мы начинали со страхов, то ими и закончим. По-началу(и не только) вам будет страшно вообще на всех этапах и к этому надо привыкнуть. Особенно сильно вас может прижать на самой конференции перед выступлением. Тут нет спасательных советов - вы просто идёте и выступаете
@mobileunderhood - Некоторые компании вполне себе выдают бабло за выступления (лого компании в слайдах обязательно!) - Внутри компании вполне себе бренд (но в подписчиков не конвертируется) - Толпа hr-поклонниц - "Ну давай ты еще куда-нибудь подашься?" "А ты не хочешь на конфе Х выступить?"
Почти всё так)
Бренд внутри компании очень даже конвертируется при поднятии зарплаты. И к вам в компанию могут прийти новые люди потому что "о, у них же работает чувак, выступление которого я видел на осенней конфе"
А податься дальше обычно начинает уговаривать сама компания) twitter.com/xotta6bl4_/sta…
@mobileunderhood Важный совет: бухайте после своего выступления, а не до. Если у вас есть друг в ПК, то упросите его поставить вас до афтерпати, а не на следующее утро после него.
Мне всегда везло и я всегда выступал на последнем дне конференции, а афтерпати обычно шёл перед ним. Ощущения настолько не передаваемые, что страх перед выступлением отступал перед головной болью и другими приятными последствиями twitter.com/xotta6bl4_/sta…
На одной из конференций меня сковало так, что я всю конфу до своего выступления просто сидел в мягкой зоне и не смог сходить ни на один доклад, но даже в такой ситуации ты просто идёшь и выступаешь.
Надеюсь, мой опыт поможет кому-нибудь хотя бы с одним из большого списка страхов
Про опыт как начать выступать - всё. Завтра я хотел рассказать про внутреннюю кухню ПК, но есть ощущение, что после двух дней про конференции, на третий у вас кровь из глаз польётся. Поэтому могу разбавить эти темы опытом начинающего лида. Про что обсудим - решать вам:
И ещё один небольшой хак. Когда посреди выступления вы забудете, что вы там рассказываете дальше, вам на помощь придёт бутылка с водой - никто не заметит, что вы тупите, пока пьёте воду. Это поможет вам отвлечься и собраться с мыслями. Поэтому моё первое выступление выглядело так
Четверг
Всем доброе утро, сегодня поделюсь своим очень свежим опытом листва на проекте. Начнём с опроса)
Как ты стал лидом?
Всем доброе утро, сегодня поделюсь своим очень свежим опытом листва на проекте. Начнём с опроса) Как ты стал лидом?
Судя по опросу, большинство стало лидами, потому что компании понадобился лид. На такую ситуацию мне очень запомнилась мысль: "когда вы делаете сеньора лидом, вы теряете сеньора". Хорошо, что я не сеньор, поэтому моя компания ничего не потеряла
twitter.com/mobileunderhoo…
У меня ситуация “компании понадобился лид” возникала дважды:
- Когда пропало понимание между предыдущим лидом и другими членами команды, из-за чего лид покинул компанию
- Когда предыдущий лид захотел начать новый проект компании
Начну со второго случая потому что он менее экстремальный, и тут я стал лидом по-нормальному, а не “лидом на час”, пока компания судорожно ищет настоящего.
Что же меняется, когда становишься лидом? Пока идёт текущий спринт - ничего. Но когда начнётся планирование следующего...
Первое, что сразу высасывает из вас всё время - встречи. Помимо грумингов(дев-ревью) и планирований будет ещё миллион встреч на 15 минут обсудить какую-нибудь фичу с аналитиком, дизайнером, продактом. Если терпеть не можете встречи, одумайтесь, пока ещё не согласились на лидство
А после встреч вам ещё придётся передавать ваши знания разработчикам, потому что по прочтению документации не всегда с первого раза понятно, что нужно делать. Чтобы облегчить этот процесс, позовите разработчиков на добровольной основе на крупные обсуждения задач:
- Меньше вопросов по задачам от разработчиков
- Больше разработчиков => больше нюансов сможете проработать
- Разработчики будут больше погружены в проект, чем когда они просто двигают таски в код ревью
- Когда вас не станет, разработчику с вашего проекта будет проще стать лидом
При этом нельзя тащить разработчиков силком на все обсуждения: многие пришли в первую очередь писать код и решать задачи, и делают это отлично - вы же не хотите, чтобы разработчик на собеседовании в другую галеру сказал, что ушёл из-за слишком большого количества встреч?
После возрастания количества встреч обнаруживается, что непонятно как оценить вклад в проект. Если раньше к вечеру ты создавал MRы с новыми фичами или фиксами, то теперь складывается ощущение, что ты перестал делать реальную работу и просто весь день разговариваешь с коллегами
Это происходит из-за того, что ты привык писать код, а теперь у тебя новая область ответственности. Теперь сходить на встречу, обсудить задачу с аналитиком или UI с дизайнером - это твоя работа и твой непосредственный вклад в проект
Чтобы было легче увидеть результат дня(недели), я начал записывать в блокнот абсолютно всё, что делаю. Полчаса обсуждал с дизайнером UI? Записал в блокнот. Спланировал спринт? Записал в блокнот. Впервые за неделю исправил баг на две строки кода? Поплакал и записал в блокнот
@aarexer @mobileunderhood Согласен, что он вырастает из разраба в проекте, иначе быть не может. Это же не манагер, у чувака видение должно быть. На своём примере скажу, что это разраб на которого один раз все скинули и он выжил. Хотя видел вакансии на лида, не пойму как это работает.
Вот вам лучшее описание лида:
"Разработчик, который выжил" twitter.com/dikobrazz_supe…
Следующее, что произошло - я открыл в себе свои тёмные стороны при просмотре MR, когда возникает желание докопаться до кода, потому что "у нас тут так не принято писать" или "я бы написал это по-другому, и вообще кто тут на проекте главный"
А ещё ваши разработчики могут разнести в пух и прах ваши MRы, накидав вам кучу обоснованных(у них-то нет вашего инструмента власти) претензий. В такой ситуации вам будет очень хотеться резолвнуть дискуссии и втупую вмерджить ваш MR потому что "я лид, я так вижу"
Лечится это техническим обоснованием каждой вашей дискуссии в сторону разработчика и каждым ответом на дискуссию в вашем MR - вы же не хотите выстроить общение в команде по принципу "я лид, я так вижу"? И такой подход помогает вам расти лучше как техническому специалисту
Вашим спасательным кругом в таких ситуациях также будет документ с код стайлом на проекте - в любой ситуации можно сослаться на него и тогда обосновывать дискуссию/код придётся уже разработчику. У вас ещё нет документа с код-стайлом? Составьте его, облегчите себе жизнь)
Немного материалов, которые помогут вам выжить на код ревью
How to do a code review от гугла:
google.github.io/eng-practices/…
Кому удобно в формате видео, вот вам митапчик, построенный вокруг этой статьи:
youtube.com/watch?v=O4lcyG…
Самое страшное, что с вами случается, когда вы становитесь лидом - вы не просто начинаете писать меньше кода, у вас полностью исчезают периоды в несколько часов времени, когда вас никто не отвлекает, вы можете полностью погрузиться в задачу и запилить какую-нибудь фичу
Потому что помимо запланированных встреч и мелких обсуждений вас постоянно будут доканывать вопросами вообще все кому не лень. У тестировщика появился вопрос по задаче, которую сделал ваш разработчик? Он идёт с вопросом к вам, чтобы вы отправили его к разработчику
У вас в проекте есть куча не задокументированного легаси кода? Ожидайте аналитика с вопросами как работает тот или иной экран. Прилетел вопрос от заказчика по какому-то багу или негативный отзыв пользователя? Этот вопрос долетит именно до вас, иногда минуя всех остальных.
На другой платформе хотят сделать такую же фичу, которая была сделана у вас пару лет назад? Угадайте, кто будет подсказывать как эта фича делается)
В самые весёлые моменты ко мне выстраивалась очередь из трёх человек с разными вопросами
Из-за этого всего в какой-то момент происходит хлопок вашей жопы и приходит понимание, что минимум половина вопросов направлена проходит через вас транзитом: от одного члена команды - другому. И это именно то, где можно освободить себе кучу времени
Вас спрашивают про задачу вашего разработчика? Объясните вопрошающему, что в Jira есть исполнитель задачи и лучше сразу обратиться к нему, чтобы вопрошающий сэкономил своё и ваше время. Тестировщик спрашивает как должно работать фича? Пошлите его в документацию или к аналитику
Самый лучший способ решения данной проблемы - составить карту ответственности: кто на какие вопросы и кому может помочь. После чего, когда вам прилетит вопрос не по адресу, перенаправляйте человека на эту карту. К сожалению, эта штука не даст мгновенного результата
Все устные договорённости нужно фиксировать в задачах или в документации, куда и нужно перенаправлять соответствующие вопросы. Вы же не хотите, чтобы на вас завели баг только потому что тестировщик не знал, что вы с аналитиком закорешились и порешали делать что-то по-другому?
Что вы получите от лидства?
- Денюжку - но тут зависит от компании и вашей предыдущей позиций. Если вы были сеньором на 300 кк/сек, то вряд ли вам поднимут зарплату
- Новые обязанности и задачи. Это очень помогает, когда вы ощущаете, что засиделись над одними и теми же задачами
- Прокачка софт-скиллов. Вам придётся начать учиться общаться с коллегами: от своей команды вплоть до заказчика
- Более глубокое погружение в проект. Вы будете знать для чего делаются те или иные фичи, что планируется дальше
- Больше влияния на проект. Вы можете выбить из менеджера время на техдолг или убедить его, что это не техдолг, а улучшение, которое менеджер может продать заказчику. Хотите, чтобы появился CI на проекте? Обоснуйте бизнесу зачем, станьте devops и начните получать кучу денег
Всеми вышеописанными штуками может заниматься не только лид, но и разработчик, если он хочет либо стать лидом, либо больше влиять на продукт. Сейчас набирает популярность такое мнение, что время чисто кодеров проходит - скоро не получится клепать MRы и получать миллионы
Нужны разработчики, которые разбираются в своей предметной области, понимают для кого они делают продукт, какие крутые фичи можно туда добавить, а чего добавлять не стоит. При этом они могут объяснить свои технические хотелки так, чтобы они были интересны бизнесу
Интересное и очень холиварное выступление на эту тему- youtube.com/watch?v=wMuD9S…
Пятница
Пятничного утра всем, сегодня расскажу про внутреннюю кухню программного комитета на примере ПК Mobius(думаю, тут многое похоже на другие крупные конференции): какими инструментами пользуемся, как проходит работа со спикерами и на что обращаем внимание при просмотре докладов
Всё начинается с подачи заявки спикером и нулевого созвона. Созвон длится в среднем 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 продукт => когда менять работу.
Зачем вы пошли в ВУЗ?
Твиттер не позволяет делать длинные описания для опросов, поэтому раскрою каждый пункт:
Чтобы стать программистом. Вы ещё в школе заинтересовались программированием и решили связать с этим вашу будущую профессию, поэтому решили получить высшее образование
Мама сказала, что надо. Вы закончили 11 классов, потому что в ПТУ идут лохи, а каждый уважаемый себя человек должен получить высшее образование, если не хочет стать дворником. Кем вы хотите быть вы ещё не знаете, но точно не срочником.
Переезд в большой город. Мама сказала, что нужно пойти в ВУЗ, но вы начали подозревать, что ваш родной город вам как-то надоел как и жизнь с родителями под одной крышей. А вот большой город - больше возможностей и свобод, а ВУЗ даст вам почти бесплатное жильё и стипендию
Вы решили не продлевать своё состояние школьника ещё на 4-6 лет поступлением в ВУЗ и сразу приступили к этапу взрослой жизни. При этом вы лишили себя возможности ныть о бесполезности высшего образования, чтобы набирать классы от других дипломированных специалистов
Всем хороших выходных в эти нерабочие дни! На неделе ушло много времени на треды про выступления, поэтому на выходных будет единый рассказ из нескольких тем: из ВУЗа в разработчики => как вкатиться в Android => аутсорс vs продукт => когда менять работу. Зачем вы пошли в ВУЗ?
Почти половина проголосовавших пошла в ВУЗ с целью стать программистами. Я на пересечении второго, третьего и немного первого вариантов. Кем хочу стать особо не знал, но программирование в рамках школьного предмета нравилось, да ещё и узнал про зарплаты
twitter.com/mobileunderhoo…
Поэтому и пошёл на специальность "Программная инженерия" в надежде, что за 4 года меня из разработчика QBasic черепашки сделают разработчиком QBasic черепашки за 300 кк/сек. И ровно с этого момента начались жёсткие недопонимания между мной и ВУЗом
@mobileunderhood Ещё когда в семье ни одного психолога или программиста — одни геологи и экономисты. Когда родитель уважает желания и потребности ребёнка ☺️
Всегда было интересно есть ли реальные люди, к которым лет в 14 подошёл отец и сказал: "Сынок, я геолог и мой отец был геологом, и отец моего отца тоже был геологом, поэтому, когда придёт время, ты тоже станешь геологом"? twitter.com/MojoIvan/statu…
Студент вне зависимости от цели поступления в ВУЗ все же ожидает от ВУЗа получения скиллов для успешного устройства на работу после выпуска. Например, в ВУЗе он изучит современные направления продовской разработки: от сурового банковского бекенда до Android/iOs
Но, сорян, в 80-х не было ваших Android и iOs, зато был ассемблер. Поэтому у нас было аж три семестра изучения программирования на ассемблере, из которых целый семестр мы писали код на ассемблере под систему z/OS, о которой вы сейчас слышите впервые и больше никогда не услышите.
Такая фигня возникает из-за абсолютно разных целей студента и ВУЗа: студент хочет попасть в актуальный рынок труда, а ВУЗ по старым методичкам пытается сделать из студента сотрудника НИИ или любого другого гос предприятия, где до сих пор и используются древние технологии.
После пары-тройки таких актуальных интереснейших предметов я принял самое правильное и лучшее решение в данной ситуации(нет) - забил хуй на получение знаний и старался наименьшими усилиями закрывать зачёты и сессии. И именно так поступили многие другие студенты
Это огромная ошибка с нашей стороны, потому что среди кучи ненужных и устаревших предметов примерно треть дают отличную базу для будущего трудоустройства, а вместо получения знаний мы просто начали делать отчёты по лабам, когда поняли, что ВУЗ интересуют подписанные бумажки
И с забиванием на получение знаний я упустил такие важные темы как:
- Сетевые уровни и протоколы и как всё это работает
- Алгоритмы и структуры данных
- Разработка компиляторов
- Многопоточность (прямо отдельный семестр был)
Мне потребовалась целая ступень образования, чтобы понять что на самом деле с этим всем нужно делать и только к магистратуре я смог отделить полезные предметы от устаревшей теории и перекладывания бумажек. Этому поспособствовали реально крутые преподаватели и устройство на работу
Самые интересные лекции и практики и самые полезные знания мы получили от преподавателей-практиков. Не тех, кто безвылазно просидел в вузе последние 30 лет и вписывал своё имя в студенческие работы, набивая себе количество научных публикаций
А тех, кто совмещал преподавание с работой, смог вытащить нас из состояния вечного студента и заинтересовать в реальной разработке. И к моему выпуску таких преподавателей на кафедре становилось больше. Возможно лет через 10 в твиттерах начнут советовать всем поступать в ВУЗы
И я не пытаюсь этим сказать, что "ВУЗ - говно, не идите в ВУЗ". Тут дело именно в том, что студент хочет от ВУЗа то, чего ВУЗ не даёт, а ВУЗ ничего не знает про современный IT рынок и что за написание отчётов денег уже никто не платит. И иногда и правда лучше пройти курсы
После которых вы попадёте на целый год курсов по покраске травы и заправлению кроватей, но это совсем другая история
Что же реально ВУЗ даёт и что не так просто заметить с первого взгляда: переезд, связи, жизнь без армейки, базовые знания и мифическое умение учиться
Переезд. Поступление в ВУЗ - это самый дешёвый способ перебраться в другой город для бывшего школьника. Дешёвое жильё, стипендия в зависимости от успеваемости(да она очень маленькая, но всё же) и 10к от родителей на месяц, пока вы не захотите заработать себе ещё денег
Связи. Именно в возрасте студента школьники превращаются в спецов, находят себе работу и могут помочь вам а, может, и вы им поможете с трудоустройством
Жизнь без армейки. После школы вы не особо успеете сориентироваться, а ВУЗ даёт время придумать решение этой проблемы
Базовые знания, которые помогут углубиться в конкретную область IT, к счастью ещё не успели устареть.
Мифическое умение учиться == способность тратить огромное количество времени и сил на достижение результата, даже если сам процесс неприятен и сложен
Нужно ли идти в ВУЗ? Думаю, что в текущих российских реалиях ВУЗ даёт крутую базу для развития, но не в тех областях, которые я от него ожидал изначально. Не получится просто учиться по ВУЗовской программе и сразу вбежать на уровень хотя бы Junior разработчика
Ну и последнее недопонимание с ВУЗом произошло, когда мы начали курса с 3 устраиваться на работу по специальности и получили кучу претензий от ВУЗа, что студент не должен работать, а грызть гранит науки. При этом на вопросы как без опыта работы найти потом работу ответа не было
На этом перейду как раз к вкатыванию в Android разработку, хватит уже пинать наше остывающее высшее образование)
Когда я начинал изучать Android в 2016 году, все рекомендации сводились к изучению Java и Activity Lifecycle, после чего можно было отправляться делать своё приложение метчы.
Как выглядят очень настойчивые рекомендации гугла для юных андроид разработчиков сейчас:
@mobileunderhood Народ, а кто-нибудь свой список рекомендаций для изучающих андроид может написать?
Как раз хотел написать про это)
Может, я дед, но я считаю, что всё ещё нужно начинать с изучения следующих штук:
-Java и только после неё Kotlin
-Android SDK - по сути все уроки со StartAndroid
-Писать свои приложения, например, калькулятор или файловый менеджер twitter.com/PereslavlLive/…
На начальном этапе, наверное, даже вредно будет изучать архитектуру, иначе получится разработчик, который делает архитектуру ради архитектуры.
После первого приложения, где запросы летят из Activity, а при повороте экрана оно крашится, уже есть смысл изучить всякие MVP и MVVM
Но лучше пробовать эти подходы на практике под зорким наблюдения сеньор разработчика, чтобы не научиться делать неправильно. В принципе там же изучаются всякие RxJava или Coroutines в зависимости от того, что использует компания
Воскресенье
@mobileunderhood Расскажи, почему сначала Java? Я бы никому не посоветовал сейчас под iOS начинать с ObjC.
Java используется в куче других сфер - в отличие от ObjC
Во многих проектах есть Java код, и его нужно поддерживать
Въехать в Kotlin после изучения Java проще, чем въехать в Java из Kotlin
Android SDK и куча либ написаны на Java - а в исходниках мы копаемся часто twitter.com/AndreyMishanin…
После переезда на Kotlin, обратно на Java не хочу. Стоит учитывать, что в Android разработке не используется вся мощь Java 8. Но после некоторых танцев с бубном и desugaring можно и Stream, и остальное заюзать. А вот без танцев с бубном это всё уже есть в Kotlin, да ещё и удобнее
Итак, к воскресенью закончили ВУЗ, вкатились в Android и пора определиться где лучше работать: в аутсорс разработке или продуктовой разработке?
Лучше работать в продуктовой разработке
Всем спасибо, всем хороших выходных
На самом деле совсем не так. У каждого подхода есть свои сильные и слабые стороны. У продуктовой разработки есть несколько крутых преимуществ перед аутсорсом:
Проще влиять на сам продукт и на техническую часть: хотите Корутины? Дядя-заказчик не скажет “ой, на это у нас нет бюджетов, нам надо ещё 20 новых кнопочек покрасить, чтобы поднять retention”. Появилась идея для фичи? Вам не нужно убеждать менеджера продавать её заказчику
В среднем кодовая база продукта лучше чем у аутсорс проекта, потому что продукт разрабатывается много лет вовлечёнными в него людьми, которые не скачут между проектами и заказчиками
Но и аутсорс разработка предлагает пару интересных фишек:
Можно менять проект без смены работы, если текущий вам осточертел
Больше проектов - больше подходов к разработке и технологий. Если только вы не используете для всего внутренний фреймворк - бегите от такого
Хорошая аутсорс компания пилит одни и те же проекты настолько долго, что это по сути продуктовая разработка со всеми её преимуществами, только проектов много.
Хорошая продуктовая компания имеет свой вектор развития и не схлопнется под грузом разрозненных фичей
И выбор тут стоит между компаниями, которые умеют в качественную разработку одного или нескольких продуктов с внутренним или внешним заказчиком и между шарагами, которые пилят по 100500 проектов или фич одного проекта за полгода лишь бы по-быстрому поднять бабла
После устройства в самую лучшую, самую дружную успешную компанию с печеньем на кухне рано или поздно наступает приходит время менять работу. По моему опыту это очень часто происходило не из-за поисков нового, а потому что в текущей компании начинала происходить какая-то дичь
Когда следует увольняться?
Если вам перестали платить зарплату и начали кормить обещаниями "через 2 недели", "пойми, сейчас всем тяжело". Это дикое капитанство, но всё равно куча людей продолжает работать в течение нескольких месяцев за бесплатно.
Я сталкивался с таким дважды и оба раза не уходил из-за огромных сомнений в том, что моего скилла хватит найти новую работу. В первом случае я два месяца просидел без зарплаты. Причём ситуация доходила до такого дикого абсурда, что
(1/2)
(2/2)
В какой-то момент директор вместо обещаний начал кидаться претензиями "вы так плохо работаете в такое тяжёлое время и ещё осмеливаетесь требовать зарплату за ваши ошибки". В итоге это оказалось обычное психологическое давление, чтобы люди не побежали искать новую работу
При этом абсолютно все, кто через пару месяцев прозрел, нашли себе работу с х2-х4 зарплатой. Так что если вам начинают говорить, что вы вообще-то так себе специалист, вполне возможно, кто-то пытается воспользоваться вашим синдромом самозванца, чтобы сэкономить на вас
Во втором случае я почему-то верил что продукт, который я с нуля сделал за 7 месяцев вот-вот запустится, и на нас польются деньги рекой, поэтому продолжал работать бесплатно целых 3 месяца. Но компания просто развалилась и так и не выплатила больше половины долгов сотрудникам
В большинстве случаев ни интересные задачи, ни дружный коллектив в карман не положишь, поэтому когда вас больше недели-двух кормят обещаниями/угрозами, заявление на стол и, в текущих реалиях IT рынка, через пару недель вы будете уже на новом месте с новой зарплатой
@mobileunderhood Был в такой ситуации. Только на меня в конце, когда мне надоели обещания заплатить на следующей неделе и я ушёл, написали заявление в милицию на тему вымогательства и кажется кражи интеллектуальной собственности.
Вот это, конечно, дикая история twitter.com/TheNotoriousSD…
Следующая причина сменить работу: вы каждый вечер рассказываете домашним как на работе вы катаетесь на горящем велосипеде, всё вокруг горит и вы в аду. Это ни разу не нормально и дружная команда вместе с большой зарплатой опять же не стоит выгорания 24/7
Или обратная ситуация, когда вокруг ничего не происходит и вы просто занимаетесь поддержкой старого приложения и пилите небольшие фичи: очередной экран с двумя кнопками. После пары лет такого опыта вы станете профнепригодным, потому что рынок бежит вперёд с большой скоростью
Когда выбираешься из компании с дичью, перед тем как попасть в галеру мечты, сталкиваешься с HRами. Вы же понимаете к чему всё идёт)
Например, если не отвечать на письмо на почте хорошему HRу, то к тебе в телеграмм придёт плохой HR и будет разговаривать с тобой совсем по-другому
Когда у хорошего/плохого HR не получается схантить, то приходит HR-гопарь, который изучает твой стек технологий по понятиям
Но все эти смехуёчки по поводу общения с HR меркнут по сравнению с главным инструментом компаний, которые не хотят предлагать достойные зарплаты:
Тесты на мотивацию!
Сейчас мы узнаем насколько вы преданы компании или вас интересуют только грязные бумажки на покупку кофе
Что Вас больше замотивирует выполнить сложное сверхурочное задание?
дополнительная оплата
возможность заявить о себе руководству
возможность сделать интересную творческую работу
то, что это важно для достижения целей компании
Если бы Вы были руководителем, то какой способ награды вы бы использовали?
премия
награждение званием «Лучший…» и публичная похвала
дал бы большую свободу в действиях
включил бы в состав группы, участвующей в принятии важных решений
Это уже back to USSR прям
Какую компанию Вы скорее выберете?
где больше платят
где лучше коллектив
где будут интересные для вас задачи
с которой совпадут ваши убеждения и ценности
То есть при устройстве в конкретную компанию у вас спрашивают в какой компании вы хотели бы работать ¯_(ツ)_/¯
С каким руководителем Вам бы НЕ хотелось работать?
с тем, кто не дает зарабатывать
с тем, кто уделяет мало внимания сотрудникам
с тем, кто постоянно контролирует
с тем, кто скрывает информацию о ситуации в компании
Что бы вы хотели получить от продвижения по карьерной лестнице?
хорошие деньги
признание
свободу
возможность влиять на развитие компании
Повышение зарплаты раз в 5 лет, а вот свободу можно получить только в Юрьев день
На ваш взгляд хороший руководитель это тот, кто
будет справедливым в распределении денег
будет публично признавать личный вклад каждого и поддерживать коллектив
будет давать время на подготовку, не будет торопить
будет всей душой болеть за общее дело
Один из моих любимых вопросов тут, который много проясняет относительно компаний с такими опросами)
Наиболее значимое для вас слово
@mobileunderhood А Признание в этом опросе можно считать гордыней?)
Гордыня, эйчароугодие, кроссплатформа - смертные грехи программиста twitter.com/knacid/status/…
Ну и лучший вопрос
Как бы вы, будучи руководителем, простимулировали сотрудника выполнить сложную задачу, не входящую в его обязанности
деньги
попросил бы лично, ради меня
бросил бы вызов, взял бы «на слабо»
объяснил, как это важно для достижения целей всей компании
Какой из этого вывод?
Хорошо, что наш айтишный рынок умудряется создавать такое огромное и разнообразное количество тем на покекать.
Не вижу смысла относиться к этому всему серьёзно и бежать строчить миллион статей на ebanoe.ит о том как всё ужасно плохо и не профессионально
@knacid @mobileunderhood А что не так с признанием? Обычная потребность имхо.
Проблема этого теста на мотивацию, что он есть 3 пункта про мир дружбу жвачку, признание, мотивацию и высшую цель. И есть один пункт для не очень хороших людей - он про деньги) twitter.com/MojoIvan/statu…
На этом моя неделя подошла к концу. Надеюсь, мой опыт и мои кулстори были вам интересны и даже в чём-то полезны, а мемы заставили вас знатно покекать(how do you do, fellow kids?)
В телеграмах и твиттерах меня можно найти по нику xd720p
Всех люблю
