Сергей, #python #backend
4 года опыта, РФ, зп 250к р, удаленка

Начинается день с дейлика, просыпаюсь за пару минут до него (дейлик без камеры).
В это же время параллельно смотрю есть ли созвоны в календаре и мр'ы от коллег
После дейлика чаще всего иду чилить или спать.
Какого-то ежедневного рабочего графика у меня нет, потому что таски я откладываю до последнего дня. Т.е. беру новую задачу, чекаю, что меня по ней ничего не заблокирует в процессе и несколько дней по ней ничего не делаю; просто хожу на созвоны, чекаю мры и все. Но стараюсь давать корректную оценку команде, когда я ее закончу. Потом в какой-то день сажусь на несколько часов, чтобы ее сделать.
В итоге за всю неделю в среднем у меня уходит около 4 часов на созвоны и 10 на разработку, коммуникации, ревью мров.

Конечно, изредка возникают критикал проблемы на проде, и такие таски не откладываю. Но такое происходит раз в 2 месяца.
Никогда не работаю по вечерам и в выходные, даже если что-то не успеваю (кроме очень критичных редких штук)

По процессам: работаем по спринтам, вместе со всей командой обсуждаем все таски, декомпозируем их, задаем вопросы бизнесу через аналитика, даем оценку по времени.

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

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

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

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

Всем привет!
Александр #backend #nodejs #19yo

Мой суммарный доход: 200 + 150 вечнодеревянных руб.

Пояснение + совет для ребят кто учится / имеет призывной возраст: я не учусь, т.к. считаю это лишней тратой драгоценного времени (а как мы знаем, энергия молодости 😏 постепенно угасает), но моим единственным щитом является военник с очень вкусной категорией. Поэтому те, кто задумался о карьере айтишника – так же позаботьтесь о своём щите (академ, поиск болячек и документов для В/Д категории, переезд в соседние страны СНГ)

Daily routine:

10:00 Подъем - готовлю вкусный сбалансированный завтрак (омлет с мясом + салат или какой нибудь йогурт /сэндвич из доставки).
Привожу себя в порядок, читаю непрочитанные в ТГ, доделываю должок по задачам основной работы, отвечаю в рабочих переписках

11:00 Дейли - дружно общаемся в канале дискорда, обновляем статусы по задачам (мол, вчера починил такой то запрос, который падал с ошибкой, сделал такую то фичу), расходимся. Estimate: 10-30 min.

P.S. так же вместо дейли могут быть другие scrum-встречи

– Sprint review 🕵️ или в простонародье демонстрация - встреча команды и представителей бизнеса на которой мы показываем результат за последний спринт. Проходит каждую итерацию (у нас ~2 недели). Estimate: 1.5 часа
– Грумминг 🐩 - мероприятие, на котором мы детализируем, оцениваем и декомпозируем задачи на более мелкие, чтобы их можно было выдать конкретному разработчику (делаем понятное описание как и что делать, оцениваем в стори поинтах) Так же проходит каждую неделю. Estimate: 1 час
– Планирование спринта - чем то похоже на грумминг, но там больше уделяется времени на высокоуровневые цели, которые будут выполнены к концу итерации (какой то жирный кусок функциональности). Estimate: 2 часа

11:30 - 18:00 Основная фаза работы. Каждый день может быть совершенно не похож на предыдущие, но если усреднить - обычно это:
– Решение критических проблем на стендах (то что сильно ломает работу системы / блокирует других)
– Созвоны на которых мы помогаем / менторим друг друга по решению текущих задач
– Непосредственно разработка кода фичи
– Работа в Gitlab (настройка репозиториев, MR, ревью и т.д.)
– Research (дебаг проблемы, анализ различных библиотек для решения задачи, написание документации, использование ChatGPT и прочих инструментов, рисование диаграмм)

P.S. Документацию у нас пишут аналитики, но есть часть доки сугубо техническая (README), так что иногда приходится развивать и такой навык
P.S.2 - естественно в большинстве случаев я не приварен к стулу, так что в промежутки между работой обедаю, выхожу в город по делам. Непрерывно работа занимает не больше 5 часов

18:00-19:30 Немного физической активности: прогулка / упражнения из фитнес приложения

Так же в период с 18:00 до полуночи есть некоторые задачи по второй работе. Занимают в сумме они 1-2 часа в день, т.к. это скорее дружеский стартап, и там своя специфика. Я играю роль lead backend + lead DevOps, в это время я работаю над бэклогом в Jira, помогаю решать задачи, провожу встречи и т.д.

Так же веду канал, в котором делюсь своей экспертизой по части роста в IT на личном опыте: t.me/alexcupert

Вступай в ОМ | Расти в IT | Присылай историю

#backend #node.js
1/2
Здаров🔥

Я Аркадий, мне 20 лет, backend node.js developer, зпшка 115к на новом месте и 120к на предыдущем(знаю, для накрученных  2 лет и 9 месяцев мало).
Работать начал в конце августа 2023 года, на данный момент реального опыта около 4 месяцев, ибо с последнего места работы ушёл по причине реально хуёвого отношения к сотрудникам. Также, помимо работы, учусь в униче, на очном отделении(на прогера). Резонный вопрос, а зачем мне учиться там? А вариантов, на данный момент нет, я либо учусь в шараге, либо иду играть в пабг в реальной жизни(с категорией годности А1)🪖. Вообще, уник занимает много времени, не спорю, но меня особо это не парит, я стараюсь учиться не в напряг(если интересно, могу рассказать как это делать). Летом, также как мой друг-фронтендер Дмитрий, буду пробовать проходить собесы на 250к+.

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

С другом-фронтендером ведём свой блог, где рассказываем наш айтишный путь, что интересного за наш небольшой опыт произошло на работе/в жизни, на что стоит обратить внимание, когда уже работаешь. Короче, рассказываем полезную инфу, которую, в принципе, рассказали бы и себе начинающим🫡

Вообще, все мои дни максимально непредсказуемы(могу всю ночь протусить, остаться у кого-то на ночёвке и, в любом случае, в послетусовочном состоянии выхожу на работу/и в шарагу), но если искать что-то среднее, то прошу к ознакомлению:
7:20-9:00 - подъём, вне зависимости от дня недели(сразу скажу, в зависимости от пар сижу в унике до 16-16:30). Небольшая зарядка(не поход до холодильника за пивом, а потягиваня, анжуманя, прэс кочят, бегит). Далее завтрак, чаще всего гречка - самое норм для завтрака.

12:00 - 12:30 - во время пар сливаюсь на дейли, там рассказываю что получилось по задачам, какие есть вопросы, что нужно доработать и что буду делать сегодня. На предыдущем месте работы могли вообще дейли растянуть до 1.5 часов(как-никак небольшая фирма с бэд процессами)

17:00-20:00 - делаю рабочие таски(вообще, я чаще всего делаю их на парах, но этот промежуток как запасной, на всякий случай, если не успею сделать в униче). Если тасок нет или всё готово - дёргаю в зал, для поддержания себя в форме

20:30-22:00 - делаю уже что-нибудь по шараге , заказываю лабы и дз у одногруппников или на сайте, или тупо вбиваю всё в ChatGpt, чтобы не засорять всякой хернёй себе мозг. Мне, честно скажу, не интересно вникать в эту хуету, которая и так отнимает слишком много моего молодого времени, ведь его я действительно могу потратить на себя (в любом отношении)🤬

22:00 - 7:20 - время, когда начинается самый ебейший движ: катаемся по городам зимой на тачке как ахуевшие, а летом на самокатах/велосипедах, просто гуляем, ходим по хатам, можем арендовать сауну, также я, во время каникул,редко, но могу уехать в другую страну(уже ограниченное количество таких стран) и потусить там

Ловлю ли я выгорание с таким движем? Да, раньше такое бывало, но, я научился более-менее распределять своё время не во вред психологическому состоянию🤖



Теперь немного о рабочих задачках:
1. Так как фирма новая, чаще всего приходилось писать новый функционал. Сам по себе бекенд был не сложный, просто много делать, то есть что-то взять из бд и отправить фронту или что-то принять и закинуть в базу, ну или отправить на обработку в сторонний сервис. Короч, всё просто крутилось вокруг средненьких по логике эндпоинтов. Например, возможность пользователю подгрузить свою фотографию. И, как я упомянул ранее, в последней фирме были хуёвые процессы => задачки ставили в jira в 2-4 слова, причём всё строилось на словах, мол: сделай поиск по каталогу кремов. Окей, его я сделал и мне говорят примерно следующее: "А чё он всё выдаёт, где есть это слово, а не то, что мне надо". Да ёбаный в рот, пропишите сразу что нужно сделать😡

#go #golang #backend
Привет! С сентября 2022 по август 2023 работал в озоне мидлом-бекендером на стеке: Go, Postgres, Kafka. На начало работы: полгода опыта на Go, до этого 2 года с перерывами студенческий парт-тайм на C, зп: 200к. Команда поддерживала способы того, как продавцы загружают свои товары: эксельки, гугл-таблицы, свои таблицы и т.д. Состав: 5 беков, 2 фронта, 2 тестера.

11:00-11:30 Дэйли-созвон, на котором говорю что делал вчера и что планирую делать сегодня. Долгие вопросы, если есть, решаются после на других созвонах.

12:00-17:00 Работа. Фикс багов/разработка новых фичей и всякое общение вокруг этого.

Процесс взятия фичи в работу: формирование микротимы (1-2 бека, 0-1 фронт, 1 тестер) с выбором ответственного; чтение доки на конфлюенсе от аналитиков c требованиями; созвоны/переписка с уточнением требований; распил фичи на таски и оценки; созвон микротимы перед лидом с финальной оценкой срока когда будет в проде;

Пара примеров характерных фичей, которые я делал:

1. Продавцам надо было грузить эксельку, чтобы поправить уже загруженные товары. Очевидно, что править было бы удобнее на самом сайте. То есть пользователь понатыкал своих товаров из списка, нажал редактировать. Ему прилетает таблица с характеристиками этих товаров, он редактирует их и жмет отправить. Вот такую табличку и надо было сделать на фронте/беке. Собственно реализация бека: смотрим, какая категория у натыканных товаров. По категории готовим заголовки таблицы, заполняем таблицу с текущими строчками для товаров, и отдаем для отрисовки фронту.
И тут унылые тонкости, которые надо закодить. Ну например, если товары из разных категорий, то заголовки таблицы - это какой-то минимальный хардкод наиболее общих параметров по типу цены или бренда. Сами заголовки могут быть сложными: быть объединенными в группы; идти в каком-то определенном порядке; иметь подсказки; иметь какие-то конкретные значения для заполнения; быть запрещенным для редактирования для каких-то типов товаров и т.д. Для сбора всей этой инфы ходим в ряд чужих микросервисов. Добавляем метрики, как часто юзают фичу. На первое время фича закрыта A/B-тестом.

2. Чтобы загрузить новые товары, продавцы шлют эксельку. Товары за деньги можно продвигать в выдаче. Делать это можно было позже, после загрузки товаров. Чтобы продавцы активнее юзали фичу, я вшил в эксель-шаблоны для загрузки поле “включить продвижение” со значениями “да/нет”. Чтоб сразу могли его прожать при загрузке. Также это поле появилось при генерации эксель-отчетов, в которых продавец смотрел какие у него товары.
Реализация: юзер просит выдать ему шаблон на загрузку товаров. Сервис экселек смотрит на роль юзера. Если он какой-то правильной роли, ему в таблицу вшивается эта колонка. Когда он грузит заполненную эксельку, вытаскиваем помимо прочего инфу о продвижении, (а) сохраняем у себя, и (б) прокидываем в чужой микросервис, который этим занимается. Когда генерим эксель-отчеты, которые смотрят актуальный статус товаров, для заполнения конкретно поля с продвижением, идем в чужой микросервис (б) и смотрим, включилось бы продвижение. Когда генерим эксель-отчеты, которые хранят историю того, что продавец грузил, то смотрим, что сохранили у себя (а). На первое время фича закрыта A/B-тестом.

Процесс попадания на прод: написал на код; выкатил на тестовое окружение и минимально потестил; попросил код-ревью коллег; после одного апрува передал ручному тестировщику; после его апрува нажал на кнопочку выкатить в прод в пайплайне на gitlab.

Длительность выполнения таких фичей ~2-4 недели.

Короче говоря, за исключением эксцессов, таких как 4 месяца распила монолита, писал вот такую незамысловатую бизнес-логику. Красило ее то, что это был типа хайлоад и много данных, так что были всякие индексы, реплики, шардирование и мониторинг. Основными сложностями по части разработки новых фичей было разобраться с требованиями и узнать, как юзать API чужих сервисов, потому что игнорить или отвечать на отъебись при межкомандом общении очень любили.

#Backend #Java
дороу👋
Я джун java разработчик, 24 года, работаю в крупном российском корпорате.
По зп с учетом премий выходит около 300к. Разработчиком работаю меньше полугода, но на проекте в целом уже больше 2 лет.

Как так получилось?
Работал на проекте бизнес-аналитиком и в какой-то момент на one-to-one с руководителем объявил, что после завершения работы над крупной задачей уйду с команды, спустя пару дней пришла мысль перейти в разработку, обсудили это с менеджерами и спустя 6 месяцев самостоятельной подготовки перешел на другую роль. Опыт работы в аналитике - 4,5 года

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

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

Мой примерный распорядок дня:
07:00 - подъем, рутина
У нас недавно родился ребенок, помогаю с утренними процедурами
09:00 - начинаю работать
10:00 - общий дейлик с командой и отдельно с разработкой
10:00 - 19:00 решение задач + бывают какие-то влеты по встречам:
валидация тз, помощь команде эксплуатации или еще какие-то задачи, где нужна моя какая-никакая экспертиза

По решению задач:
Каждая задача детально описывается аналитиками, совместно с архитектором и user story приходит с довольно проработанным ТЗ.
Тимлид разбивает ее на таски и раскидывает на разработчиков.
Стек почти каждый раз для меня новый, приходится разбираться на ходу, от этого часто страдаю, но зато мне проще вкатиться в суть бизнес-логики.

19:00 - 22:00 бытовые вопросики
22:00 - 00:00 в основном творчество: работаю над подкастом и каналом или учусь

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

Вступай в сообщество | Расти в IT | Присылай историю

#java #backend
Senior Java-разработчик в банке
Доход 500к: ~400 с работы + 100 менторство
2 года опыта

Хочу рассказать сегодня о процессах релиза в крупном российском банке. Огромное количество вакансий на java, да и всех ITшных - это крупные банки. Многие новички где-то слышали, что в банках долгие процессы, релизы и тд. Сегодня хочу приоткрыть эту завесу и рассказать как происходят процессы в таких компаниях, чтобы новички-вкатуны знали, что их будет ждать крупных компаниях и не боялись ходить на собесы. Кстати, у меня есть статья о эффективном прохождении собеседований

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

Как задача появляется с самого нуля и доходит до релиза в продакшн. Каков её путь? В первую очередь, стоит понять, что задача не появляется просто из ниоткуда или из воздуха.

Задачи возникают из требований бизнеса.

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

Начало
Бизнес обращается в команду, которая занимается идентификацией и регистрацией пользователей и излагает требования и сроки. Бизнес общается обычно не со всеми членами команды, а с продукт-менеджером. Продукт-менеджер затем сообщает команде эти требования, чтобы команда понимала, что от неё хотят.

Этап аналитики
Задача ставится перед аналитиком, чтобы он проанализировал и собрал требования для этой задачи. Когда бизнес говорит, что ему нужна какая-то функция, он не собирает все требования и не анализирует их полностью, а просто выражает желание. Задача аналитика - собирать требования, обращаясь к смежным системам, спрашивая, могут ли они предоставить нужные данные, какие протоколы взаимодействий (http, kafka, grpc…)

- откуда будем получать данные паспорта пользователя
- как проверять данные, куда их затем отправлять
- какие внешние системы будут участвовать в этом процессе, как хранить данные пользователя
- как будем отказывать в верификации, как уведомим пользователя о том, что верификация прошла

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

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

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

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