Богдан Орлов

Богдан Орлов

Неделя
Aug 19, 2019 → Aug 25, 2019
Темы

Архив недели @bohdan_orlov

Понедельник


Всем привет! Я @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

@mobileunderhood А вот другая точка зрения - в Германии я столкнулся с тем, что многие компании считают, если человек проработал менее 2 лет в 1 компании, то он «не надёжный». Это прежде всего из-за сложности найма (дорого, долго, буткамп 3 мес). Прокоментируете?
Также и в UK. Я здесь считаюсь "Jumper"-ом. Почти все работодатели поднимали этот вопрос чтобы: 1) получить успокоительную речь о том, как их компания отличается 2) попытаться занизить зарплату. На горячем рынке работодателю сложно быть придирчивым. #день1из7 twitter.com/pingwinator/st…

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

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

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

@mobileunderhood Странная логика. Что ж тогда делать в подобном случае?
Проясняю, свою позицию. Если плохо, то искать и сваливать безусловно нужно. Но если все идет стабильно то это не значит что нужно 5 лет сидеть на попе и ждать пока плохо не станет — нужно быть про-активным. #день1из7 twitter.com/iLLuzor/status…

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

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

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

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

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

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

@mobileunderhood Есть же известное когнитивное искажение: человеку свойственно переоценивать себя и недооценивать других. Если пять одинаковых разработчиков узнают, что у них одинаковые зарплаты, обидятся все пятеро.
В итоге кто-то прокачает навыки и запросит больше. Идея не в том чтобы у всех было одинаково, а в том чтобы друг на друга и рынок равнялись. Хочешь быть самим "дорогим"? Иди и докажи, начальству или рынку что ты стоишь денег. #день1из7 twitter.com/stevenpigeon3/…

@mobileunderhood А это точно не тот случай когда из всех статистик выбрал только ту что подходит под свой опыт?
Это не точно. twitter.com/industrieapps/…

Вторник


Сегодня говорим о требованиях, а конкретно о 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
notion image

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

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

Наличие 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

"Фильтрация указаний сверху" может привезти к образованию диады "папа - ребёнок" в команде. В итоге, цели лида могут могут не совпать с целями компании. Если связь сильная, лид решает уйти, то команда обречена, другой лид не сработается. Это вредит компании. Не надо так делать) twitter.com/mobileunderhoo…
У меня так и было, лид ушел, а с новым не сработался потому что он просто все перекидывал на низ по цепочке и старался не вступать в конфликт со своим начальством. "Мне сказали делать глупость - я вам сказал делать то же самое". twitter.com/mike_emelyanov…

Разработчики часто считают 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

@mobileunderhood @wiruzx Так как ET то получить?
Получить абсолютно также. Согласно блогу @pomidorus средние обладатели: Tier 1 EP Visa - 20-40 лет, 0-5 лет в индустрии. И уже есть достижения, но еще есть куда расти. Tier 1 ET Visa - 20-90 лет, 3-20 лет в индустрии. Признанный эксперт, часто цитируемый, иногда со стартапом. twitter.com/igrekde/status…

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

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

@mobileunderhood Надо ещё учитывать, что на EP есть лимит. Точно не помню какой сейчас но было 2 тысячи в год.
Да, каждый год 6 апреля начинаться новая квота 2000 мест. twitter.com/romk1n/status/…

@mobileunderhood @pomidorus Особо не изучал вопрос, поэтому заранее прошу прощения. Скажите, что является достижением в контексте этого вопроса?
Определение достижения намерено размытое. Нужно доказать что вы делали что-то больше чем работали в IT компании, как ваша деятельность повлияла на индустрию. А также ваш (потенциальный) вклад в экономику UK. twitter.com/dskibin/status…
notion image

Пятница


Сегодня я расскажу как перестать обсуждать 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

@mobileunderhood Clean Architecture конечно! Сразу же подразумевается что все остальное unclean и даже dirty
Оговорюсь что Clean Swift Architecture (aka VIP) (набирающий популярность у павших от ВИПЕРА) это для сектантов и не имеет ничего общего с Uncle Bob's Clean Architecture. #день5из7 twitter.com/simonovvasiliy…

Где началось наше занимательное архитектурное путешествие? На 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
notion image

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

@mobileunderhood Можешь пояснить, что именно значит «UI независимый от модели / домена»?
Конкретный пример, вот в такие карточки можно прокидывать сущности модели типа User. card.user = user: А можно делать их независимыми от Домена: // Mediator cardData = { title = user.title subtitle = user.handle } // UI Framework: card.data = cardData twitter.com/AndreyMishanin…
notion image

То есть писать сначала карточку которая использует исключительно типы из вашего 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

Такой подход очень опасен для собеседующих: - они дойдут до уровня инкомпетенции, кандидата или своей. - они будет спрашивать разных кандидатов разные вопросы (дискриминация возможностей) - их оценка будет очень сильно зависеть от того как вы "сошлись" с кандидатом #день6из7

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

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

@mobileunderhood Для небольших компаний компаний последний пункт минусом по сути и не является. Если собеседуемый сильно не "сходится" с членом команды, то возможно для всех лучше, если оффера не случится.
То есть, если в компании есть 3 разработчика задротa то и нечего набирать скиловых кандидатов с которыми не сошлись в интервью? twitter.com/Kan__Nabi/stat…

Воскресенье


В этот выходной отдыхаем. Темы нету, но отвечу на вопросы. #день7из7 #WorkLifeBalance
notion image

@mobileunderhood Спасибо за крутую неделю! Было интересно 😊
Всем спасибо за активное участие и отдельное @igrekde за приглашение! С вами был @bohdan_orlov, до новых встреч! twitter.com/EbTvoy/status/…

Ссылки