#Golang developer. 3.5 года опыта на Python + 0.5 года на Go на нынешней позиции. Работодатель — крупная компания с российскими корнями, 2к+ работников, после 24 февраля перевезла всех в Сербию, Турцию и Болгарию. Повезло устроиться к ним в январе и спешно вместе с остальными работниками уехать в Турцию в начале марта. В итоге в Турции и остался.
Работаем по Scrum, 2-недельные спринты. Утренний созвон в 10 утра каждый день, встаю либо незадолго до него, либо прям в 10 и созваниваюсь из кровати (классика). После созвона завтракаю, умываюсь и тщательно анализирую своё состояние. Я циклотимик, раньше принимал таблетки, нормализующее состояние, но в силу разных причин бросил и стал учиться жить с этим (не жалею об этом решении). К обеду если понимаю, что не могу взять себя в руки, сосредоточиться и сесть за работу, то даю себе добро на отдых и иду гулять/спать/на пляж/играть в игры. Если же состояние нормальное или хорошее, то могу весь день до ночи работать. Соответственно, иногда приходится врать на дейликах относительно текущего состояния таски, если за прошлый день ничего не смог сделать, но тогда в один из следующих дней наверстываю. В целом, честных часов 30 в неделе отрабатываю. В разбивке по дням где-то 9+9+5+5+2 получается.
За время работы в этой компании успел поработать над несколькими продуктами в рамках одного отдела. В основном просто пилю бэк и апишки, никакого rocket science. Последний проект самый приятный — сервис для внутреннего использования. Мне нравится тем, что всегда можно пойти к реальным пользователям предметно поговорить о том, какие фичи им нужны, а не доверять чуйке менеджера относительно потребностей сферического пользователя в вакууме.
Зарплата: 5000 евро до налогов. После налогов то ли 5000, то ли 3000 (40% налог). В Турции айти-компания может получить льготы, полностью освобождающие сотрудников от налогов, но это сложно и с марта до сих пор определённости с этим не появилось.
ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot
Работаем по Scrum, 2-недельные спринты. Утренний созвон в 10 утра каждый день, встаю либо незадолго до него, либо прям в 10 и созваниваюсь из кровати (классика). После созвона завтракаю, умываюсь и тщательно анализирую своё состояние. Я циклотимик, раньше принимал таблетки, нормализующее состояние, но в силу разных причин бросил и стал учиться жить с этим (не жалею об этом решении). К обеду если понимаю, что не могу взять себя в руки, сосредоточиться и сесть за работу, то даю себе добро на отдых и иду гулять/спать/на пляж/играть в игры. Если же состояние нормальное или хорошее, то могу весь день до ночи работать. Соответственно, иногда приходится врать на дейликах относительно текущего состояния таски, если за прошлый день ничего не смог сделать, но тогда в один из следующих дней наверстываю. В целом, честных часов 30 в неделе отрабатываю. В разбивке по дням где-то 9+9+5+5+2 получается.
За время работы в этой компании успел поработать над несколькими продуктами в рамках одного отдела. В основном просто пилю бэк и апишки, никакого rocket science. Последний проект самый приятный — сервис для внутреннего использования. Мне нравится тем, что всегда можно пойти к реальным пользователям предметно поговорить о том, какие фичи им нужны, а не доверять чуйке менеджера относительно потребностей сферического пользователя в вакууме.
Зарплата: 5000 евро до налогов. После налогов то ли 5000, то ли 3000 (40% налог). В Турции айти-компания может получить льготы, полностью освобождающие сотрудников от налогов, но это сложно и с марта до сих пор определённости с этим не появилось.
ПРЕДЛОЖКА ДЛЯ ВАШИХ ИСТОРИЙ: @one_IT_day_bot
👍47🔥19❤2👏1
#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 чужих сервисов, потому что игнорить или отвечать на отъебись при межкомандом общении очень любили.
Привет! С сентября 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 чужих сервисов, потому что игнорить или отвечать на отъебись при межкомандом общении очень любили.
👍45🖕3❤2🔥2