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

Ну правда, зачем? Задача тимлида – сделать всё, чтобы команда работала эффективно. Зачем быть искренним и эмпатичным, если люди – это ресурс, и вы умеете ими управлять?

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

С этого и начну. 

Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!»

Очень смешно, но давайте я все-таки объясню.

Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.

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

Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто "Frontend-разработчик", а более развернуто - "Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик". Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы.

Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низкого уровня, к наивысшему и без привязки к инструментам/библиотекам)

— Что вы скажете, если я попрошу вас разработать сервис, который обрабатывает тысячи запросов в секунду с минимальной задержкой?

— Хм… Я скажу, что у вас в компании возникла такая проблема. Но у вас нет идей и вы обсуждаете её на собеседованиях с кандидатами :)

В последние годы области проектирования и дизайна начали сближаться с разработкой. Проектирование соприкасается с дизайном, а дизайн — с версткой. В этом помогают, к примеру, дизайн-системы, storybook’и, созданные по правилам разработки интерфейсов, а также современные инструменты: Figma, Sketch, InVision Studio и другие.

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

• 12 m уникальных пользователей в месяц;
• Версии для всех современных платформ (Web, iOS, Android);
• Достаточно нагруженное приложение – около 800 тысяч подключений онлайн по WebSocket (основной протокол общения с пользователями).

• Я придумал идею
• Я начал работать за N месяцев до моего сооснователя
• Мы так договорились
• Мой сооснователь получал зарплату за N месяцев, а я — нет
• Я начал работать полный рабочий день за N месяцев до моего сооснователя
• Я старше/опытнее своего сооснователя
• Я привлек своего сооснователя после того, как собрал N тысяч долларов
• Я привлек своего сооснователя после запуска своего MVP
• Нам нужен кто-то для тай-брейка в случае спора основателей

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

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

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

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

Потребление информации снижает творческий потенциал — мозгу нужно отдыхать

«Чтобы по-настоящему дорожить вещами, которые для вас важны, вы должны cначала избавиться от тех, которые уже пережили свое предназначение. Выбрасывать то, что вам больше не нужно, — это не расточительность и не постыдный поступок».

В начале 2020 года специалисты сервиса по поиску работы «Работа.ру» провели социальный опрос и выяснили, что в следующие 12 месяцев 74% россиян хотят заняться вопросом нового трудоустройства. 53% респондентов рассказали, что недовольны текущим уровнем заработной платы. Но почему в итоге ничего не происходит?

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

… или самые частые ошибки фаундеров.

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

За это время мне удалось оценить сотни pitch decks. Удалось поработать со стартапами, чтобы улучшить идеи, реализовать и запустить их продукты.

Здесь собраны самые частые ошибки, которые я видел за последние 10 лет. Все они основаны либо на личном опыте, либо на опыте фаундеров, с кем я общался. Часть ошибок типична только для русскоговорящих фаундеров, но большинство из них — универсальны.

Итак, как же фаундеры стреляют себе в ногу?

Всем привет! 

Меня зовут Святослав. Я лидирую разработку сервисов оформления ипотеки в компании Домклик. Не так давно наша компания взяла курс на внедрение философии Progressive Web Application в наших клиентских сервисах.

Одним из важных аспектов PWA является использование технологии Service Worker API. Однако технология не так проста, как кажется на первый взгляд. Для эффективного использования нужно пройти тернистый путь из квестов, связанных с особенностями жизненного цикла воркеров, неполной поддержкой браузерами, проблемами с политикой кэширования и попутно встречающимися сайд-эффектами (кэширование устаревшего контента, сломанные ссылки и другое).

Workbox - это набор инструментов, предоставляющих высокоуровневый API для конфигурации и работы с такими браузерными технологиями как Service Worker API и Cache Storage API. Инструментарий состоит из набора изолированных модулей, которые помогут сделать ваше приложение "offline-ready".