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

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

Если покупали у нас курсы последние полтора года — найдёте всё в lms.tough-dev.school. Код, как и все проекты школы, — в нашем гитхабе.

Технологии: vue3, pinia, vitest, playwright.

Разработчик: Тимур Брачков.

Одна из привычек, которая появилась у меня после 30 лет — не покупать ночные рейсы.

Идея ночных рейсов звучит довольно привлекательно: ты экономишь деньги, вылетая в 03:45, а аэропорт получает чуть более ровную загрузку. Но это же глупость! Во-первых, время — я, как дисциплинированный пассажир, приезжаю в аэропорт за два часа до вылета. Днём я трачу свободное время в аэропорте на работу — просто открываю ноутбук и делаю накопившиеся дела. В час ночи, я так сделать, увы, не могу — голова не работает.

Во-вторых — цель поездки. После ночного перелёта всё, что хочет нормальный человек — это отоспаться. Получается, что если я лечу в отпуск, то отпуск должен быть на один день больше. Если лечу по делам — дела занимают на один «отсыпной» день больше. А мог бы потратить этот день на что-нибудь полезное — хорошо отдохнуть и поработать.

Вряд ли разница в стоимости билетов (пусть она будет хоть 30%) стоит больше, чем деньги, которые я могу заработать за счёт того, что не перехожу в состояние сонной коровы.

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

С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за день вместо недели или за 300 строк вместо 30 000.

Если планируете развиваться в кого-то кроме синьёра, годами не вылезающего из своего, постепенно превращающегося в легаси, проекта, такой оверижиниринг для вас — стратегическая ошибка. Смотрите сами, технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.

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

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

Грубо говоря — плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.

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

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

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

Цели бывает три:

• Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
• Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
• Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».

Если ваше сообщение не задаёт вопрос, не спрашивает разрешения и ни о чём не просит — скорее всего это пустое сообщение, которое лучше не писать.