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

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

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

P.S. И да, заранее закладывайте в сроки все те мероприятия, которые необходимы вам для достижения того качества, которое вы хотите соблюсти на данном проекте.

[Бесплатно и только для женщин] Круглый стол-девичник: «Борщ, дедлайны, 2 декрета: как быть женщиной в современном мире и не сойти с ума»

Сначала нам диктуют, как жить и где работать. Потом говорят, что мы должны работать наравне с мужчинами, но не дают этого делать. А потом требуют совмещать быт и работу. Быть современной женщиной чертовски сложно. Быть женщиной в IT — почти нереально. Но мы справляемся. И вам расскажем!

13 спикерок собираются вместе 📅 5 декабря (четверг) в 19:00 (МСК), чтобы обсудить:

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

Невыдуманные истории женщин, о которых невозможно молчать, и наша Girls Power в действии.
❗️ Вход только для женщин. Включенная камера обязательна. Анонимов будем удалять со стрима, чтобы нам никто не помешал.

📅 Дата и время: 5 декабря (четверг) с 19:00 до 21:00 по Москве.
🎙 Спикерки: Леся Набока, Люда Пак, Наташа Гришина, Оля Федосеева, Марго Лукина, Наташа Давыдова, София Сидорова, Ира Мазаева, Надя Гнусина, Карина Жданова, Ангелина Зинченко, Настя Румянцева, Настя Никулина. Умницы, красавицы, великолепные экспертки.

🔖 Как участвовать: Через обязательную регистрацию https://careerfactory.timepad.ru/event/3138085/
❓ Задавайте вопросы и рассказывайте истории — оставляйте их в комментариях к посту, и мы обязательно обсудим их на встрече.

💬 Дамы, приходите сами и берите с собой подруг. Мы вас ждем. Мы вам рады ❤️‍🔥
#GirlsPower

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

Радикальная идея!

Часто слышу мнение, что при поиске работы нужно как можно больше откликаться на разные вакансии (вплоть до того, чтобы рандомно кликать даже на те, который совсем не подходят), чтобы пройти как можно собеседований. Предполагается, что такой путь максимизирует количество офферов, из которых можно будет выбрать самый лучший. У меня по этому поводу есть радикальная идея - не нужно как можно больше откликаться на разные вакансии, достаточно того, чтобы откликнуться на несколько вакансий, но самых “вкусных” для тебя.

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

Однако понять, какие вакансии интересные, а какие нет - не такая простая задача, как может показаться на первый взгляд. Она осложняется тем, что в вакансии обычно пишут самую общую информацию о сфере деятельности компании и проекте + пару-тройку общих фраз вроде наличия печенек на кухне, но никогда не указывают такие важные моменты, как уровень инженерной культуры, к примеру. Поэтому, на мой взгляд, самый надежный способ поиска работы, к которому прибегаю лично я - это через знакомых и друзей, чьему мнению я доверяю. Второй способ, который мне нравится - это чтение блогов интересных мне компаний: из них можно понять, какие вещи более важны для проектов в конкретной компании, а какие - менее. Соответственно, я стараюсь выбирать компании с более интересными для меня проектами - в моем случае это “толстые” клиенты со сложной логикой, дизайн системой и ui kit-ом.

Выбрав пару-тройку интересных для себя вакансий, нужно максимизировать свои шансы на эти вакансии попасть. Я для этого редактирую свое резюме отдельно под каждую интересную мне вакансию, описывая подробнее более релевантный вакансии опыт и сокращая менее релевантный. Это увеличивает шансы быть приглашенным на собеседование. По моему опыту - если откликаться на вакансию, релеватную опыту, оформить резюме и сопроводительное, то конверсия “отклик - собеседование” близка к 100%.

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

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

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

Стоило мне только написать про поиск работы, как в ленте хабра попадается классная статья на ту же тему. Делюсь ей с вами: https://habr.com/ru/articles/872244/

Софты рулят?

Часто встречаю мнение, что основополагающее в карьере программиста - это софты, а не харды. Но так ли это на самом деле?

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

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

Насчет «умения нравиться» в контексте карьеры программиста я осмелюсь высказать радикальную идею: больше всего нравятся программисты с сильными хардами. И чем сильнее харды, тем сильнее нравятся. Лиды и менеджеры ищут специалистов, которые решат их проблемы и не создадут новых. Отсюда растут ноги у баек про токсичных сеньоров: они всех достали, но уволить нельзя, потому что кто-то должен работу работать. Поэтому, если вы хотите нравиться и получать хорошие офферы - будьте полезными, а не просто «дружелюбными и нетоксичными».

А что насчет «софтов»? Считаю ли я, что они не нужны? Отнюдь. Но планка требований к «софтам» для программистов резко отличается от планки для продавцов или, скажем, политиков. На мой взгляд, программисту требуются два основных «софт скилла»: 1. Быть адекватным в общении 2. Не продалбываться.

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

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

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

Дело в хардах

Я наблюдала, что бывает, когда про человека говорят, что у него “хорошие софты” или “плохие софты”, дело на самом деле не в софтах, а в хардах, которые ошибочно принимают за софты. Расскажу два примера из своей профессиональной жизни.

Много лет назад, когда я была джуном, в одной из компаний на перфоманс ревью мне поставили “ниже ожидаемого” по софтам (по хардам поставили “соответствует ожиданиям”). Тимлид пояснил на встрече, что моя проблема в том, что я не высказываю свое мнение, соглашаюсь со всем, что мне предложат и не умею дискутировать - просто соглашаюсь. Таким образом, я из боевой единицы, которая способна мыслить и принимать решения, становлюсь обычным исполнителем. Но почему я не высказывала своего мнения? Дело было в том, что я была джуном и у меня вообще тогда не было никакого профессионального мнения. Я старалась освоиться в технологиях, моим единственным требованием к моему коду было “чтобы работало” и я плохо понимала, чем “хороший код” отличается от “плохого кода” и что значит “потекшая абстракция”. Удивительно ли, что при отсутствии мнения я его не высказывала? Мне поставили “ниже ожидаемого” по софтам, однако вся моя проблема была в хардах. Как только я прокачала свои харды (в плане формирования профессионального мнения особенно помогла известная книга банды четырех), у меня сразу же появилось мнение, которое я стала высказывать (иногда даже слишком часто :D но это уже другая история).

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

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

Про работу “с горящими глазами” и “просто работу за деньги”

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

Моя радикальная идея заключается в том, что это ложная дихотомия. В жизни я видела другую картину: одним достается все - интересные проекты, которыми они занимаются с удовольствием, высокая зарплата, и те самые “горящие глаза”, а другим - нууу… тоже какие-то деньги, да. Давайте разберемся, как так получается. Допустим, Вася - тот самый программист “с горящими глазами”, который с кайфом работает свою работу. В какой-то момент Вася решает, что все тлен и теперь он “просто работает за деньги”, а сферу своих амбиций он лучше перенесет в пятничные посиделки с друзьями. Вырастет ли от этого зарплата Васи? Черта с два. Единственное, что вырастет у Васи, так это недовольство жизнью и усталость в конце рабочей недели.

Для того, чтобы зарплата Васи выросла, необходимо, чтобы выросла объективная ценность Васи на рынке, а это произойдет, если Вася получит новые навыки и научится решать более сложные задачи. То есть Васе нужно 1) Брать на работе более сложные задачи 2) Учиться новому после работы. Проблема людей, которые готовы терпеть свою работу исключительно за деньги в том, что у них совершенно нет сил и мотивации после работы заниматься тем же, но бесплатно. Не говоря уже о том, чтобы брать на работе более сложные задачи вместо привычных, которые можно сделать, смотря параллельно сериальчик на втором мониторе. Люди, которым не нравится то, чем они занимаются, вынуждены тратить на это свою энергию и силы в то время как те, которым то же самое в кайф, наоборот, получают энергию от этого энергию и вдохновение. Поэтому те, кто кайфует от работы, продвигается по карьере, в то время как у “работающих просто за деньги” есть силы только на то, чтобы выполнять текущие задачи абы как, лишь бы их не уволили.

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

Как не продалбываться?

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

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

Такой способ позволяет на этапе исследования понять, как будет выполняться работа, а следовательно, и сколько она будет выполняться. К сожалению, он тоже не дает 100%-ной гарантии, однако точность его, на мой взгляд, достаточно высока.

Ошибка 90% резюме

Позавчера S0ER выпустил очень классное видео, в котором он рассказывает, на что обращают внимание при отборе резюме и собеседовании программиста, и в видео он сказал очень важную вещь - нужно учиться говорить конкретно. Это то, что я говорю 90% ребят, которые приходят ко мне за консультациями по своему резюме, и это то, на что я в первую очередь обращаю внимание при просмотре резюме и на собеседовании.

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

В комментариях к предыдущему посту задали правомерный вопрос про примеры хороших и плохих описаний своего опыта в резюме. Приведу несколько примеров:

❌ Занимался разработкой и поддержкой фронтенда на React.
✅ Занимался разработкой фронтенда приложения для покупки и продажи недвижимости. С нуля сделал интерактивные дашборды, показывающие динамику спроса/предложения по региону. Стек: react, redux, d3.js.

❌ Работал в команде из 5 человек над crm системой на React.
✅ Занимался разработкой crm системы. Добавил в таблицу заказов возможности фильтрации и сортировки заказов, сделал пошаговый визард оформления заказа. Стек: React, typenoscript, react query.

❌ Занимался поддержкой старых проектов, добавлял новый функционал, исправлял баги, рефакторил.
✅ Разработал с нуля и довел до продакшна два проекта для внешних заказчиков:
1. Систему бронирования туров для турагентства. Включает в себя интерактивный список туров, возможность перейти на страницу конкретного тура, пошагавшую систему бронирования. Стек: react, typenoscript.
2. Сайт товаров для домашних животных. Включает в себя каталог товаров по категориям, поиск, сортировки, фильтрации, добавление товара в корзину, оформление доставки. Стек: Vue, vuex.

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

Войти в айти

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

В этом посте расскажу про несколько обучающих курсов и стажировок, с которых можно круто стартовать свою карьеру.

1. Focus Start от компании ЦФТ https://team.cft.ru/start/school

Этот образовательный проект существует очень давно - я с него начинала свою карьеру frontend разработчика далеких 8 лет назад. В течение трех месяцев опытные наставники рассказывали нам про разработку на html, css, javanoscript и первом angular, после чего лучшие выпускники получили оффер от ЦФТ. Из 10 человек оффер получили 3 или 4 человека (точно не помню). Я, к сожалению, в число счастливчиков, начавших карьеру с ЦФТ, не попала, но обучение на курсе позволило мне довольно легко найти свою первую работу.


2. GPB IT Factory https://www.gazprombank.tech/digital/gpb-it-factory/

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

3. Школа от KTS https://metaclass.kts.studio/

Я сама год назад училась на курсе по python в этой школе. Берут всех желающих, но в финал обучения и защиту проекта попадают только те, кто завершил все предыдущие этапы в срок. Я не завершила этот курс (ушла на курс по Java в GPB), но, насколько мне известно, обычно до финала доходит 3-5 человек.

4. Стажировки VK https://internship.vk.company/internship

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

5. Курс по go разработке от компании Ozon https://route256.ozon.ru/go-developer-junior

Я буду пытаться попасть на него в этом году. Если получится, то подробностями буду делиться в канале :)

6. Стажировки от Т-Банка https://education.tbank.ru/start/

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

Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен state менеджер “. Дмитрий сделал действительно классный анализ существующих на данный момент стейт менеджеров (упустив, однако, effector и mobx), а также сравнил их с хранением состояния средствами react. Вставлю свои пять копеек.

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

- Стейт является структурой вида “ключ-значение”.
- Содержит геттер данных по ключу.
- Содержит сеттер данных, причем для каждого поля может быть только один сеттер. Этому требованию очень удобно удовлетворяет Redux: в нем принято писать один action creator, который возвращает action, и диспатчить этот action creator из разных мест приложения; но не удовлетворяет, например, effector, потому что он допускает установку данных как в push дизайне (вызов ивента), так и в pull дизайне (подписка стора на эффект). Почему это так важно, опишу позже.
- Удобные девтулзы.

Бизнес логику я распределяла и хранила в: 1. компонентах реакт (например, вызов запроса, если он вызывается только в одном месте), 2. в ts классах (отлично подходит для кода, не требующего механизмов реактивности), 3. в redux-thunk (в небольших приложениях) или 4. в эпиках rxjs (в больших приложениях). Таким образом, я изначально проектировала свой код так, чтобы стейт менеджеру отводилась роль хранилища, поэтому с проблемой, о которой говорит Дима, я за свой профессиональный опыт так и не столкнулась.

Для чего я вообще использую стейт менеджеры? Главная проблема, которую они для меня решают, возникает вовсе не в процессе написания кода, а в процессе поддержки и эксплуатации. Хранение глобальных данных во время написания кода - это вообще не проблема. Я могу легко написать код, который хранит данные где угодно - в реакт хуках, в контексте, да хоть в объекте window. Однако потом наше приложение постепенно обрастает пользователями и фичами, и рано или поздно мы неизбежно сталкиваемся с багом: в наших глобальных данных почему-то лежит не то, что мы ожидаем. Ждем foo, а лежит bar. И дальше наша - понять, почему так получилось, и устранить проблему. Для этого, во-первых, надо понять, какие данные записаны неверно. И вот тут-то пригождаются топовые девтулзы редакса: я просто открываю девтулзы и смотрю текущий слепок данных, в котором достаточно легко нахожу неверные данные. Дальше надо понять, откуда записались неверные данные. Для этого я ставлю в соответствующем action creator брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.

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

С большим удовольствием прочла классный пост Наташи про планировании и пару раз прослезилась от того, ну насколько же жиза!

Я уже писала выше: чтобы не продалбываться, очень важно не коммититься на то, чего ты не знаешь. То есть на вопрос «за сколько вы сделаете задачу, в которой хрен знает, что надо, в модуле, который вы раньше в глаза не видели» я отвечаю примерно так: «мне нужен день (полдня, два дня - не так важно), чтобы поковырять, а потом я дам оценку». Если за этот срок не удалось декомпозировать задачу на понятные мне куски, тогда я: 1. Называю срок работы над теми кусками, которые понятны 2. Говорю, что есть такие и такие непонятные куски, надо еще день (полдня, два дня), чтобы с этим разобраться. На этом этапе может оказаться, что задача вообще не стоит того, чтобы так долго с ней возиться, и на этом вы с менеджером можете порешать. Или уйти на новый цикл ресерча.

Про оценку задач

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

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

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

Так вот, что касается реализации, это всегда что-то потрясающе странное выходит.

Собирается вся команда (в моем самом дивном кейсе - 15+ человек), на стол начинают выкладываться задачки по одной (с которыми не дают ознакомиться заранее), и начинается доооолгое (самое эпичное на моей практике - 4 часа) гадание методом "пальцем в небо", совмещенное с азартными торгами.

Примерно так это выглядит:

Менеджер: - за сколько вы сделаете задачу, в которой хрен знает, что надо, в модуле, который вы раньше в глаза не видели?

Работник: - да кто бы знал. Там поресерчить бы. Заложим 5 часов?

Менеджер: - а чо не 4? Там, максимум, 4 часа будет!

Вот сам и делай за 4 часа, если все знаешь 🤌

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

И тут мне лид-бэк говорит шедевральное: "а ты что, не можешь оценить без дизайна и требований? Ну сколько, в общем, можно делать интерфейс?". Да как бы тебе сказать. От 3 часов до бесконечности, там миллион разных факторов влияет. А за сколько ты сам напишешь API без требований хоть каких-то, абстрактное такое API?

Короче, за все мои 4 с хвостиком года опыта я ни разу не видела ни в одной команде какого-то худо-бедно внятного планнинга, который не занимал бы вечность и не сводился к "то ли час делать, то ли до пенсии, но поставим 3 часа".

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

Сегодня общалась с человеком, который хочет попасть на летнюю стажировку по фронтенду, но боится не потянуть. Вдруг под “базовым пониманием Javanoscript” на самом деле скрывается требование знать наизусть последний стандарт ECMAScript?

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