В твиттере рассказывают прохладные истории о том, что свежая модель AI за 1 запрос сделала проект с невероятным уровнем детализации и качества. (Код правда не показывают, это корпоративный секрет)
У меня AI не смог сделать консистентные и работоспособные правки в 10 небольших CSS файлах, при условии того, что я дал четкую инструкцию и пример.
CSS файлах. Не Ruby, JavaScript или c++.
В CSS!
Не в 100500 файлах среднего проекта. В 10 файлах простого лендинга.
Разговоры о замене программистов на AI предлагаю считать закрытыми.
Прошло 10 лет с момента моего участия в одном крупном проекте.
Вдруг мне пишет разработчик.
Илья, добрый день! Вот посмотрите что вы наделали 10 лет назад! В ваших GIT сообщениях только "WIP". 1000 коммитов, тонны изменений и ничего не понятно!
В этот момент я испытал невероятную гордость за себя и сердце мое забилось сильнее!
10+ лет назад меня пригласили в тот проект как экстренного антикризисноготех. менеджера.
Проект умирал. Деньги кончились. Инвестор сказал, что через месяц закроет проект если не будет результата.
Тимлид убежал, технари заигрались в технологии, которых не знали. Проект застыл на 4 месяца.
У меня был релевантный опыт — я знал что делать.
3 недели я только спал и работал. Надо было показать прогресс.
Через 3 недели и сотни WIP коммитов проект заработал.
Клиент согласился продолжать финансирование.
Команду не распустили. Компания осталась с ключевым клиентом.
Когда программист делает точку сохранения в своей работе, он может указать сообщение для этой точки сохранения.
В идеале, это сообщение должно быть информативно и рассказывать что ты сделал на этом шаге.
На практике, в день ты делаешь примерно 100500 сохранений и тебе точно есть о чем еще подумать, кроме задания красивых и информативных сообщений коммитов, которые будут читать примерно НИКОГДА.
git commit -m WIP 😅
(WIP = Work In Progress)
Примерно так это работает в жизни.
Раз в день, или перед оформлением PR все "грязные коммиты" все равно объединяются в один с красивым именем и названием: "TASK-165 feat: Add new Model", и что там было до этого — никто и никогда не видит и не знает.
Давать каждому отдельному коммиту имя и описание — это просто неразумная трата времени.
Да, бывает 1% ситуаций, когда работу можно разделить на отдельные коммиты с подробным описанием, но в большинстве случаев это просто не требуется.
Чуть больше 10 лет назад случилось поворотное событие. Я устроился в компанию, в которой все общались только на английском.
Не смотря на то, что я учил английский с 7 класса, мои разговорные навыки были примерно на уровне 0.
Мне не хватало какой-то детали. Какого-то ощущения или схемы, чтоли.
У меня был только месяц, чтобы срочно восполнить пробел.
Я пошел в первую школу у моего дома в Питере. Без особых надежд.
Там я познакомился с Антоном.
За неделю он выяснил, чего мне не хватает и изобрел под меня «волшебную» схему. Еще неделю я ее корректировал под свое понимание и выяснение деталей работы с ней.
На третью неделю я впервые в жизни свободно рассказал на дейли что я делал, делаю и планирую делать по задачам. И понял все, что говорил мои коллеги из разных стран.
В те недели случилось чудо. Антон натурально изменил мою жизнь в те 3 недели.
Сегодня Антон был в Стамбуле и мы отобедали с видом на Босфор.
Благодарен ему так сильно, как только возможно. ❤️
И вот клиент говорит: "Раньше над этим проектом работал один наш хороший разработчик. (Сейчас он на другом проекте). Там все уже готово для нового функционала, надо только переиспользовать готовые решения. Это не должно быть сложно."
Идешь изучать проект и понимаешь следующее:
1️⃣ Клиент даже близко не понимает, что было сделано и как оно может пересекаться с новым функционалом.
У него просто ощущение того, что раньше работало и были разговоры о переиспользуемых компонентах.
2️⃣ "Готовые компоненты" были сделаны в спешке несколько лет назад. Спагетти код, устаревшие подходы и deprecated решения образуют плотный клубок проблем, живут в проекте и вообще не помогают.
3️⃣ Инфраструктура не подготовлена. Для нового функционала на каждом шагу нужно принимать техническое решение и изобретать способ "поженить" желаемую картинку с уже существующей.
Попробуй объяснить заказчику почему его ощущения о быстром результате физически невозможны.
Коммуникационные задачи ВСЕГДА сложнее технических.
Сегодня свободный день. Отправились с семьей на прогулку по Босфору. Я впервые увидел танкер так близко. Я был Оооооочень удивлен. Ого, какой он огромный!
Да и вообще красиво вокруг. Стамбул. Лето. Босфор. Чай. ❤️
Кажется, что иногда вместо очередного проекта в духе «в Basecamp это работает» — лучше было бы просто сделать сам Rails сильнее. Например, в плане DX, документации или работы с фронтендом.
