Дима печатает…
144 subscribers
10 photos
1 video
32 links
Пишу о жизни и работе во фронтенде
bezugly.ru@sexy_dima
Download Telegram
to view and join the conversation
Сделать ≠ делать
3 месяца назад я начал руководить командой фронтенда. Думал, что тимлид — это где я в роли бати, к которому приходят за фронтенд-мудростью:
— Бать, а как тут лучше архитектуру сделать?
— Бать, у меня не получается интерфейс сделать, помоги.
— Бать, я тут написал модуль, который ходит на сервер, поревьюй плиз.

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

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

То, о чем я буду сейчас говорить, хорошо раскрыто в книге «Управление проектами, людьми и собой». Мне близка философия Бюро Горбунова, так что горячо рекомендую.

Итак, фундаментальная вещь для разработчика/дизайнера номер один — сделать ≠ делать.

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

Если разработчик говорит в понедельник, что сделает фичу к четвегу, то это значит, что в четверг фича будет на проде. Очевидно, скажете вы, но иногда четверг бывает результатом делания, а не сделывания:
— Фича готова, но пулл-реквест на код-ревью, чет они долго
— Все ок, но фича тестируется, я ни при чем
— Я все сделал, но продакт просит поправить кое-что перед выкаткой, прикинь

Если принять философию сделать ≠ делать, то план изменится:
1. В понедельник делаю фичу с горящими глазами
2. Во вторник утверждаю у продакта
3. В среду тестирую и прохожу код-ревью
4. В четверг качу на пользователей и слежу, что ничего не отломалось

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

Из принципа сделать ≠ делать вытекает другая фундаментальная вещь — ответственность на разработчике.

Докатить до прода — ответственность разработчика, поэтому все задержки на код-ревью, тестирование, утверждение у продакта — ответственность разработчика.

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

В книге крутая аналогия про сделать ≠ делать:

> Представьте студента, который готовит дипломную работу. Мало написать сам диплом, его ещё должен утвердить научный руководитель. И вот попался студенту нерадивый научный руководитель: постоянно динамит несчастного студента, на встречи не приходит, советом не помогает. Подходит срок сдачи, а диплом не утверждён.

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

Сделать — это фича на проде к обещанному сроку. Все остальное не имеет значения.
Как быстро запускать проекты

Допустим, мы верстаем лендинги в компании. В понедельник нам пишет менеджер:

— Привет! Дизайнер нарисовал лендинг с акцией, заверстай, пожалуйста. За сколько дней сделаешь?
— Так, я сделаю за 4 дня, плюс день на исправление замечаний, так что через неделю запустим.
— Эээ, чел, тут такое дело… Нам надо завтра запустить.
— (начинается ситуация)

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

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

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

Кучу лет назад Артемий Лебедев сформулировал метод прогрессивного джипега, который гласит, что «в любую секунду любой проект готов на 100%, хотя проработанность может быть и на 4%». Главный вопрос: как сделать лендинг на 100%, проработав его на 4%.

Что, если вместо верстки добавить на сайт картинку с макетом? Ну вот просто <img src="/images/maket.jpg" />. Проект будет запущен, но не проработан. Конечно, любому уважающему себя фронтендеру станет плохо:

— А что, если пользователь захочет скопировать текст?
— А что, если медленный интернет? Чел будет ждать картинку всю жизнь!
— Да о чем мы вообще говорим, так никто не делает, это кощунство, вы чего!

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

Поэтому первое, что делаем — спрашиваем у менеджера, откуда такие сроки, и зачем вообще мы это делаем.

Ответ на вопрос «зачем это надо» даст вам понимание до какой степени всратости фантазировать.

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

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

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

Объясняем решение менеджеру и если он ок, то иди наливай, а я пока запущу проект.

Если менеджеру не ок, то разговариваем дальше:

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

Короче, алгоритм такой:
0. Предложить решение с уменьшением проработки.
1. Если менеджер ок, идем работать.
2. Если не ок, то спросить почему. В итоге получаем список аргументов от менеджера.
3. Обсудить с менеджером каждый аргумент: делать или забить. Если без этого аргумента не решается задача продукта, то делаем, иначе — забиваем. Конечно, сделать хочется все, но важно отталкиваться именно от решения задачи, если хотим запуск быстрее. В итоге получаем список того, что надо сделать.
4. Подумать над списком, придумать решения с уменьшением проработки, повторить цикл.
В нашем случае анимацию откладываем на потом, потому что задача продукта — проинформировать клиентов об акции и собрать заявки — анимация тут не поможет. А форму надо сделать.

Теперь давайте тоже самое, но с формой сбора заявок. Сначала определяемся, до какого предела можно фантазировать с проработкой:

— Готов ли бекенд?
— Если бекенда нет, то где хранить заявки?
— Есть ли похожие формы на нашем сайте?

В общем, собираем инфу, зачем это нужно, а дальше решения пойдут сами:

— Бекенда нет, отстой. Надо самому писать, я к завтра не успею, тем более, что похожих решений нет.
— Слушай, если данные необязательно хранить у нас, то может сделаем гугл форму и вставим на сайт?
— Кстати, а как мы общаемся с клиентами? Хм, через телеграм… Ёмаё, так давай я ссылку на телеграм бахну!

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

Конечно, есть опасность: при таком подходе легко скатиться в говно. Особенно, если принимаешь такие решения в одиночку без бизнеса.

Представьте, если бы Яндекс запустил свой Google Docs, но по факту вместо яндексового редактора запускался бы тот же гугл, только через айфрейм. Задача, вроде, решается, пользователь создает доку на сайте Яндекса, разработчик быстрее запустил продукт, но загубил репутацию команды.

На самом деле тут задача не решена, потому что «не похерить репутацию запуском» — тоже задача, которую надо учитывать при уменьшении проработки. Хороший менеджер знает эти задачи, поэтому надо с ним советоваться и держать в курсе своих решений.

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

Короче. Если бизнес просит вас быстрее запуститься, то не бойтесь предлагать всратые решения — если задача решается, то можно. Мыслите запусками.
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Удаленка vs работа в офисе

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

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

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

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

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

В общем, моя формула — офис для личного общения и креатива, дом для тихой сконцентрированной работы.
This media is not supported in your browser
VIEW IN TELEGRAM
Ну шо

Мы вместе с командой KARPOVꓸCOURSES запилили курс по фронтенду.

Вообще, я хотел переосмыслить свой курс по реакту, который записал на Udemy. Накидал план, пришел к Толе Карпову как к старшему брату, мол посоветуй, глянь план, скажи мысли.

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

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

Короче говоря, мы рассказываем про реакт, тайпскрипт, сервера, http, браузер, оптимизации, мониторинг, тестирование, быстрые запуски. На работе мы не только пишем фронт, но общаемся с девопсами и бекендерами. Надо быть на уровне, понимать, о чем речь, поэтому на курсе подробно говорим о серверах, CI/CD, протоколы, сети. Спасибо Антону 🙂

Недавно с Артуром проводили трансляцию, где рассказывали как писать на JSX без сборщика. Заходите посмотреть наш трёп.
https://www.youtube.com/watch?v=4DGMjzPuaww

Ну и пишите, если хотите на курс — договорюсь о скидке)
This media is not supported in your browser
VIEW IN TELEGRAM
Недавно потрепались с ребятами о собеседованиях на фронтендера. Этот подкаст больше для джунов, но по ходу разговора мы делились недавними историями из жизни, много ржали, рассказывали о своем опыте.

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

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

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

Поэтому я устраиваю марафоны из 6–10 собеседований до главного собеседования в компанию мечты. Что это дает:

1. Понимаешь, какие вопросы задают.

2. Если где-то не смог ответить, есть шанс нагуглить вопрос дома.

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

Такое упражнение кратно повышает шансы попасть в компанию мечты.

Больше лайфхаков и историй в полной версии нашего подкаста на ютубе:
youtube.com/watch?v=C7b4aShcLKA
This media is not supported in your browser
VIEW IN TELEGRAM
preload prefetch preconnect prerender

Если вы хотели разобраться с предзагрузкой данных через preload/prefetch/preconnect/prerender, посмотрите 2 видео Антона — он очень четко и по полочкам раскладывает эту тему на практических примерах. Лайкосик 👍

youtu.be/uulGYttwldo
youtu.be/YjPVlOjJ3CQ
Что хочет рынок от фронтендера миддла сегодня

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

Много ржача, наблюдений, ответов на вопросы и рассказ про stateofjs.

Рекомендую, чтобы скоротать вечерок
youtu.be/4MWVWE27GxY
This media is not supported in your browser
VIEW IN TELEGRAM
Когда времени на раскачку нет

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

1. Назначить встречу с человеком. Когда я пытался заниматься спортом самостоятельно, меня хватало максимум на месяц. Но когда появился тренер, с которым я встречаюсь 3 раза в неделю в 8:30, то слиться уже тяжело: отменять неудобно, придумывать отмазки — по-детски, подводить не хочется, казаться кидалой тоже. С работой применяю тот же принцип — назначаю встречу и не сливаюсь.

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

3. Еще бывает сопротивление первого шага — это когда сложно начать. Причем я знаю, что если начну, то дело пойдёт, вот только мозг сопротивляется. Тогда я его обманываю и настраиваю себя на поработать 15 минут без результата, типа просто что-то поделаю по этой задаче. Не получится — не буду продолжать. Но по факту обычно сажусь, начинаю делать что-то и сопротивление пробивается.

Итого, 3 способа борьбы:
1. Назначить встречу с человеком.
2. Разбить задачу на пошаговый план.
3. Договориться с собой поработать 15 минут.

Кстати, Ася Казанцева круто объясняет отчего берётся прокрастинация и как ее пробить.

youtu.be/FPYCQpfrQSw
This media is not supported in your browser
VIEW IN TELEGRAM
А еще мне тут сказали, что мой канал не ищется в поиске из-за слова sexy.

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

Давайте решать! Ставь сердечко, чтобы оставить как было, либо огонек, чтобы убрать sexy.
Как работают сорсмапы

Вчера собрались с Антоном, где он рассказал, как работают сорсмапы. Тема про которую знаешь, но при погружении в детали начинаешь плыть 😅

Как они формируются, чем отличается eval, eval-cheap-source-map, eval-source-map, source-map, hidden-source-map и т.д. Ну и в конце рекомендации, что бы мы где использовали.

Все тут с 2:15, велкоме
This media is not supported in your browser
VIEW IN TELEGRAM
Особенности условного рендеринга в React

Ревьюю студентов на курсах и часто натыкаюсь на общую проблему с условным рендерингом. Рассказываю.

Вот пишут такой реакт-компонент (для простоты убрал лишнее)

const List: FC<{ id: number }> = ({ id }) => (
  <ul>
    <li><a href="/">домой</a></li>

    {id && (
      <li><a href="/somewhere">куда-то</a></li>
    )}
  </ul>
);

Что здесь: передаем пропом число id, и если оно есть, то рендерим элемент списка.

Вроде бы все хорошо, но на самом деле опасно. Если id будет равен нулю, то компонент не отрендерится. Зато отрендерится 0.

То есть при id === 0 на странице получится такая разметка

<ul>
  <li><a href="/">домой</a></li>
  0
</ul>

Почему так
Первый момент, что если при логическом операторе И (&&) один из операторов ложен, то он и вернется. То есть в нашем случае вернулся 0, т.к. число ноль при логическом преобразовании ложно.


0 && 1 // 0
2 && 3 // 3
1 && 0 && 2 // 0


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

https://codesandbox.io/s/tender-colden-wfgtz?file=/src/App.js

Другое дело, если бы вернулся не 0, а false — его реакт не отрендерит.

https://codesandbox.io/s/sad-babbage-04ir9?file=/src/App.js

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

То есть в нашем случае лучше будет

const List: FC<{ id: number }> = ({ id }) => (
  <ul>
    <li><a href="/">домой</a></li>

    {Boolean(id) && (
      <li><a href="/somewhere">куда-то</a></li>
    )}
  </ul>
);

Доп. материалы на почитать:
https://learn.javascript.ru/type-conversions
https://learn.javascript.ru/logical-operators