Архив недели @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
Добавление технических деталей в PRD это типичная ошибка разработчиков, которые пытаются начать писать документ с требованиями. Очень важно разделять ЧТО и КАК, поэтому технические детали должны быть в отдельном документе. #день2из7
Делать проект или фичу и не измерять её производительность — это деньги на ветер. Бизнес аналитики описывают как это сделать в PRD, фича без аналитики в продакшин не ходит. #день2из7
Наличие 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…
Пятница
Сегодня я расскажу как перестать обсуждать 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
Оригинальный М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…
То есть писать сначала карточку которая использует исключительно типы из вашего 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
@mobileunderhood Спасибо за крутую неделю! Было интересно 😊
Всем спасибо за активное участие и отдельное @igrekde за приглашение!
С вами был @bohdan_orlov, до новых встреч! twitter.com/EbTvoy/status/…
