Стоит ли учить [framework name]?

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

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

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

Но ведь [framework name] сделает мое резюме дороже?

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

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

На прошлой неделе прочла "Scrum" Джеффа Сазерленда. Делюсь с вами списком своих избранных цитат:

💡 Причина успеха методики проста. Я смотрел на то, как люди на самом деле работают, а не слушал то, что они говорят об этом.

💡 Любая задержка в рабочем процессе равно преступлению.

💡 Обнаружить ошибку как можно раньше и устранить.

💡 Планировать полезно. Слепо следовать плану - глупо.

💡 Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше (цитата из “Мифический человеко-месяц” Ф. Брукса).

💡 Дело было в базовой ошибке - и они ее не учли. Работники, ответственные за проект, считали, что можно спланировать все заранее.

💡 Карта - еще не живая местность.

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

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

💡 Помните, мы говорим об оценках, а не о жестких планах.

💡 Главное, что нужно запомнить - порядок [задач в беклоге] постоянно меняется. Правильный порядок для нынешней недели уже не подойдет для следующей.

💡 Одна из плохих привычек, которая может появиться у компании из-за постоянно меняющихся потребностей рынка или из-за недопонимания руководством, в чем основная ценность - это приоритизация всего подряд. Любая мелочь становится делом первостепенной важности. “Тот, кто защищает все, не защищает ничего”.

💡 Я уже говорил о взятом из боевых искусств понятии “сюхари” (Shu Ha Ri). В состоянии Сю человек четко следует правилам, таким образом знакомясь со стоящими за ними идеями. В состоянии Ха человек начинает создавать собственный стиль, но при этом остается в границах обозначенных правил, лишь адаптируя их под свои потребности. В состоянии Ри человек окончательно избавляется от правил и создает саму идею.

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

Друзья, у меня есть для вас радикальная идея: важно не КТО говорит, а ЧТО говорит. Если спикер - крутой перец и он рассказывает про какой-то подход, это не значит, что вам нужно срочно тащить его к себе. Вам нужно понять, в какой ситуации подход был применен, какой дал эффект и какая ситуация у вас. Если ваши ситуации схожи, тогда подход можно применить. Аналогично с менее известными спикерами. Короче, друзья: продуктивнее размышлять над идеей и подходом, чем над тем, достаточно ли сеньорный спикер про него рассказал.

С огромным удовольствием посмотрела дискуссию о SOLID Кирилла Мокевнина и S0ER. По поводу SOLID у меня есть некоторое количество радикальных идей и сегодня я хочу поделиться с вами одной из них. Она звучала в ходе дискуссии, но мне хочется сделать на ней особый акцент. Я сформулирую ее следующим образом: не проект для SOLID, а SOLID для проекта.

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

❌ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что Мартин написал, что нужно соблюдать DIP
✅ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что у бизнеса есть планы на эксперименты с разными калькуляторами и поэтому удобнее не хардкодить конкретный калькулятор

❌ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что так сделано во всех библиотеках
✅ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что у нас может быть много разных вариантов нотификаций и так мы сможем использовать компонент в разных вариациях

❌ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что отображение - это зона ответственности компонента по SRP
✅ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что у нас есть дизайн система и мы должны зафиксировать варианты отображения компонента, чтобы он выглядел везде одинаково

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

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

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

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

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

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

Принцип открытости-закрытости (OSP) побуждает нас не вносить ломающие изменения в код, от которого зависят другие модули.

Применение принципа постановки Барбары Лисков (LSP) позволяет нам в полной мере использовать полиморфизм и работать с интерфейсом объекта, а не с его реализацией.

Принцип разделения интерфейсов (ISP) помогает нам регулировать количество зависимостей у модуля.

И, наконец, принцип инверсии зависимостей (DIP) позволяет нам зависеть в коде от абстракцией, а не от конкретных реализаций, что позволяет динамически подменять эти реализации “на лету”.

Таким образом, если соединить все это вместе, то получается, что при проектировании наших модулей мы должны:

1. В первую очередь продумать интерфейс, (LSP, DIP);
2. Этот интерфейс должен позволять создавать абстракции, изменяющиеся вследствие решений одного актора (SRP) и не позволять лишних действий (ISP);
3. Этому интерфейсу может соответствовать несколько реализаций (OSP, LSP, DIP), что даст нам возможность использовать полиморфизм;
4. Частота изменения этого интерфейса должна быть обратно пропорциональна количеству его зависимостей (SRP, OCP).

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

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

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

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/