Архив недели
Понедельник
Всем добрый день
Меня зовут Арсений, я работаю в компании Dejavoo и буду на этой неделе говорить о разработке, жизни в IT тимлидстве и ещё много о чём
Часовой пояс у меня +7 GMT, поэтому в тот момент, когда моя работа подходит к концу, люди с временем, наиболее привычным для дэйли коллов, только начинают потягивать вторую чашечку кофе
Поэтому буду притворяться дедом и уходить в оффлайн уже в 8 часов вечера
Начнем с классики - кто я такой и откуда взялся, что это за Академгородок такой и как в таком месте можно найти как геймдев галеру, так и попасть к сберу/яндексу/youNameIt на более продвинутую должность со всеми этими крупными проектами или же оказаться там, где я сейчас
Есть такое место в Новосибирске, которое основали в 1957 как будущий центр Сибирского отделения РАН, тут создали ФизМат школу и Новосибирский государственный университет, которые должны были взращивать будущих ученых для массово создающихся институтов
Прошли долгие годы, наступило другое государство, институты никуда не делись, но вместе с ними, благодаря техническим учебным заведениям возникла база мозгов, которая хотела что то делать с вычислительной техникой, а позже, информационными технологиями. И началось :)
В наше время тут можно найти местый банктех, компан явии, занимающиеся крайне специализированными заказами для встроенных систем, тут появились геймдев конторы и приехали большие компании из за Урала и начали открывать свои филиалы
Не последнюю роль сыграло создание технопарка, который сначала начал заполняться производственными высохотехнологичными бизнесами и исследовательскими лабораториями, но потом построили 'гуси', пришла пора бума стартапов и бородачи с маффинами и мукбуками заполонили технопарк
Тут и начинается история студента, который решил, что 2й курс ВУЗа, половина прочитанной книжки 'Философия Java' и желание 'поработать где нибудь' являются отправной точкой в разработку
Первый удар по шапке прилетел тогда, когда на 40 разосланных писем на должность стажера или джуна прилетело 2 ответа с желанием пообщаться. Одни предлагали сначала сделать тестовое задание, а вторые хотели сразу поговорить
Long story short - в обоих местах мне отказали, а в одном так вообще не воспринимали собеседование всерьез и прямо во время него обсуждали друг с другом планы на летний отпуск. Где то здесь будет заложен фундамент синдрома самозванца, а именно 'я ничего не знаю и никому не нужен'
Сдаваться было нельзя, поэтому я двинулся дальше. Абсолютно случайно, через какую то новостную рассылку я попал на двухдневную лекцию про суть геймдева в России и Сибири, в частности. Послушал про роли в команде, зарплаты и типовые проекты. И оттуда меня схантили в геймдев школу
Я заранее знал что это за компания, знал о ее репутации и что они заслуженная и понимал, что это не лучший вариант, но на безрыбье и галера - работа
На первом же занятии я понял, что людей 30, а предполагаемых места всего два. Так что с горящими (и еще не выгоревшими) глазами я принялся день и ночь отклоняться от программы занятий и бежать впереди всего поезда
Через 4 занятия люди в группе еле научились управляться с студией и создавать объекты на сцене, а я уже подходил к преподавателям с вопросами 'я вот тут сделал движение, хп, препятствия, в том числе с уроном, но есть проблема с загрузкой уровней'. Через неделю меня наняли
Я не работал в российском геймдеве на уровне Москвы и топовых компаний, поэтому могу говорить о работе в них только со стороны читателя статей. Тут это были мелкие двухнедельные проекты с безумной монетизацией, куча джунов, низкие зарплаты - после вычетов моя составляла 17400
Но джуны непобедимы и их душа еще не познала всю боль, поэтому я продолжал, как бульдозер, грести проекты, читать книжки по проектированию задач и экстремальному программированию и смотреть в рот людям, которые умели писать шейдеры на Си (почти что боги)
Два с половиной года я старался расти, надеялся, что вот вот будет какой то крупный проект, какая то недосягаемая лига для элит, но наблюдал только уходящих людей, эксперименты бизнеса, который получал с такого конвейера все меньше денег и понимал, что надо уходить
В мае я решил уволиться, мой начальник предложил мне на 3-4 тысячи больше, а когда я отказался - сказал что очень рад, что я смогу найти лучшее место. Место было найдено, это была первая удаленка, большая зарплата, модный офис по желанию, но это все еще был новосибирский геймдев
На данный момент это мое самое скоропостижное время работы. Проекты были примерно такого же уровня, только вместо веселых ребят, пиццы на дни рождения и совместного перекура вышел очень скудный контакт с коллегами и продолжение выгорания от конвеерных проектов
Через 2.5 месяца компания получила баны на несколько аккаунтов гугла, потеряв львиную долю выручки и всех людей, которых наняли за последние пол года, попросили уйти ПСЖ. Была выплата неустойки в конверте в размере одной зарплаты, извинения и разбитое состояние 'а что дальше'
После такого опыта я понял, что хоть геймдев и был мечтой моего детства - но лечь на этом поле боя своими (пока еще молодыми) костями я не готов и решил, что пора идти в нативную андроид разработку
Куплена книжечка, пилится домашний проект и идет подготовка к устройству в школу-интенсив по андроид разработке у еще одной (очень) знакомой мне компании. Было даже круто, особенно подход преподавателя 'никаких сторонних библиотек - попишите пока без всего этого сахара'
Ближе к окончанию школы на меня вышли HRы и сказали, что одна из команд хочет со мной поговорить о дальнейшем сотрудничестве. Ожидание тянулось, накопленная подушка безопасности заканчивалась и я понял, что пережидать новогодние праздники я просто не могу и выложил резюме на HH
Забавный момент - HRы компании это быстро заметили, попросили снять его с публикации, аргументируя тем, что собеседование будет назначено 'вот вот', но я просто скрыл свой профиль для них
Как я попал на текущее место - я не представляю. Им был очень нужен миддл, который имел бы хорошие навыки английского языка, а пришел джун, хоть и с английским. Но после разговора, небольшого лайв кодинга и еще одной беседы я попал в восхитительную команду и стал грызть апи гугла
Краткость - не мой конёк, но когда то нужно и остановиться. В целом от мой путь от самых первых попыток устроиться на работу до текущего места. А то, чем я занимаюсь тут и хочу заниматься дальше, пойдет уже отдельным тредом
Тред (Арсений Александров)
Кстати, всегда твиттер воспринимал как площадку, где без набросов, жалоб и токсичности не обойтись, но, возможно, это будет тот самый опыт, когда можно будет обойтись без этого и просто потравить истории
Ах да, темы недели
Не знаю - поступлю ли я правильно, но пока что я не знаю в каком порядке они будут идти. Если мини темы, есть крупняк, есть боль, есть истории. Пока, вроде, без лайфхаков, бест практис и карго культа. Каждый будет делать свои выводы
А так - список тем: книги по разработке, релокация, выгорание (а точнее то, как мы себя к нему любим приводить), внезапное тимлидство, личные финансы, евангелизм в разработке, работа с постановкой задач, структуры компаний, смена работы, расскажу про текущую, удалёнка
Проблемы имплементации clean architecture, боли gradle (особенно в связи с крайне специфичными девайсами), разговор про 'идеальную компанию', про работу с банковскими картами на уровне андроида, про набор и онбординг сотрудников, про английский язык в сфере
Зарплатные ловушки, контроль со стороны начальства, разговоры про зарплату с коллегами и будет, скорее всего, что то ещё
Вот так заходишь в мобильный аккаунт про кишки почитать, а тут тебе этими управленчиствами тычут :)
Тред (Арсений Александров)
На новосибирскую ночь кину одну из любимых пикчей
Вторник
Есть мнение, что покупать книги по разработке не имеет смысла, потому что сначала они, во время написания, отстанут от технологии, про которую рассказывают, потом будет публикация, книжка попадет к вам на полку, будет прочитана и станет не самым полезным источником правды.
А если вы ещё ждете русской версии - тогда дело становится совсем гиблым, потому что между отправной точкой создании книги и до вашего прочтения может пройти 3-5 лет!
За это время гугл успеет задеприкейтить 60% работающих библиотек, создаст ворох экспериментальных, но так и не даст инструмент, который будет хорошо работать и подходить под ваши требования. Или же API будет абсолютно неузнаваемым
Однако есть отдельная категория книг, которая не рассказывает о конкретных технология, которые меняется часто, но вместо этого старается рассмотреть культуру кода/архитектуры/разработки как эволюционирующее явление с выявленными полезными шаблонами
Это может быть GOF, это может быть Java Concurrency in Practice, а в моем случае - это книги Боба Мартина Clean Code и Clean Architecture. Их несомненный плюс в том, что читая их, будучи джуном, ты вникаешь в материал достаточно поверхностно, но тебе уже интересно
И спустя год ты снова берешь эту книгу, читаешь её и начинаешь куда лучше понимать практики, которые ты старался переизобрести каждый день, видишь проблемы, с которыми сталкивались до тебя и чувствуешь, что не один плаваешь в этом океане знаний, боли и постоянной гонки технологий
А какие книги по разработке вы купили или хотели бы купить себе (или очень раздражающему джуну), чтобы периодически их перечитываеть, находя что то новое?
Тред (Арсений Александров)
Пообещал себе, что на следующей работе ни за что не соглашусь писать толстый клиент. Столько усталости из за этого оффлайна и постоянных проблем синхронизации накопилось, что хочется уже и кнопочки иногда покрасить и подвигать
Сегодня в очередной раз решалась задача, когда крайне плохой стационарный интернет, необычный флоу использования устройства и отсутствие хороших способов распознать систему на раннем этапе приведут нас к потере пользовательских данных
Каждый раз эти пограничные ситуации требуют целого исследования 'а что там происходило то' и каждый раз приходит к фиксу, но вот осадок то остается. А еще большое количество усталости, конечно же
А все потому что в свое время было очень тяжело понять как именно писать систему синхронизации данных и на какие вещи смотреть в первую очередь. По крайней мере среди мобильщиков я всё ещё не нашел таких статей
А искать то надо было в бэкэнд топиках. Когда спустя год понимаешь, что последовательно три раза переизобретал воркер с обработкой ошибок, приоритетами и уникальностью задач - ты идёшь переизобретать его в четверый
Тред (Арсений Александров)
Одной из последних вещей, на которые я, похоже, подсел в проектах - это деление на проекта на модули. Сначала был переход на котлин, который забрал package-private и многие классы отныне стало возможно трогать куда чаще, а затем app модуль стал уже совсем ненавигируемым
Мне кажется где то определенно есть предел того, сколько модулей стоит делать и есть best-practice того, как это стоит выполнять. Кто то предлагает делить по слоям, как в clean, кто то говорит о feature модулях
В любом случае, даже с узкими интерфейсами повсюду и отсутствием связанности 'абстракция зависит от реализации' - это всё ещё напоминает месиво из package, которое очень старательно пытается скрыть все внутри себя через internal и сообщить наружу только формат взаимодействия
Так что если есть хорошие советы про то, как вы делили свое приложение, ловко разрешали circular dependency модулей в dagger, не утонули в количестве бойлерплейта и почему вас не бесит 47 очень похожих build.gradle файлов в проекте - поделитесь мудростью, о мудрейшие :)
Тред (Арсений Александров)
Закончу день двойным мемом
Среда
Про постоянные приколы с девайсами, с которыми приходится работать. Когда я думал, что, разрабатывая под андроид, буду на парочке самсунгов проверять работоспособность приложения и потом пихать в прод - как же я ошибался
Большая часть девайсов, с которыми вы работаем, представляют из себя крайне интересные вундурвафли с 8 юсб, COM порт, RJ-45 и, чаще всего, встроенный принтер, а иногда еще и сканер для штрихкодов
Ты подключаешь два принтера по юсб, два по bluetooth, один через локальную сеть и принимаешься печатать чеки разной ширины, длины и через разные форматы печати производителей. Туда же идут кейсы продажи, синхронизации данных мужду устройствами, но эту уже куда привычнее
Девайсы такие не продаются в магазине, чаще всего у них нет гугл сервисов, и из за специфики их использования приходится решать задачи постоянной поддержки приложения в памяти, на переднем плане, а иногда без возможности закрытия
Доходит вплоть до того, что мы пишем свой собственный лаунчер, который гарантирует нам то, что приложение будет постоянно активно и будет поддерживать постоянную работу остальных наших и сторонних интегрированных приложений, делаю эдакую экосистему для ритейла
Тред (Арсений Александров)
Происходит второй день спасание релиза от выпуска в крайне нестабильном состоянии. Как же хочется уже перейти на новое апи с нормальной консистентностью данных
По запросам @jack_martynov
Есть связка устройства и сервера. На устройстве создается заказ, у заказа есть есть id, который по умолчанию равен нулю. При первой отправке на сервер происходит выдача инкрементального уникального id
Затем заказ продают и создают локально ещё одну сущность 'продажа', у которой есть транзакции. Эта сущность не может быть отправлена на сервер до тех пор, пока не была отправлена первая
Есть статус заказа, который мы используем чтобы двигать его от InProgress/InDelivery/Delayed до Deleted/Done. Этот статус надо поменять после окончания продажи, чтобы заказ более не выдавался в активных и не было возможности его редактировать
Также есть статусы синхронизации заказа Syncing/Synced/Charging/Charged/Removing/Removed/Delayed/Failed/Blocked. Эти статусы исключительно локальны и о них не знает сервер
Плюс есть еще транзакции через наличку, терминал, чеки, подарочные карты и т.д., которыми можно оплатить заказ не в один присест, а в несколько
И все это время ты можешь находиться в оффлайне, один из запросов может оборваться посреди исполнения (когда сервер уже получил данные, но не успел отдать нам ответ), пользователь еще может удалить заказ или оплатить часть заказа и потом пойти дополнять его
И все это в условиях того, что большая часть сущностей не может просто создаться и отредактироваться локально и независимо друг от друга - нужно сохранять порядок перехода статусов, исполнения запросов и быть готовым ко всем этим неожиданностям
Плюс бэкенд часто любит игнорировать некоторые части сущностей - допустим, если заказ оплатили частично и пока еще нельзя создать экземпляр продажи - его транзакции хранятся только в нем. И при отправке на сервер - они их игнорят и не сохраняют
Также нельзя сначала закрыть заказ и затем сделать продажу, чтобы сразу скрыть заказ с радаров 'активных заказов'. Иначе получишь 423
В общем возникает две проблемы:
Мало того что несколько устройств могут менять данные одной сущности - это еще делает и сервер
Хранение данных на старом апи сделано очень неудачно (как по структуре, так и по скорости доступа)
Поэтому очень хочется перейти на новую версию апи, которую уже пользует iOS, где девайс стал куда самостоятельнее, а бэкэнд просто верит нам и хранит все как надо. То есть наконец то появился главный источник истины
Тред (Арсений Александров)
Мне кажется это какая шутка
Я часа три не мог понять почему не могу с телефона прогрузить Твиттер, думал даже что нашел баг, а оказывается ночью сяоми обновился и добавил Твиттер в список приложений без доступа к мобильной сети
Чувствую поражение себя как девелопера
Прямо среди написания твита оно решило попробовать вернуть себе вообще все привелегии
Не так то быстро
Traditions, traditions
Желаю всем такой же странной и абьюзивной любви, как у Google и AsyncTask
Четверг
Про контроль со стороны начальства: какие два разных подхода я видел
Полное спокойствие и самоконтроль, когда никто не смотрит во сколько ты появился в онлайне - главное присутствовать в определенные часы (допустим с 11 до 4)
Есть софт, который автоматом подтягивает задачи с джиры и трекает в них время и время от времени делает скриншоты экрана, которые потом никто не смотрит
Другой подход. Приходишь на работу в офис в определенное время (иначе вызванивают или тебя нужно прикрывать, что ты вышел покурить), прикладываешь свой палец на входе на этаж, когда приходишь и уходишь.
В течении дня вручную логаешь время в джиру, бэк сопоставлял эти два времени, записывала их твой график отработанных часов и сравнивала с тем, сколько ты должен был отработать
Если ты выпадал даже на 10 минут - тебе приходилось писать заявление уровня ‘я во вторник буду работать 6 часов, потому что в среду планирую работать 10 часов’. В итоге, конечно, неопытные люди работали 8 + 12 часов, потому что не боялись выгореть.
Ты писал такое заявление даже если сообщил руководителю об этом изменении и он был не против. Чаще всего тебя готов был хоть весь отдел прикрыть, когда тебя пытались прессовать на эту тему
Если ты страдал переработкой - тебе это никто не оплачивал, даже если по другому проект было не закончить. Максимум - можно было взять раз в пару месяцев 1-2 дня отгула за счет переработанных часов, написав на ещё одно заявление
А бывало ли у вас такое, что начальство было помешано на контроле, но потом удивлялось, что отработанные часы сходятся с планом, но задачи все равно не выполнены?
Тред (Арсений Александров)
О том как я сам набираю сотрудников. Поначалу я участвовал в этом процессе просто как член команды со своим мнением. Обычно тихо сидел где то неподалеку от тимлида и слушал. А потом тимлид ушел и тимлидом стал я. Про это будет отдельная история
Проблемы набора существуют во многих аспектах: от непостроенного бренда до крайне специфического типа андроид разработки. Поэтому, как это вышло со мной, мы все время набираем джунов, стараемся делать так, чтобы не мешать им расти и, я считаю, что получается неплохо
Очень приятно, что однажды шанс показать себя дали мне и на это дело не закончилось. Так что скиллбоксы и гикбрейнсы - вот вам гарантированное устройство начинающих разработчиков :D
С джунами всегда так, что нет смысла гонять их слишком долго и уж тем более не стоит расстраиваться, если они чего то не знают. А вот посмотреть на то, пытается ли человек думать или просто юлит, когда не знает ответа - тут всегда пожалуйста
Во всем и всегда работает замечательное правило ‘относись к другим так, как ты бы хотел, чтобы они относились к тебе’. Поэтому хоть я и разработчик - прежде всего смотрю на софт скиллы и пытаюсь понять будет ли мне и остальным комфортно с ним на удаленке и в офисе
Я очень люблю задать глупый вопрос или поставить заведомо неверное утверждение из базовых знаний по теме и услышать, что то вроде 'это дичь какая то, разве нет'. А если человек не знает и вырулил на логике на какую то почву - это тоже прекрасно
А еще бывает забавный момент, что я знаю, на какие задачи я нанимаю людей, какой мне нужен человек, знаю все вплоть до адреса человека, но никогда не знаю на какую зп берут человека. Однажды даже был курьезный случай с повышением - можно будет рассказать
Тред (Арсений Александров)
Ну и как же не пошутить про мой любимый clean
Пятница
О выгорании, о том как я внезапно этим летом с такой проблемой столкнулся. Все мы любим истощать свой организм и психику ненужным трудоголизмом. И можно замечать, как тебя это бесит, но продолжать так делать
Кого то гонит вперед постоянный синдром отличника, у кого то это синдром самозванца, не позволяющий насладиться своим профессиональным прогрессом. Кто то боится сменить компанию из за синдрома хорошего парня. Что объединяет все эти и другие странные названия?
А то, что это преграды в нашем поведении, которые очень часто заставляли как меня, так и моих знакомых айтишников заниматься проектом, который был им абсолютно неинтересен или находиться на специальности, которая давала им задачи, которых они не хотели.
Очень важно понимать, что как бы не были громадны и богаты компании, которые нас могут нанять - мы не обязаны им большим, чем планирование и выполнение своих рабочих задач. Все остальные преграды мы строим себе сами, пытаясь выстроить какие то свои рамки ‘хорошего содрудника’
Был ли у вас опыт выгорания? Отправлялись ли вы в длительный отпуск или уходили из IT? Какова ваша главная причина покинуть текущее место работы - может это проект? Команда? ЗП? Локация?
Тред (Арсений Александров)
Суббота
Вчера ведение твиттера было поставлено под очень большое сомнение, когда уже в 12 по мск я сидел на корпоративе и чиллил
Будем наверстывать на выходных
Я в одном из предыдущих постов упоминал курьезный случай с повышением и решил о нем чуть подробнее рассказать. Ко мне как то пришел сотрудник и сказал, что у него скоро должен состояться ужеполугодичный ревью и он бы хотел получить повышение
Вопрос не страшный, мы поговорили, он спросил что бы он мог сделать, чтобы как то прокачаться - я сказал, что ему очень хорошим опытом зайдёт менторство над каким нибудь джуном. Почувствовать себя в шкуре руководителя, понять что не бывает глупых вопросов и прочее
В итоге к моменту ревью я был уверен, что сотруднику можно дать повышение, о чем и сказал ему и директору и довольным этим пошел себе дальше работать. Тревожный звоночек был тогда, когда сотрудник спросил у меня насчет размера аванса - всегда ли он вот такой или нет
Помучив его немного я понял, что не знал его текущее ЗП, а он не знал до какого уровня его повышают. В итоге после нескольких попыток поиграть в глухой телефон через меня я сказал сотруднику, чтобы он просил столько, сколько хочет и не боялся показаться наглым
Затем мне написал директор, что мой коллега что то возмужал, стал уверен в себе и просит больше, чем ему думали предложить
Long story short - сотрудник получил свои деньги, директор поймал спокойствие, я узнал на каких деньгах сидят мои сослуживцы - все счастливы. Правда вчера сотрудница по моей просьбе призналась сколько она зарабатывает и я минут 5 сидел с убитым видом и мыслями 'да почему вы так'
Тред (Арсений Александров)
В последнее время все чаще возникает ощущение, что code review не нужен и только тормозит нас. При этом если его отменить - я прямо вижу как за пару спринтов кодовая база начнет цвести всеми цветами стилей. Могут ли автоматические lint проверки спасти от всего
Воскресенье
Не планировал набрасывать про code review - это скорее была усталость от неопытного пользования таким инструментом
И спасибо всем за дискуссию на эту тему!
Сегодня мой последний день на этом аккаунте
Ведётся активная подготовка к переезду в Питер через неделю, исследование всех тех подходов, что были описаны в ответах. Хочу поблагодарить всех прежде всего за ваши ответы
Прежде всего я очень хотел увидеть какую то активность и немного стремался вести этот аккаунт, потому что уверен, что количество моей технической экспертизы пока ещё недостаточно, чтобы быть готовым к любым вопросам. А с другой стороны это не собеседование
Хочу пожелать всем поменьше алгоритмов из учебника на собеседовании, побольше стабильных релизов, поменьше метаний между хайповыми технологиями и побольше интересных фичей
Посмотрим что подарит нам jetpack в будущем - станет ли compose окончательным мейнстримом, как Котлин, проснется ли древний ужас TDD в умах ПМов и сколько ещё изменений по permissions и deprecated фичей нам выдаст Гугл. Всего всем наилучшего!
Тред (Арсений Александров)