Сегодня. Донатный МК: “Progress Bar на HTML/CSS/JS”

Я очень благодарна всем , кто присылает мне донаты! И, в свою очередь, хочу за эти донаты порадовать вас, читателей, бесплатным открытым мастер-классом.

Сегодня мы с вами потрогаем ванильный JS, обсудим работу с DOM и то, как можно создавать кастомные UI/UX-элементы, которыми удобно пользоваться.

От вас нужно:

🔘базовые знания HTML, CSS и JS;
🔘 подготовленная песочница на Codesandbox или аналоге, чтобы вы могли кодить вместе со мной и задавать вопросы;

🗓 пройдет сегодня, в четверг, 11 июля, в 19:00 по Мск

▶️ запись останется в общем доступе по этой же ссылке в посте, вход свободный

❤️ Этот МК стал возможен благодаря Оксане Ш., Ренату Ф., Василию З.

💳 поддержать новые движухи - 5536913954129132 (Тиньк)

А я сегодня вам принесла чудесную подборку каналов девчонок-айтишниц.

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

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

Итак, встречайте!

🟣Anna Sea IT - Анна, системный аналитик, ментор и тимлид, а еще и яхтсменка. Она делает публичные мок-собесы тимлидлов, рассказывает, что делать с агрессивными коллегами и помогает не продолбать мотивацию у субординатов;

🔵Выйди и зайди в IT нормально 🗿 - Агата, руководительница проектов в IT, рассказывает о том, как строить карьеру, о PM-буднях и выкладывает очаровательные фото. Она разработала план «Как начать карьеру в IT» (подойдет для начинашек и продолжающих), говорит о гигиене созвонов, делится подборкой книг для PM и интересующихся;

🟢 Никаких багов - канал Маши, амбассадорки QA, work-life balance и бережного к себе отношения. Развенчивает различные мифы о тестировщиках, предлагает не рваться на тряпки на испытательном сроке и делится списками стажировок для новичков;

🟡 frontend от ежетты - милейший фронтенд-канал с ёжиками 🦔 Много верстки (а кроме того, vue, php, sql) , добрых мемов, образовательных технических материалов, в том числе, и для подготовки к собесам (вёрстка, javascript, инструменты). Есть списки рекомендуемых книг для новичков и продолжающих. Очень дружелюбное и джуно-ориентированное место;

🟣 Хочу в STEM - Саша, продуктовый аналитик из Авито и автор маленького славного курса на степике "Что такое программирование и почему это интересно". Она классно разбирает продуктовые кейсы, рассказывает про собесы в разные компании, а еще составила подборку учебных материалов для джунов-аналитиков;

🔵 Нетипичная айтишница - Маша перекатилась из медицины в дата-инжениринг, делится мок-собесами по DE, пишет атмосферный лайф-стайл контент и рассказывает, где в Москве можно интересно провести время;

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

Поговорим про плохие увольнения

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

Я сама писала про увольнения 2 материала на канале:

🟣3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК)
🟣Про увольнения с ГПХ-договора

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

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

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

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

Итак, флаги

🚩 вам не сообщили заранее агенду встречи, и вы не знали, что это - увольнительный созвон/встреча. Вы сразу попадаете в неравное положение: они подготовились, заранее все обсудили и продумали, а вам надо что-то судорожно соображать на месте;

🚩 на встрече больше 2 человек (вашего руководителя и HR) со стороны работодателя - противодействовать толпе оппонентов очень сложно, вас, опять же, ставят в неравное положение;

🚩 от вас требуют подписать бумаги срочно, сию секунду, прям вот "нет времени объяснять - подписывай";

🚩 от вас требуют подписать "по собственному желанию" или "по соглашению" без выплат.

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

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

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

🚩 вам говорят, что, раз вы устроены по ГПХ/ИП/СЗ (при условии того, что это - постоянная, а не проектная работа), вы должны уйти одним днем, без компенсаций и непотраченных отпускных;

Видите что-то такое? Сразу закрываем коммуникацию, прощаемся и топаем консультироваться к юристу, просим помощи в чате джунов и смотрим доклад Витали Шароватова.

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

Резюмирую

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

Лучше подписать какую-то бумагу на пару дней позже, чем подписать что-то, что вам навредит.

💳 поддержать мои дайджесты, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Дайджест полезных материалов на этом канале

📖 Самообучение и курсы

- "Золотая четверка" курсов для джунов-фронтов;
- Как писать конспекты, чтобы это было полезно;
- Про отношение к своему плохому коду (дизайну/любому другому результату);
- Вам не нужен личный ментор (почти никогда);
- Как быстро и надежно отбить себе мотивацию учиться;

✅ Поиск работы

- Основные ошибки в тестовых заданиях (и как получить бонусные баллы при проверке);
- Как подготовиться к лайвкодингу, чтобы не волноваться;
- Что такое референсы и как их получить;
- Как написать в соцсети о том, что ищешь работу, чтобы это было продуктивно;
- Как хорошо проходить собеседования;
- Почему нельзя писать сопроводительные с помощью ChatGPT;
- Рассказ о себе и достижениях по методу капусты;
- 🔥🔥🔥 Эксперимент: какая на самом деле конкуренция в IT для джунов: анализ рынка в цифрах (+ мои впечатления);
- Фото в IT-резюме: зачем и как;
- Как оформить репозиторий с тестовым заданием или пет-проектом;
- 2 вещи, которые вам надо знать про контакты в резюме на hh;
- Про неэтичные зарплатные торги;

‼️ Увольнения

- 3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК);
- Про увольнения с ГПХ-договора;
- Поговорим про плохие увольнения;

🙂 Софт-скиллы и карьера

- Мой путь в IT (внешняя ссылка);
- Личный бренд: Зачем? Почему? Как?;
- Как давать положительный фидбек, чтобы не обидеть;
- Как я впервые отсобеседовала человека и что из этого вышло;
- Как задавать вопрос по работе/учебе так, чтобы вам помогли;
- Про страх публично опозориться;
- Почему "горящие глаза" - это плохо (+ где "гореть глазами" можно);
- Деньги - мотивация;
- Про оценки и собесы;
- Стереотипы вокруг курсов для джунов;
- Менторинг на работе, личный менторинг и наставничество на курсах;

💫 Frontend/UI/UX

- Идеи пет-проектов для фронтов (верстка);
- Фронтенд-инструменты для пет-проектов;
- Про доступность интерфейсов и этику;

⛵️ Фриланс

- Стереотипы о фрилансе, плюсы и минусы;
- Как собрать портфолио для фриланса;
- Как провести ресерч конкурентов;
- Как писать сопроводы на фрилансе и не только;

🎙 Стримы и МК

- Структура HTML-страницы (часть 1, часть 2);
- Анализируем сложный HTML-макет;
- МК "Рисуем на CSS": делаем тыкву;
- МК "Рисуем на CSS": делаем мышку;
- МК “Progress Bar на HTML/CSS/JS”;

🎵 Подкасты (аудио/видео)

- Frontend Weekend (внешняя ссылка);
- "Поговорим о собесах на фронта (и не только)";
- Сходила на подкаст "Два стула"!;

💬 Митапы

- Митап #1: анимация в вебе и мок-собес джуна-фронта;
- Митап #2: поиск первой темы для доклада и концептуальный подход к подготовке к собесам;
- Митап #3: основные рекрутерские боли и архитектура для джунов;
- Митап #4: мок-собесы джунов с рекрутерами и концепт стандартных задач фронта;
- Митап #5: о репутации в индустрии и том, как оценивать качество своей работы;
- Митап #6: карьерный путь до сеньора и разбор стандартной задачи фронта на примере;
- Митап #7: карьерный путь в JS-разработке, React-хуки и как разбирать сложный код на компоненты;
- Митап #8: мок-собес Java-джуна;
- Митап #9: мок-собес джуна-фронта;
- Митап #10: про архитектуру для самых маленьких и о том, как сделать пет-проект и не задолбаться;
- Митап #11: о том, кто такие Product Owner, и мок-собес джуна-фронта;
- Митап #12: мок-собес джуна-AQA (плюс фидбек собеседующему от тимлида);
- Митап #13: мониторинг веб-приложений и паттерны взаимодействия React-компонентов;
- Митап #14: мок-собес джуна .Net/C#;
- Митап #15: рассказ джуна об устройстве на первую работу, миддл + о карьерном росте и стрим с лидом QA/AQA о резюме, хардах и поиске работы;
- Митап #16: Q&A сессия с эйчар, сторителлинг для начинающих авторов контента и помощь начинающим тимлидам;
- Митап #17: демонстрация внутрянки headHunter со стороны эйчара и практикум по canvas;
- Митап #18: взаимодействие с QA и рассказ о синдроме самозванца;
- Митап #19: cookie-аутентификация и мок-собес джуна PHP;
- Митап #20: IaC инструменты: HashiCorp Terraform и круглый стол про достигаторство;
- Митап #21: как варить классный кофе и мок-собес джуна-фронта;
- Митап #22: структурная типизация и RxJS;

Конспект: "Как дизайну и разработке найти общий язык" (ч.1)

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Это второй выпуск рубрики "Конспект" (первый - тут), в которой я буду публиковать сюда интересные материалы с краткой выжимкой.

Итак, сегодня принесла вам статью "Отрицание, гнев, торг: как дизайну и разработке найти общий язык".

❗️Статья очень большая, поэтому постов-выжимок будет два.

Почему я вообще принесла эту статью

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

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

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

Теперь выжимка (ч.1)

🟣основные боли разрабов при взаимодействии с дизайнерами:

🔘 неполные и неконсистентные макеты (не хватает экранов/состояний элементов/сообщений об ошибке или успехе/лоадеров);
🔘 вместо компонентов из дизайн-системы (если она есть), просят кастомные компоненты без объяснения причин;
🔘 дизайнеры не понимают ограничений разработки и рисуют "красивое";

🔵 основные боли дизайнеров при взаимодействии с разрабами:

🔘 реализуют макеты с очевидными багами, которые невозможно не заметить;
🔘 разрабы не вникают в макеты на этапе концепта (если им показывают) и заранее не указывают на ограничения;
🔘отказываются что-то делать, потому что это "слишком сложно/невозможно" (а потом оказывается, что и возможно, и не сложно);

❤️ что нужно улучшить, чтобы порадовать всех #1: делать больше совместных грумингов, чтобы разработка могла посмотреть на макеты несколько раз до того, как их полностью согласуют с продактами и C-lvl. Это уменьшит количество сложных ситуаций и переделок;

❤️ что нужно улучшить, чтобы порадовать всех #2: делать дизайн-ревью готового фронтенда заранее, а не за день до релиза, чтобы ревью и починка багов не делались с горящей жопой и с риском не выкатить релиз;

🟢 что отдельно можно улучшить, чтобы порадовать разрабов:

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

🟡 что отдельно можно улучшить, чтобы порадовать дизайнеров:

🔘 помочь дизайнерам повышать упомянутую "грамотность": организовать локальные внутренние ликбезы/митапы, делиться обучающими материалами;
🔘 разрабам - поучиться пользоваться фигмой, посмотреть пару туториалов (или почитать эту статью);

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

Про перфекционизм

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

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

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

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

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

🟢 более того, очень хорошее в моменте решение может отстрелить тебе жопу через несколько месяцев. А если в этом самом моменте начать защищаться от всех "а что, если", нагородишь таких переусложнений, что потом не разгребет никто;

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

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

Альтернатива перфекционизму - подход "достаточно хорошо"

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

Что такое "достаточно хорошо" на примере. Представим, что мы - фронтенд-разраб, и у нас задача - сделать модальное окошко. "Достаточно хорошо" будет, если:

🔘 мы соблюли визуальные требования - модалка с начинкой соответствуют дизайну;

🔘 мы соблюли функциональные требования - модалка открывается по клику на нужную кнопку, закрывается, показывает верную начинку, начинка тоже работает;

🔘 мы учли типовые продуктовые корнер-кейсы - поддержку разных браузеров (если надо), поддержку разных типов устройств (если надо), ситуацию, если "начинка" не прогрузилась/ее слишком много, например, 100 абзацев текста (это называется проверкой на переполнение контентом);

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

🔘 на всякий случай, перепроверили свою работу перед сдачей;

Все, вы великолепны!

А если я вижу, как улучшать и улучшать дальше

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

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

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

Помните главное. Лучше сделать что-то, пусть не идеально, и разобрать свои ошибки по итогу, чем сделать идеальное "ничего"

Как критиковать, чтобы это было конструктивно

Дисклеймер. Я не буду в этом посте рассказывать про сэндвич-концепт ("похвали" - "поругай" - похвали"), сосредоточусь на другом.

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

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

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

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

Хорошо, а как на практике?

Перед тем, как практиковаться, надо честно ответить себе на вопрос: зачем вы человека вообще критикуете? Вы хотите ему добра или покрасоваться? Вы хотите помочь ему вырасти или пнуть, потому что а чо он такой неидеальный? Если ответы вторые - положите человека на место и не практикуйтесь.

Если же первые, вот вам основной фактор, делающий критику полезной: проверять все тезисы своего фидбека на "это поможет вырасти?".

Что вырасти не помогает

🟣 любые переходы на личности (критика человека, а не идеи/результата). Приведу примеры из фидбеков на реальных мок-собесов с ютуба: от "Ну для человека без формального образования достаточно хорошо" до "Когда говорю с вами, ощущение, что общаюсь с ChatGpt" (речь не про то, что кандидат списывает, а про манеру разговора);

🟣видимые обесценивания. Тоже из реального мока: "вообще, эта задача должна быть решена за 2 минуты, и то, если ночь не спать". Задача уже не решена за это время, хотя собеседуемый выложился на полную. От того, что ткнешь человека в его несовершенства таким образом, легче никому не будет;

🟣отсутствие конкретики. "Не, ну плохо сделано" - не конкретика. Совершенно неясно, что с этим замечательным фактом делать.

Что вырасти помогает

Связка "что неправильно -> почему это неправильно -> как правильно -> какие дополнительные шаги сделать, чтобы улучшить (опционально)".

У критикуемого по каждому пункту должно остаться на руках 3 вещи: что именно не так, почему оно не так и как сделать, чтобы было "так".

Например: "Решение задачи, на мой взгляд, неоптимально, потому что <... список причин ... >. Чтобы было оптимально, нужен подход такой-то и потому-то. Почитай Васю Пупкина, он в своих статьях отлично это раскрывает, можно еще добить книгой Пупки Васина, если хочется".

Ничего лишнего не нужно. Если вы предпочитаете сухой сдержанный стиль, этого хватит. Уровень детализации ответа может варьироваться, в зависимости от ситуации.

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

Важно: следите за состоянием критикуемого. Если он уже сидит с совсем сложным лицом, возможно, пора остановиться и продолжить позже.

Когда давать критику, чтобы было конструктивно

1️⃣ когда вас о ней просят (просьба должны быть прямой. Если человек что-то выложил в интернет, это не запрос на критику);

2️⃣ когда это подразумевает контекст (например, вы ревьюите коллегу или проводите мок-собес);

Если меня не просят, а хочется покритиковать?

Говорим: "Мне кажется, я могу помочь улучшить твой результат. Хочешь?". Если ответ положительный - отлично, критикуем, если отрицательный - тоже хорошо, что вы не потратили зря время.

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

И раз уж заговорили о тимлидах

Я тут смотрю доклад Саши Кирсанова на тему того, должен тимлид кодить или нет. И это тот случай, когда остро не согласна с примерно 95% тезисов автора.

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

Если вкратце, основной пойнт Саши: "тимлид должен быть самым сильным техническим специалистом на проекте, должен много и плотно кодить, только тогда он будет авторитетом".

Моя же позиция: тимлид не должен кодить, отвалите от тимлида.

Почему так думаю:

1️⃣ навыки тимлида не падают людям с неба просто за то, что им дали должность. Это здоровенная отдельная область знаний, как фронтенд или дизайн.

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

2️⃣ из такой логики, мы консервируем уровень команды на уровне тимлида. Если тимлид - лучший, и весь его авторитет строится на этом, он уже не сможет нанять кого-то компетентнее себя, иначе ему придется сложить "лычку" на полку.

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

3️⃣ далее, у тимлида есть, вообще говоря, круг своих обязанностей.

Работа с командой: регулярные 1-1, организация процессов (не путать с миллионом созвонов), организация роста сотрудников, решение всяких околомотивационных вопросов.

Внешние активности: на архсинк сходить, найм организовать, в стратсессиях участвовать, перфоманс-ревью всем устроить, бюджет на отдел выбить, от "надо сделать срочно" команду прикрыть;

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

Я написала это в тви и получила стопку типичных возражений:

✖️а кто тогда будет охренительно кодить и контролировать качество?

Сеньоры, технические грейды выше сеньора (сеньор+, стафф), архитектурный комитет, техлиды.

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

И не надо путать тимлида и техлида, это разные карьерные треки.

✖️ а как тогда зарабатывать авторитет?

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

✖️а чем это отличается от проджект менеджера?

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

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

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

❗️Анонс моего благотворительного ивента для Junior Frontend и верстальщиков (с опытом тоже можно)

🛑🛑🛑 UPD. Набор временно приостановлен (кто уже успел написать - тем отвечу)

Делаю небольшой благотворительный онлайн ивент, чтобы помочь джунам получить проект в портфолио и собрать немного денег в пользу НКО "Ночлежка" (или любого зарубежного аккредитованного НКО, если вы не в РФ).

📘 Что будет

🔸 мы соберемся 4-5 командами по 4 человека (можно заявиться и одиночкой, и несколькими людьми: команды я соберу);

🔸 после аппрува участия участник вносит 800 рублей сразу в "Ночлежку"/зарубежное НКО (❌мне ничего переводить не надо) и присылает чек;

🔸 я присылаю командам красивый макет средней сложности в Figma;

🔸 мы тратим выходные в околохакатанном формате и реализуем макеты в HTML/CSS/JS (без фреймворков);

🔸 я делаю публичное код-ревью всем командам;

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

🗓 Когда будет

Ивент будет длиться все выходные 28-29 сентября, с 10:00 утра субботы до 17:00 воскресенья (потом - смотр работ и ревью)

⭐️ Кто может участвовать

Все, у кого есть базовые или выше знания HTML/CSS/JS (JS - на уровне "подключить готовую библиотечку"). Фреймворков не будет.

Допускаю и ребят без опыта вообще, и опытных верстальщиков.

✉️ Как участвовать

🔸написать мне в личку (@natti_davydova) письмо, начать его с "хочу участвовать в ивенте", обязательно рассказать там, какой у вас опыт (чтобы я смогла сделать сбалансированные команды);

🔸заявляться можно и по одиночке, и сразу несколькими людьми;

🔸после аппрува вашего участия, вы вносите 800 рублей в НКО "Ночлежка" (или $10 в любое аккредитованное НКО, если вы не в РФ) и присылаете мне чек;

🔸 до 22 сентября включительно будут сформированы команды, и вы успеете познакомиться, подготовить репозиторий для работы и договориться по стеку (будут ли препроцессоры, tailwind итд);

🔸28 сентября получите инструкции, и начнем;

🙁 А если у нас ничего не получится?

🔸 по организационным вопросам я буду поддерживать вас в течение всего ивента;

🔸 даже если у вас не получится закончить макет, вы получите код-ревью и понимание, куда самостоятельно двигаться дальше;

В любом случае, вы унесете с собой новый опыт, красивый уникальный проект и получите возможность поработать в команде (либо поменторить новичков и возглавить команду);

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

В этот раз - не реклама, а исключительно по любви. Хочу рассказать про блог моей чудесной подруги Леры Зелёной - "Рефлексант".

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

Я нашла ее блог несколько лет назад и после пары месяцев запойного чтения очень захотела с Лерой подружиться: настолько славный она человек, настолько ее мысли и ценности со мной резонируют. И вышло же! Я горжусь тем, что дружу с ней ❤️

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

О чем вам может быть интересно почитать тут

🟣о том, как преодолевать жестокое и грубое отношение к себе, привычное с детства, к чему приводит абьюз себя и постоянное тыканье палочкой, и о том, как гарантированно выгореть;

🔵 о том, как сложно, но важно принимать себя внешне и внутренне в культурной парадигме, призывающей постоянно искать в себе недостатки, о ценности самопознания и о том, как не загнобить себя, когда неминуемо сравниваешь себя с другими;

🟢 о том, как учиться отстаивать свои границы, когда ты мяконькая булочка, о том, что все мы иногда - те еще жопники, и о том, что можно (а порой, и нужно) двигаться вперед без мотивации и вдохновения, просто делать шажок за шажком;

🟡 о том, как учиться отдыхать, если привык бесконечно гнаться хомяком в колесе, о том, что хотеть поныть - нормальная и здоровая история, и как сохранять в себе вкус к жизни;

🟣 о психпросвете в общем: о том, что у депрессии нет лица, и люди с диагностированной депрессией не всегда лежат лицом в стену, о "налоге на СДВГ и о том, что делать, когда тревога сжирает изнутри;

🔜 Подписывайтесь на Лерин "Рефлексант", будем вместе удерживать кукуху и справляться с жизненными челленджами