Один день айтишника

Случается, что проект заканчивается, а новый проект для тебя еще не нашли. Такая особенность работы в аутсорсе, что поделать. Срок простоя может быть от нескольких дней до нескольких месяцев. И тут твое времяпровождение будет сильно зависеть от компании и от тебя самого. В моем случае я просыпаюсь тогда, когда хочется. Если куратор дает какие-то учебные задания, то делаю задания.Если нет заданий, то либо прожигаю время в соцсетях, либо что-то изучаю в интернете (лучше бы в обратной последовательности). Учебные задания похожи на реальные, поэтому есть смысл привести еще пример, чтобы новички могли понять специфику (мне в свое время этого не всегда хватало). Например, на последнем простое я делал задачу на PySpark. Был предоставлен фрейм данных, содержащий информацию по криминальным событиям в городе по районам с различным типом преступлений, временем совершения и т.п, нужно посчитать статистику, т.е какой район самый криминогенный, какие преступления чаще всего, в какое время суток и т.д.

В целом коллектив огонь, руководство по отношению к сотрудникам - топ (я после работы в автобизнесе по началу слезу пускал, когда сюда устроился и получал человеческое отношение), задачи часто клевые и интересные.
Мне с одной стороны повезло, что было разнообразие проектов, с другой - не очень, т.к срок участия на проекте в среднем не большой и не успеваешь глубоко погрузиться. Плюс не повезло с большим простоем, но тут и моя вина, т.к у меня были свои требования к желаемому стеку на следующем проекте. Минус главный один - зп ниже рынка.
Но какие галеры этим не грешат?

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

2. Проект в крупном российском банке.

Здесь мой рабочий день начинается в 10-11. Просто потому, что каких-то утренних созвонов нет вообще, и я могу сам регулировать свой график. У меня было большое задание, которое я делал на всем протяжении работы над проектом. В общих чертах, заказчик предоставил бизнес-требования, в которых указал какие поля и с какой логикой
нужно добавить в имеющуюся витрину данных. Витрина - это таблица в хранилище данных, которая содержит тематическую и узконаправленную информацию. Моя задача заключается сначала в аналитике, т.е нужно понять, как нужное поле создается, в какой таблице взять значение, с какой таблицей сделать сравнение или что с чем поджойнить, чтобы получить нужное. Часто приходится созваниваться с ментором, а потом с банком, чтобы разрешить возникающие вопросы. После аналитики я пишу код на SQL, который выполняет все необходимые манипуляции. На основе полученного запроса, в программе SAS DI создаю ETL - процесс получения данных из источников, их преобразование и загрузку в целевую таблицу (витрину). SAS DI
позволяет достаточно просто строить ETL с помощью графического построения этого процесса. Буквально рисуется блок-схема, в который есть блоки-таблицы и блоки-преобразования. Блоки соединяются стрелками в том порядке, который нужен для логики ETL. Внутри некоторых блоков с помощью интерфейса добавляются нужные поля, джойны, условия и другие преобразования. В отдельных случаях пишется код, который берется из того самого начального скрипта. Запускаю полученный ETL, если есть ошибки - исправляю, если ошибок нет сравниваю полученные данные с ожидаемыми, если сходится - экспортирую файл с ETL и отправляю сотруднику банка. Далее банк запускает ETL на тестовом сервере и проверяет корректность работы, если все плохо - отправляет на доработку мне, если хорошо - ставит на прод. ETL чаще всего запускается ежедневно, поэтому я скрещиваю пальцы и жду следующего дня. Бывает, что из-за того, что тестовые
данные сильно отличаются от продовских, возникает некорректный результат. В этом случае снова аналитика и доработка.

3. Проект в крупном российском букмекере.

По времени работы день аналогичен предыдущему проекту. У компании уже было реализовано хранилище данных, само собой включая ETL. Требовалось провести унификацию, т.е приведение к единообразной форме, отдельной части ETL, отвечающей за загрузку данных в таблицы справочники. Заказчик предоставил уже унифицированные джобы, которые можно брать в качестве эталона.
Утром я обновляю свою ветку git. В excel-файле смотрю с каким из пакетов ETL никто из коллег не работает, после в графическом редакторе ETL SSIS (программа похожая на SAS DI) открываю джоб и сравниваю его с типовым джобом. Чаще всего и проще всего за основу беру какой-то эталонный джоб и изменяю наименования таблиц и полей, часть изменений вношу в SSIS, часть - редактирую открыв файл джоба в xml. Внутри джоба используется процедура, написанная на T-SQL. Эту процедуру я также редактирую в соответствии с требованиями унификации, т.е убираю лишние джойны, фильтры, группировки, добавляю нужные и т.п. После запускаю джоб, проверяю, что он отрабатывает без ошибок, смотрю на адекватность полученных данных. После чего делаю коммит, потом старший разработчик его ревьюит и делает слияние с общей веткой. В течение дня при возникновении вопросов созваниваюсь с ментором. С разработчиками заказчика созваниваемся раз в неделю, где сообщаем о проделанной работе.

Отдельно выделю рабочий день во время bench (простоя).

Junior #Data Engenier.
Я Влад.М. @volllander, 1 год 3 месяца опыт работы (реальных в бою месяцев 7), зарплата 60000 руб net. Удаленка.

Компания крупный российский аутсорс, предоставляющий услуги в области BI и Big Data в России и некоторых зарубежных странах. Заказчики в основном банки, телеком и ритейл. Большое количество проектов позволяет получить опыт работы с различным стеком технологий. Компания достаточно лояльно относится к начинающим айтишникам, поэтому можно получить первую работу с относительно небольшими знаниями. Для джунов проводят различные обучения, всегда есть ментор, который помогает им на проектах.

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

1. Проект CRM в топ-3 российском банке.

Мой рабочий день начинается в 10 утра с созвона на 15мин, на котором каждый участник команды кратко рассказывает о том, что он делал вчера, с какими сложностями столкнулся и, что планирует делать сегодня. Задачи планируются на две недели, в конце каждой недели созвон на час-два по итогам. Затем смотрю, какая на меня запланирована задача, открываю Confluence, в котором читаю техническое задание к задаче.Все мои задачи заключались в написания скрипта обработки пользовательских ошибок. Суть в том, что сотрудник банка (кампейнер) создает некую CRM-компанию: обзвон клиентов с финансовыми предложениями, SMS или отправку e-mail. При создании компании он заполняет различные параметры: к какому типу относится клиент(юр.лицо или физ.лицо), какие у него счета, возраст физ.лица, даты последней активности и многие другие. Для разных CRM-компаний существуют различные требования к этим параметрам и, нужно сделать так,
чтобы введенные пользователем параметры соответствовали этим требованиям. Здесь как раз и начинается моя работа. С помощью скриптов на достаточно специфичном языке программирования SAS Macro и всем известном SQL, я пишу всевозможные проверки получаемых от пользователя параметров. Простой пример, CRM-компания создается для физических лиц, а пользователь по ошибке добавляет юридических. В этом случае,создается проверка типа пользователя, при неверном типе выдается ошибка, которая логируется в специальную таблицу, а пользователю отправляется сообщение о некорректности данных. После написания скрипта я делаю коммит в свою ветку GIT, который ревьют старший разработчик, если все хорошо, то делаю слияние с общей веткой, если нет, то получаю фидбек и дорабатываю скрипт. При возникновении каких-либо сложностей, а особенно на первом проекте у меня это было каждый день и много-много раз, я созваниваюсь со своим ментором и мы вместе разбираемся в коде. Рабочий день в основном заканчивается в 19 часов. Бывает случается, что просто не успеваешь сделать задачу в срок, тогда можно поработать на час-два больше или начать свой день раньше, но переработки у нас не любят тем, что возрастает риск выгорания сотрудника. Переработки дополнительно оплачиваются.

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

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

#QA Engineer manual, 3 месяца опыта ( в резюме больше), зп 100к рублей и полная удаленка ( можно и вне рф). Работодатель - издательство.

День начинается в 12:00 - дейли
Официально рабочий день с 10 утра и до 19 вечера, но раньше 12 редко что-то просят, обычно разработчики живущие в других городах и странах ( другой часовой пояс). 15-20 минут на разговор кто и что делал вчера и будет делать сегодня. В команде примерно 15 человек.

Полный скрам, спринты и тд, задачи двигают по необходимости

В Jira видишь задачи в статусе « готовы к тестированию», назначаешь их на себя и приступаешь к тесту. По необходимости дёргаешь разработчика с вопросами

Со мной в команде ещё два тестировщика, мы с ними делим задачи по интересам, кому и что больше нравится

Работа редко занимает больше 2-3 часов, только если есть сложности с локализацией ошибок

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

Один день из жизни #Angular разработчик на внутреннем проекте в компании, у которой какие-то проблемы с линиями и пчёлами.

Зп чуть меньше 3к бачей

Мой день никогда не начинается до дейлика, который начинается в 12 и идёт минут 30. Оунер по очереди всех опрашивает чё по задачам и я включаюсь только тогда, когда дело доходит до меня. В иных случаях обсуждаются весьма скучные темы. Так это уже можно считать вполне себе работой, то после этого я иду либо кушать, либо пить кофе и курить, либо просто занимаюсь каким-то своими делами, никак не связанными с работой. В дни вдохновения могу почитать доку, или поучить новую технологию (очень редко). Могу сходить прогуляться, в магазин и тд. А можно и во флудилке посидеть...

Всё выше перечисленное работает только тогда когда сделана хоть одна таска за последние два-три дня. В противном случае я начинаю тревожиться изза того, что меня могут уволить, что поймут что я не настоящий программист, что мне опять придётся врать что-то на дейли. Я ещё почему-то думаю, что опаздываю только я и никто больше. И от этого мне ещё тревожнее. Но это не так. Все проёбываются одинаково. В такие дни я молюсь о том, чтобы про меня вообще не вспоминали. И при всём при этом работаю всё равно по настроению.

Я могу сколько угодно ныть о том, что я плохой программист, или что у меня ничего не получается, но факт остаётся фактом – задачи рано или поздно закрываются. Все довольны.

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

Так как я один фронт на проект, ревью у меня никто не проводит и я не провожу.

Иногда я могу созвониться с бэкендерами или тестером, если мне что-то не понятно.

Перед релизом у меня все задачи закрыты и даже на дейли меня уже никто не трогает. Сказка, а не жизнь.

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

Александр, Senior #Java Developer.
7.5к евро

График:
9:00-10:00 Открываю ноут, пишу в общий чатик что начал работать. Обычно действительно делаю текущие задачи. Смотрю ревью. Большинство коллег еще спят
10:00-11:00 Можно продолжить работать, можно делать свои дела. Коллеги продолжают спать.
11:00-12:00 Коллеги потихонечку просыпаются, начинают теребить с вопросами. Ну либо я их.
12:00-12:30 Тут у меня два дейлика, общаюсь с коллегами. Если нечего сказать, потому что вчера был непродуктивный день, говорю "Ну вот задача есть, пока разбираюсь, нечего сказать особо".
12:30-13:30 Ухожу на обед
13:30 - 15:00 После того как покушал, обычно работоспобность падает. Можно пойти подремать минут 15-20. Обычно в это время работаю лениво, либо вообще не работаю.
15:00-17:00 Тут случается прирост продуктивности, работаю более менее активно
17:00-18:00 В некоторые дни в это время проходят регулярные митинги. Если их нет, на работу обычно не остается ни сил ни желания, спокойно занимаюсь своими делами. В конце желаю всем хорошего вечера и закрываю ноут.

Работаю обычно по 30-40 минут с перерывами 15-20 минут. Бывают такие дни, когда работать вообще не хочется. Это нормально. Надо просто немножко поднапрячься в следующие дни и все будет хорошо.

Задачи:
1. Поправить баг, запилить немножко функционала. Основной тип задач, обычно на них уходит больше всего времени. Делаются по алгоритму: прочитал задачу, че непонятно - спросил. Примерно прикинул как делать. Сделал. Отдохнул. Написал тест. Отдохнул. Закинул на ревью, взял следующую задачу.
2. Что-то типа R&D. Задача типа "разберись как сделать такую то штуку". Алгоритм: сижу, думаю как сделать. Придумал вариант 1. Отдохнул. Проверил вариант 1. Отдохнул. Повторяю пока не закончились варианты. Когда закончились, иду разговаривать с заинтересованными этой задачей коллегами, вместе решаем че делать дальше.
3. Срочно поправить баг с прода. Случается редко, если случается то перехожу в режим "жесткой работы", на этапе анализа созваниваемся со всеми, кто может помочь с расследованием бага. Общаемся, находим причину, решаем кто будет править. Если это я, то быстро решительно правлю, закидываю на ревью, заливаем это на тестовое окружение, скрещиваем пальцы, зажмуриваемся, выливаем на прод. После обычно радуемся. Фактически в этот день можно больше не работать, слишком много физических и моральных сил было потрачено на решение бага.

Помимо непосредственно программирования, нужно уметь нажимать на кнопки в Jira и Jenkins (этому вы научитесь на работе, тем более кнопки везде разные), иметь базовые навыки работы с git.

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

Один день из жизни Senior #Android разработчика в российском ритейле Магнит

Михаил Б., 4 года опыта, з/п 350k, полная удаленка

У компании много разных продуктов, в основном связанных с доставкой всего разного на дом. Я работаю над приложением сборщика заказов для курьеров.

У приложения нет версии под iOS, только Android, так как сборщики используют специальные устройства с интегрированным сканером штрихкодов. Репозиторий хостится на гитлабе, разработка ведется в 4 пары синьорских рук. Проект многомодульный, архитектура чистая, кодовая база новая, java и легаси отсутствуют. Используется Git, есть пара основных веток и несколько видов дополнительных: для фичей, багов и релизов.

Рабочий день начинается в 9-10 утра, просматриваешь свои задачи, созваниваешься с другими android-разработчиками обсудить состояние проекта. В 12:00 начинается утренний дейли, проходит в Microsoft Teams, без камер, длится полчаса-час, участвует вся команда - это человек 20: продакты, менеджеры, аналитики, дизайнеры, разработчики, тестировщики. Один из руководителей шарит экран с открытой доской jira и поочередно тыкает на каждое имя, работники высказываются в формате «‎что делал вчера, что будет делать сегодня, какие есть проблемы/блокеры». После того как все отстрелялись, проходят различные обсуждения и задавания вопросов.

После дейли обычно продолжается работа над уже начатыми тасками, либо в работу берутся новые. Условная задача (сверстать экран с бизнес-логикой) дробится на несколько более мелких подзадач, дизайн и взаимодействие с бекендом - также отдельные задачи, так как бекенд может быть еще не готов. Дизайн берется из Figma, системные и бизнес требования аналитики расписывают в Confluence. Обычно из этой стены текста все равно нихуя не понятно, что в итоге должно быть сделано, поэтому связываешься с ответственными по задаче в чатах, созваниваешься и все что не понял - уточняешь. Далее в IDE создается новая ветка с именем таски и начинается перекладка плитки. Средняя задача занимает непрогнозируемое количество времени, если просят оценить - ориентируешься на свой опыт + учитываешь ошибку планирования. Иногда от тестировщиков прилетают задачи пофиксить баг. Пример: (кнопка упаковать заказ не отображается если указать один из товаров как нет в наличии). Тестировщик в тикете максимально подробно описывает суть, прикладывает видео, если оно есть, пишет фактические и ожидаемые требования. Такие таски занимают от 10 минут до часа.

Готовая таска двигается по джире в сторону ревью и тестировщиков, указывается затраченное на выполнение время. Ветка с задачей выливается в удаленный репозиторий и назначается на ревьюеров, два разработчика смотрят твои поделки, если что-то не ок - читаешь комментарии и дополняешь/правишь код, если все ок - таска вливается в ветку с версией и с помощью CI улетает тестировщикам. Бывает, что merge request висит никому не нужный - неделями, поэтому иногда нужно заходить в него и ресолвить конфликты, которые неизбежно появляются из-за обновления других веток.

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

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

Один день из жизни Senior #iOS разработчика в американском финтех стартапе.

Дмитрий А., 7 лет опыта работы, зарплата $6000, полная удаленка.

Обычно я встаю около 10 утра, к 11 начинаю работать.
В 11 у нас утренний созвон - дейли, где все рассказывают что они делали вчера и что планируют делать сегодня. Я рассказал что починил 2 бага и планирую делать фичу которую от меня ждут.
На встрече присутствуют все члены команды - около 10 человек, разработчики iOS, Android, Web, бекенда, дизайнер и менеджер проекта.
Если у ПМ есть какие-то замечания или просьбы, он говорит что теперь поменялся приоритет, посмотри вот эту таску.
После дейли я открываю джиру, смотрю там свои задачи, у нас есть доска где задачи расставлены по приоритетам. Беру верхнюю, если надо меняю статус.
Задачи обычно типовые, сделать экран, или улучшить старый экран, или поправить баг на старом экране.
Беру фичу, в этот раз это онбординг для новых пользователей. У меня есть ссылка на проект в Figma где видно какие экраны надо сделать, все расстояния до всех элементов, если есть какие-то кастомные картинки можно их достать оттуда.
Обычно на этом этапе ты понимаешь что то что нарисовали сделать сложно, и есть путь попроще, пишу в слаке дизайнеру, давай сделаем вот так, обычно он соглашается, если не соглашается пишу ПМу, он делает какую-нибудь встречу где я объясняю что делать с нуля новый элемент и его анимации это долго, часов на 40, а взять встроенный часа на 4. Обычно перед таким мало какой менеджер может устоять и дизайн слегка правится.
Я делаю новые классы, расставляю элементы, создаю модели для работы с бекендом если нужны.
Обычно экран делится на саму верстку, на подключение бека и локализацию/аналитику, под всё есть отдельные задачи.
За день делаю 1-2 задачи, например сверстал и сделал локализацию.
Если есть вопросы иду к локализаторам, пму, дизайнеру.
Обычно за день иногда может написать менеджер и сказать вот срочный баг, возьми его следующим.
Если фичи все новые сданы, есть куча багов которые надо править. Обычно это легкие фиксы которые правятся за 10-15 минут. Таких можно сделать штук 5 за день и на следующем дейли чувствовать себя дартаньяном, когда рассказываешь это команде.
Мой ПМ после этого любит меня чуть больше как мне кажется.
Когда закончил задачу я делаю пуш, отправляю пул реквест в девелоп ветку и пишу коллегам в общий чат или в личку чтобы они посмотрели.
Иногда коллеги пишут днем - посмотри пулл реквест, на это тратится минут 10 обычно на каждый, бывает 1-2 в день максимум. Надо посмотреть код который он написал что все с ним хорошо и оставить замечания, либо нажать аппрув.


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

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

__________________________

Один день из жизни Junior #iOS разработчика в Германии

Я - Глеб Мартынов, @gvmrtnv, пол года опыта работа, зарплата 5000 €, удаленка 90%. Проект MyAudi - приложение для владельцев соответствующих авто и удаленного управления ими.

Компания - 10 летний, разросшийся до 80 человек стартап с пачкой идентичных приложений для немецкого автопрома. Хоть продукт уже давно не молод, продолжается постоянная доработка новых фич в сотрудничестве с концернами. Так как компания технически ориентированная, идет постепенный переход на SwiftUI. Пока что (в течение первого месяца) моя работа заключалась в разработке визуальных компонентов для фреймворка на SwiftUI, устранении багов.

Рабочий день я начинаю рано - просматриваю свои тикеты в Jira, проверяю изменения по моим пул реквестам в GitLab, доделываю таски по мелочам, чтобы было что рассказать на дэйли. На дэйли всей командой проходим по тикетам в Jira-борде и исполнитель рассказывает в свободной форме как обстоят дела с задачкой. Кто-то ограничивается тремя словами, кто-то начинает разводить такое обсуждение своих вопросов, что скрам мастеру приходится это присекать.

В команде 3 Android, 4 iOS разработчика, скрам мастер и продакт. Поэтому темп работы не высокий, рук хватает и от меня как новенького в проекте вообще не ждут особого ничего. Работаю только по собственной инициативе, если бы неделю рассказывал, что смотрел код - никто бы не возмутился. По остальным тоже не видно, чтобы кто-то упахивался, русский коллега с опытом подтвердил мои наблюдения.

После утреннего дейли я продолжаю работу над задачками. Если задачки коничились, ищу новые не занятые в Jira и задалбываю коллег вопросами, что же там имелось в виду (контекста я понятное дело не знаю и в приложении не ориентируюсь). Вопросы стараюсь раскидывать по разным людям, которые мне кажутся наименее занятыми. Также в течение дня происходят от нуля до пяти звонков различной продолжительности, где я пытаюсь не потерять концентрацию и понять, кто и вообще о чем вещает. Иногда задаю вопрос коллегам, что же это такое было - на что получаю не менее размытые ответы. В общем у нас много внешних команд, с которыми идет активная коммуникация, о которой вся команда должна быть в курсе. Раз в две недели езжу в офис, чтобы поболтать с коллегами из других внутренних команд и проявить присутствие.

Пример фич:
- Сделать кнопочку на SwiftUI фирменного стиля по макету из Zeppelin. Кнопка уже была, я добавил только возможность вставлять туды иконку.
- Сделать пикер с колесиком на SwiftUI. Оформленное поле уже было, я добавил только колесико и пару Binder.

Пример бага:
- Процент зарядки аккумулятора машины лагает после завершения анимации. К тикету приложили видео с демонстрацией. Потратил пока несколько часов на билд приложения и получения нужного аккаунта с машиной, которая лагает.

Когда задача закончена, создаю пул реквест в GitLab (при помощи Tower), двигаю свой тикет в столбик review в Jira и выбираю везунчика, который эту красоту будет проверять. Пока что в ходе ревью выяснились следующие косяки:
- надо заполнять Changelog при каждом пул реквесте
- я неправильно понял, какую именно кнопку хотели и тикет висел неделю недоделанный
упустил отступ обозначенный в дизайне.

Пока как зеленый джун бывает засиживаюсь до поздна, чтобы поменьше людей заметило, что я пул реквест час открываю. Те, кто мой уровень заметил, говорили, что все оки-доки, но я паникер. Бывает задачку закончу и вечером начинать новую уже лень или уже никого нет, кто введет в курс дела - тогда сворачиваюсь пораньше. Работа для новичка просто отпад.

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

Один день айтишника pinned «Новички IT-сферы плохо представляют из чего состоит рабочий день в их профессии. Часто поступают запросы вида: "Дядь, а вот расскажи, что ты вообще делаешь на работе то? А то я чет курсы прохожу, а что делать буду не понимаю" Такая непрозрачность убивает…»

Пример багов:
- после добавления картинки к карточке задачи (attach image), ее превью не отображалось на экране задачи, хотя во фронтенде была видна. Это было связано с ошибкой синхронизации и поддержкой оффлайн мода. Логика приложения не перезагружала UI даже после завершения загрузки картинки. Пришлось добавить пару коллбеков, сделать collectionView.reloadData(), все заработало
- кнопка "retry upload", которая показывалась после ошибки загрузки, ничего не делала. Связано с хуевым реактивным кодом, который после ошибки завершал подписку и больше нажатия кнопки не слушал. Починил исправив код, сама логика повторной попытки загрузки уже была написана.
- выделение метки на чертеже спадает через секунду после нажатия. Связано с дублирующимися событиями, которые летят из js ядра, на котором написан фреймворк для просмотра чертежей. Пришлось погрузиться в javascript, записать логи, отослать их человеку, который отвечал за ядро, и попросить его починить. Задачу с меня сняли, решили или нет не знаю по сей день.

Новые фичи тоже надо делать, но очень редко. Продукт в целом устраивает пользователей, менять его уже особо не надо, так, изредка вносить изменения под видом улучшения и доработки. Фичи делать весело, потому что не надо ни с кем общаться, дизайн есть, требования есть, API с данными готово. Знай программируй! Дальше все так же, pull request, code review, тестирование, done.

Примеры фичей:
- Добавить на экран "Скачивания и Загрузки" информацию о текущем состоянии загрузки картинок/видео. Они типа могут грузиться в бэкграунд моде приложения, поэтому пользователю надо видеть, что у него приложение делает, загрузилось уже или нет. Делалось через Realm, заняло около 500 строк кода и 4 рабочих дня. Все оч просто, через completionHandler в URLSessionDataTask в Realm писался статус загрузки объектов. Экран "Скачивания и Загрузки" подсчитывал эти объекты и писал 3 загружено/5 загружается
- Миграция на новую версию API. Несколько запросов объединили в один, другие разбили, чуть поменяли формат данных в JSON. Скурпулезная рутина, где главное не поломать то, что уже работает. Делал около недели, основное время ушло на выяснения деталей нового API, потому что документации как обычно не было.

Я считал свой рабочий день законченным, когда проверял все задачи и убеждался, что везде я что-то написал/спросил и мне есть, что рассказать завтра. Работал только когда все детали были у меня, иначе забивал до завтра. Уходило от двух до пяти часов. Хорошая работа.

ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot

После рабочего звонка я открываю таск-трекер Jira и просматриваю все задачи, назначенные за меня. Там хаос, потому что многие задачи живут месяцами в ожидании вялых ответов от пользователей. Поэтому каждый день я проверяю не появилось ли нового ответа, следуя стандартному процессу. Процесс выглядит в среднем так:
- Прилетает задача с описанием "нихуя не работает! Вообще пиздец!" и 3 минутный видос, где чувак чето тыкает в приложении. Видос по идее должен показывать, что мне нужно чинить, но обычно из него ничего не ясно
- Я копирую из заметок и отправляю вежливый комментарий, что-то типа "простите, извините, а можно чуть поточнее? Ожидаемое поведение? Реальное поведение? Устройство? Версия приложения? Добавьте меня в вашей проект"
- *ожидание/повторы вопросов с целью выжать максимум информации*
- Если пользователь продолжает конструктивный диалог, предоставляет нужную информацию, то приходится открывать IDE и пробовать воспроизводить. Если пользователю западло чето объяснять, то я выжидаю неделю, предупреждаю, что задача будет закрыта за недостатком вводных. И закрываю, ура, задача решена.
- В починке бага в таком проекте самое сложное – воспроизвести. Сценарии иногда поражают воображение: начни загрузку, включи выключи вайфай, войди в airplane mode, заблокируй телефон, разблокируй, перевени, останови загрузку и ты увидишь ОШИБКУ в одном случае из десяти! Пытаться починить этот ужас самому – лишиться личной жизни, мне за это недоплачивают. Поэтому обычно я выделяю себе час/два на попытки воспроизвести баг, если у меня не получается, перекидываю тестировщику с пометкой "не воспроизводится". Если и он не сможет воспроизвести, можно забить и закрыть.
- Иногда баг все же воспроизводится. После этого начинается поиск места, где же все таки ошибка. Довольно редко тут помогает логика и знание проекта, все чаще точки остановки дебаггера раставленные наугад по всему проекту. Иногда приходится разбираться в сложной бизнес логике, условях и ответах бэкенда. Лучший вариант: обнаружить, что косяк НЕ У НАС, а в соседней команде/на бэкенде. Можно кидаться задачкой в них и забывать про нее. Худший вариант: баг все таки на стороне iOS. Обычно это пара строк кода/лишнее условие, которое исправляется за несколько минут после обнаружения.
- Вношу правки, проверяю, что остальное приложение продолжает худо бедно работать. Пишу на починенный баг тест, если это представляется возможным. Создаю pull request через github, максимально подробно описываю проблему и решение, чтобы чуть облегчить жизнь моим последователям
- Жду пока мои правки посмотрят коллеги. Они должны отписать что-то вроде "вах, норм". Таким образом мы делим ответственность, если я накосячу, то нельзя будет ткнуть пальцем только в меня, виноваты все, а следовательно никто не виноват.
- После подтверждения от коллег pull request сливается в develop, CI отсылает сборку приложения с моими изменениями тестировщику. Он проверяет, что баг больше не воспроизводится. Если все ок, закрывает задачу, если нет, возвращает ее мне с пометкой "ты хуй, работай лучше"
- Такое перекидывание задач продолжается, пока она всем не надоест/не починится

_________________________________________

Один день из жизни Senior #iOS разработчика в Autodesk

Я – Антон Назаров, @m0rtymerr, 5 лет опыта работы, зарплата $9100, полная удаленка.
Проект bim360, что-то вроде google drive для чертежей с возможностью просмотра 3D визуализаций, правок и комментариев.

Компания – огромная корпорация, поэтому каждым приложением занимается несколько команд, каждая из которых отвечает за свои экраны и не лезет в зону ответственности чужую. Так как продукт уже на рынке и за него отваливают большие денюшки, большая часть моей работы посвящена поддержке. Мне приходится разбирать входящие запросы об ошибках, воспроизводить их на своем устройстве и пытаться починить так, чтобы остальное приложение продолжало работать.

Мой рабочий день начинается с ежедневного звонка с командой. В ней Android разработчик, бэкендер, фронтенер, дизайнер и менеджер. Цель этого утреннего ритуала ответить на три вопроса "Что делал вчера? Что будешь делать сегодня? Что-то мешает/блокирует?". Все вяленько отчитываются о своих успехов, менеджер полузевая благодарит за успешную работу и желает хорошего дня. За полгода работы я ни разу не слышал чего-то вроде "хули так долго" в чью либо сторону.

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

Новички IT-сферы плохо представляют из чего состоит рабочий день в их профессии. Часто поступают запросы вида:

"Дядь, а вот расскажи, что ты вообще делаешь на работе то? А то я чет курсы прохожу, а что делать буду не понимаю"

Такая непрозрачность убивает мотивацию, мешает приоритизировать получаемые знания. Да и просто смехотворна, на кой хрен тут нужна завеса тайны?

Цель канала – делиться опытом через прозрачные рассказов о буднях работающих ITшников. Присылай свою историю: любые грейды, специализации и страны. Не забудь рассказать про себя немного фактов: компания, зарплата, года опыта. Если хочешь приложи контакт, вдруг у кого-то будут вопросы.

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

ПРЕДЛОЖКА ДЛЯ ИСТОРИЙ: @one_IT_day_bot
Плейлист интервью с работающими специалистами об их буднях

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

Channel created