Всем привет! Я @bohdan_orlov и я прошел life cycle iOS разработчика, о чём и поговорим. Рассказы из личного опыта. Не представляю позицию моего работодателя. #НоваяАватарка #АвторНедели #день1из7

Сегодня поговорим о смене работодателя. За 7 лет в разработке я поработал в 7 компаниях, я люблю менять роботу. Сейчас работаю в Лондонском офисе ФБ. Обычно смена работы это дополнительный стресс, но также прибавка к зарплате и бесценный опыт. #день1из7

Сначала разделаемся з зарплатным вопросом. Моя история прибавок к базовой зарплате при смене компании:

2013 +100%
2014 +56%
2015 +151%
2018 +27%
2018 +33%
2019 -14%

Бонусы, налоги, стоки и переезды не учтены. #день1из7

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

#день1из7

Важно подметить что располагаемый доход (disposable income) редко возрастал больше чем на 20%, а однажды даже упал! И это не так страшно если вы понимаете что, делаете ;)

#день1из7

Моя максимальная прибавка внутри компании была:

Мой опыт всего лишь подтверждает статистику - чтобы не отставать от рыночной зарплаты менять роботу нужно часто. Смотрите на занимательный график: forbes.com/sites/cameronk…

#день1из7

Стоит ли обговаривать зарплату с коллегами?
Я считаю, стоит.
Если вам "переплачивают" (мало вероятно), то вы займётесь саморазвитием (если вы не надменный мудак), но скорее всего вам не доплачивают. Вы или получите повышение, или уйдете.
#день1из7

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

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

#день1из7

Если вам стало не комфортно работать, накидывать наверх стресс собеседований не лучшая идея. #день1из7

А вот ходить на собеседования когда у вас на роботе все хорошо — это сказка! Себя показал, других посмотрел, а не срослось — ну ничего страшного, не очень-то и хотелось! #день1из7

Но что подумает менеджер, если узнает что я пошел на собеседование почти сразу после повышения? Если вы найдете новую роботу — то вам не доплачивали, и ваш менеджер не ваш союзник. А если нет то вы "откалибровали" себя ;)

#день1из7

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

#день1из7

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

#день1из7

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

#день1из7

Стоит ли оставаться в компании потому что есть чувство долга перед сотрудниками даже если ЗП меньше рыночной? #день1из7

Платит ли ваш работодатель значительную часть компенсации стоками (Restricted Stock Unit)?
#день1из7

Сегодня говорим о требованиях, а конкретно о Product Requirement Document (PRD).

#день2из7

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

#день2из7

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

#день2из7

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

#день2из7

Другим результатом есть сложность взаимодействия команд с разными правилами к требованиям: одни верят в что все должно быть в JIRA другие утверждены что нужны Google docs для общей картины.

#день2из7

Оказывается можно относиться к требованиям таким же образом как мы все относимся к дизайну (UI). Формальные требования могут быть артефактом который блокирует разработчика, так же как и отсутствующий дизайн.

#день2из7

Таким образом у продукт менеджера появляется конкретный выхлоп — требования в форме PRD. #день2из7

Как в вашей компании относятся к качеству требований?

Мне удалось поработать в Badoo (MagicLab) где компетентные продукт менеджеры реализовали формальный подход PRD.
Они понимают, что задача ПМа не только придумать что делать, но еще и запечатлеть это в документе и вовремя вносить в него правки.

#день2из7

Лучший обзор как работает Badoo и как PRD играет ключевую роль в жизни компании глазами разработчика, Александра Балабана. youtube.com/watch?v=eehzud…

#день2из7

Ключевая часть PRD это скриншоты сырого дизайна которые подкрепляют user story. Скриншоты не заменяют Figma или Zeplin. Они нужны чтобы можно понять большую картину быстро просмотрев документ.

#день2из7 pic.twitter.com/Vn9PofxzUE

Добавление технических деталей в PRD это типичная ошибка разработчиков, которые пытаются начать писать документ с требованиями. Очень важно разделять ЧТО и КАК, поэтому технические детали должны быть в отдельном документе. #день2из7

Делать проект или фичу и не измерять её производительность — это деньги на ветер. Бизнес аналитики описывают как это сделать в PRD, фича без аналитики в продакшин не ходит. #день2из7 pic.twitter.com/z0kwSRBfQs

Наличие PRD позволяет точно оценивать задачи по времени, подключать новых людей к исполнению за несколько часов, а также накапливать и передавать знания "новому поколению". #день2из7

Также важным отличием PRD от Google Doc описывающего хотелки это жесткая структура документа. В одной компании все PRD должны выглядеть одинаково, сотрудникам очень легко искать информацию в гомогенных документах. #день2из7

Пример структуры PRD:

• Links
  • Designs
  • Tech Spec(API)
  • JIRA
• Goals
• What's New
• Platform variations
• Description
• Communication
• Use Cases
• Edge Cases
  • No Connection
  • Tablet/Small Devices
  • Error Handling
• Release Plan
• Analytics

#день2из7

Самый простой способ внедрить PRD в компанию это нанять продукт менеджера, который уже спец по этому делу. Именно так и поступили в Badoo несколько лет назад наняв ПМа из Испанской компании Tuenti.

#день2из7

Другой вариант это продвигать идею из "низов" когда разработчики и тестировщики сами пишут PRD пока практика не приживется (все равно же записывают что нужно сделать). Но есть большая вероятность что ПМы так никогда и не поймут что это их робота. #день2из7

Доказать продукт менеджеру что его робота не только придумать что делать, а еще писать и редактировать PRD очень сложно. Это не интересная задача от и от PRD мало толку если не знать как их использовать. #день2из7

Поднимайте вопрос о качестве требований на командных обсуждениях и предлагайте PRD как конкретное решение. Нужна критическая масса людей которые верят в то что это таки часть работы ПМа, а не просто хотелки разработчиков. #день2из7

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

#день3из7

Согласно этой Teamlead Roadmap писать код как тимлид это 1 из 131 возможных обязанностей. github.com/tlbootcamp/tlr…

#день3из7

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

#день3из7

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

#день3из7

Чтобы быть лучшим разработчиком нужно писать и думать о коде, чтобы быть хорошим руководителем нужно решать проблемы людей вокруг. #день3из7

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

#день3из7

Роли и вопрос становления тимлидом я более детально разобрал в прошлогодней заметке: medium.com/hackernoon/how…

#день3из7

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

#день3из7

Быть ТЛом это не только принимать важные решения, а также защищать своих подчинённых и продвигать их интересы в компании. Помните, вы начальник своих подчиненных временно, а как долго зависит во многом от вас. #день3из7

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

#день3из7

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

#день3из7

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

#день3из7

Будучи разработчиком достаточно легко анализировать свои промахи: не сделал фичу или сделал плохо, кто-то будет недовольный. Это очень простой сигнал что нужно что-то делать. #день3из7

Понят что ты не делаешь как ТЛ сложнее, нужно все время использовать множество подходов и инструментов:

• эмпатию
• делегацию
• фильтрацию указаний сверху
• обратную связь
• авторитет

#день3из7

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

#день3из7

Делегация — нужно отдавать задачи другим, а это очень тяжело. Особенно, если вы уверены что сами сделаете лучше. Хороший доклад на тему: youtube.com/watch?v=1bZ9EJ…

#день3из7

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

#день3из7

Обратная связь — создавайте возможность жаловаться:

• 1-to-1
• 360 team feedback
• Ретроспективы/Пост-мортемы
• Встречи вашего начальника и подчиненного (skip meeting)

И конвертировать в действия для себя и команды. #день3из7

Авторитет — это топливо для принятия решений с которым сотрудники не согласны. Не использовать намного опаснее чем использовать аккуратно. Будьте готовы брать ответственность на себя.

#день3из7

Разработчики часто считают 1-to-1 как трату времени. И чаще всего так и есть. Неопытные тимлиды используют встречу с разработчиком, чтобы узнать о прогрессе над задачами, дать ценные указания и возможно накинуть еще задач.

#день3из7

1-to-1 это встреча принадлежащая разработчику. Разработчик должен говорить о том что ему лично важно минимум 2/3 встречи. Поэтому задача ТЛа это установить доверие, чтобы разработчику не хотелось свалить по-быстрее и он видел в вас союзника.

#день3из7

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

#день3из7

Сегодня говорим о UK Tier 1 Talent Visa.

Многие знают (или догадываются) что можно переехать в Лондон по рабочей визе от компании-работодателя (Tier 2 General), но большинство не слышали о визе таланта.

#день4из7

Для меня просветителем оказался @wiruzx, который меня познакомил с обладателями визы (о важности их помощи ниже). А я, пользуясь случаем, передаю большое спасибо Виктору :)

#день4из7

Если сравнить EP и Tier 2 General, то ЕР не зависима от работодателя.

Если временно перестали работать, то вас не будут пытаться депортировать домой.

Можно стать контактором (LLC) что позволяет заработать намного больше денег сидя на контрактах по 6-12 месяцев.

#день4из7

С точки зрения документации на ET и EP все одинаково, только планка на EP ниже.

Я делал EP вариант, так как вероятность получить визу больше.

#день4из7

Первым делом нужно прочитать требования на gov.uk/tier-1-excepti…

#день4из7

Дальше, очень полезно пообщаться с кем-то, кто уже делал визу. В моем случае мне помогало несколько человек, но самую большую и безвозмездную инвестицию времени сделала @SBozhko. Света официальный Visa Ambassador, а также владыка devzen.ru

#день4из7

Сегодня я расскажу как перестать обсуждать iOS архитектуру.

#день5из7

iOS Архитектура — это религия для разработчиков.

#день5из7

Религия — это миф о том как устроен мир

iOS Архитектура — это миф о том как должно быть устроено приложение

#день5из7

Какая религия "правильная"? Буддизм? MVP? Ислам? MVVM? Христианство? MVC?

Я считаю все религии полезны. Каждая учит как сделать мир (приложение) лучше.

#день5из7

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

#день5из7

Религия — это хорошее начало развития морального компаса

iOS Архитектура — это хорошее начало развития навыка проектирования приложения

#день5из7

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

#день5из7

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

#день5из7

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

#день5из7

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

#день5из7

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

#день5из7

Добавляя новые буквы (и наделяя их сакральным смыслом) началась гонка вооружения MVP/MVVM/VIPER/SILVER/DISCOVER/PIDOR.

#день5из7

Где началось наше занимательное архитектурное путешествие?

На Apple's MVC.

А почему мы не говорим о том что было до этого? Разве раньше не было архитектурных проблем?

#день5из7

Откладываем архитектурные заметки с Medium в сторону и погружаемся в историю.

1979, Trygve Reenskaug опубликовал оригинальный доклад об MVC.

Если хотите понять где Apple сделала шаг не туда, читайте оригинал и делайте выводы сами. folk.uio.no/trygver/2007/M…

#день5из7

Очень сильная заметка-разбор оригинального MVC (не пропустите ссылку на вторую часть в конце текста)

habr.com/ru/post/321050…

#день5из7

Моя заметка показывающая как всякие ВИПЕРы не далеко-то убежали от MVC

badootech.badoo.com/do-mvc-like-it…

#день5из7

12 Мая 1979, день рождения MVC

#ios #holiday

Но если бы Trygve не переименовал THING-MODEL-VIEW-EDITOR в MODEL-VIEW-CONTROLLER у нас бы сейчас был TMVE

#день5из7

Еще накину на Clean Swift Architecture(VIP)

Сверху Clean Architecture
Снизу Clean Swift Architecture

Не говоря уже о "Worker"

#день5из7 pic.twitter.com/m6MYpzM9pM

Оригинальный МVC подразумевал что Модель и Вид живут отдельно и их можно легко подменять. Но мало кто пишет UI независимый от Модели/Домена.

Если положить UI в отдельный фреймворк который не импортирует Модель/Домен. То его можно строить и тестировать отдельно. #день5из7

То есть писать сначала карточку которая использует исключительно типы из вашего UI фрейморка.

Покрывать ее тестами, а потом в отдельном месте прикручивать свой домен (инжектить данные User или что угодно)

Хороший доклад про то как делать "props-driven UI"
youtube.com/watch?v=tnKeUr…

Сегодня (не) любимая тема всех разработчиков - собеседования! Поехали! #день6из7

Собеседования на первую работу это вообще цирк. У вас нету опыта и у нанимателя есть только два варианта: закидывать задачки алгоритмические (вы же только что в универе это проходили, да?) или давать писать код и смотреть что получаеться. #день6из7

Дальше, чем ближе вы подбираетесь к топовым компаниям в своем регионе тем сложнее и структурирование становится процесс.
У меня всегда было так что чем сложнее задания спрашивают собеседующие - тем интереснее потом работать в компании. #день6из7

Есть ли корреляция между сложностью собеседования и техническим уровнем собеседующих? #день6из7

У tech гигантов не спрашивают специфические знания платформы и часто нанимают просто software engineer. Также у них похожая структура собеседования и куча отзывов в интернетах. Это сильно помогает подготовиться. #день6из7

Компании по меньше обычно не имеют устоявшихся практик и спрашивают там то, что сотрудники считают важным. #день6из7

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

Все собеседования построены сотрудниками для самовалидации собственных знаний. Поэтому не извергайте гроздья гнева и не принимайте "глупые" вопросы как личное оскорбление, а просто берите себе на заметку. #день6из7

У неопытных собеседующих есть такой подход который можно назвать "техническая беседа о жизни". Это очень привлекательный для собеседующего подход так как он задает "интересные" вопросы находясь в зоне комфорта. При этом он как бы "копает в глубь". #день6из7

Такой подход очень опасен для собеседующих:

Не так важно что спрашивается а важно чтобы была "ровная планка" (even ground). То-есть вы спрашиваете всегда одни и те же вопросы и какдидат зарабатывает баллы. В конце у вас список с оценками, удобно, честно и мало места для бессознательных предубеждений (unconscious bias).

Отдаю на общее растерзание список iOS вопросов, которые я когда-то спрашивал на первом интервью. drive.google.com/file/d/1QZriqG… #день6из7

В этот выходной отдыхаем. Темы нету, но отвечу на вопросы. #день7из7 #WorkLifeBalance pic.twitter.com/4yxF8dt77U