Важнее всего люди 🤝
В управлении любой командой для меня важнее всего люди. Когда у меня есть возможность, я всегда встану на сторону разработчика и помогу разобраться в конфликте или принять лучшее техническое решение, согласую внеплановые выходные - особенно, если в жизни у человека непростой период.
Мы все любим и ценим уважительное, заинтересованное отношение к себе. А современный менеджер - это в последнюю очередь начальник, который всегда прав. Более того, именно у членов своей команды я стараюсь научиться чему-то, чего ещё не знаю. Это особенно полезно, когда приходишь руководить в уже существующий проект, где любой член коллектива по определению знает больше тебя. И ребятам приятно, что к ним относятся как к экспертам и прислушиваются к их мнению.
Учиться у разработчиков лучше всего через парное программирование - когда вы вдвоём решаете одну задачу. Причём не важно, знаю ли я, как её решать. Даже если знаю, всегда можно подсмотреть какие-то фишки в работе с инструментами или библиотеками, задать вопросы про архитектуру системы или реализацию определённой фичи.
Регулярное парное программирование полезно обоим: я получаю знания об устройстве системы без необходимости разбираться в ней месяцами (не всегда есть возможность и необходимость), а разработчик - как минимум, "резиновую уточку", а часто и вторую светлую голову. Плюс это отличный способ поддерживать тесный контакт, быть в курсе успехов и затыков каждого члена команды.
Конечно, такое отношение к людям должно соответствовать ценностям компании, в которой я работаю. Если разработка ПО - основной бизнес, то люди - основной капитал, который холят и лелеят. А если у компании ценности другие, то нам точно не по пути: моя позиция либо выйдет боком мне самому, когда я не смогу выполнить взятые обязательства, либо команда будет в плохом смысле оторвана от действительности. Рано или поздно несоответствие моей позиции и вышестоящего руководства, если оно есть, станет очевидным, и вся с любовью выстроенная культура рассыплется как карточный домик.
Доверительное общение и хороший климат в команде незаменимы и для развития проекта или в кризисных ситуациях: когда нужно делегировать дополнительную отвественность, попросить о переработках (разумеется, оплачиваемых или компенсируемых выходными - помним про правильные ценности компании) или срочно починить что-то.
В общем, одни плюсы для всех. А какие отношения у вас с руководителем и/или подчинёнными?
В управлении любой командой для меня важнее всего люди. Когда у меня есть возможность, я всегда встану на сторону разработчика и помогу разобраться в конфликте или принять лучшее техническое решение, согласую внеплановые выходные - особенно, если в жизни у человека непростой период.
Мы все любим и ценим уважительное, заинтересованное отношение к себе. А современный менеджер - это в последнюю очередь начальник, который всегда прав. Более того, именно у членов своей команды я стараюсь научиться чему-то, чего ещё не знаю. Это особенно полезно, когда приходишь руководить в уже существующий проект, где любой член коллектива по определению знает больше тебя. И ребятам приятно, что к ним относятся как к экспертам и прислушиваются к их мнению.
Учиться у разработчиков лучше всего через парное программирование - когда вы вдвоём решаете одну задачу. Причём не важно, знаю ли я, как её решать. Даже если знаю, всегда можно подсмотреть какие-то фишки в работе с инструментами или библиотеками, задать вопросы про архитектуру системы или реализацию определённой фичи.
Регулярное парное программирование полезно обоим: я получаю знания об устройстве системы без необходимости разбираться в ней месяцами (не всегда есть возможность и необходимость), а разработчик - как минимум, "резиновую уточку", а часто и вторую светлую голову. Плюс это отличный способ поддерживать тесный контакт, быть в курсе успехов и затыков каждого члена команды.
Конечно, такое отношение к людям должно соответствовать ценностям компании, в которой я работаю. Если разработка ПО - основной бизнес, то люди - основной капитал, который холят и лелеят. А если у компании ценности другие, то нам точно не по пути: моя позиция либо выйдет боком мне самому, когда я не смогу выполнить взятые обязательства, либо команда будет в плохом смысле оторвана от действительности. Рано или поздно несоответствие моей позиции и вышестоящего руководства, если оно есть, станет очевидным, и вся с любовью выстроенная культура рассыплется как карточный домик.
Доверительное общение и хороший климат в команде незаменимы и для развития проекта или в кризисных ситуациях: когда нужно делегировать дополнительную отвественность, попросить о переработках (разумеется, оплачиваемых или компенсируемых выходными - помним про правильные ценности компании) или срочно починить что-то.
В общем, одни плюсы для всех. А какие отношения у вас с руководителем и/или подчинёнными?
Фейсбук сломался - и это ожидаемо
Сломались мессенджер, инстаграм - пользователи не могут залогиниться, не могут отправить сообщения. Я давно наблюдаю за жизнью больших систем в разных компаниях, большинство из которых регулярно ломается. Но ведь можно же делать хорошо, чтоб не ломались? Особенно когда у компании есть буквально армия разработчиков.
Я тоже так думал долгое время, но с годами интуитивно всё чаще избегал и даже активно противостоял сложности в проектировании и реализации программных систем. Сформировалось профессиональное чутьё, идеальное отражающее “закон Мёрфи”: если что-то может пойти не так, оно пойдёт не так.
Но оставалось глубокое неприятие: как же так, стараемся, проектируем и планируем, тратим кучу времени и денег, а получается всё равно говно, которое гарантированно сломается. Что же мы все делаем не так?
И тут мне попалась книжка The Systems Bible, которая волшебным образом разрешила это противоречие. Ненадёжность, как и куча других качеств больших систем - непредсказуемость, сопротивление достижению собственных целей, отрыв от реальности и прочие - просто фундаментальны для них. Проблем не избегает ничто: ни бюрократические аппараты правительств, ни сети супермаркетов, ни программные системы.
Книга достаточно объёмная и написана немного претенциозно, но если вы, как и я, уже не можете спокойно воспринимать вечные поломки и проблемы с системами, в которые вы вложили всю душу, рекомендую к прочтению.
Поделитесь постом с друзьями, которым приходилось исправлять баги там, где их не должно было быть 😁
Сломались мессенджер, инстаграм - пользователи не могут залогиниться, не могут отправить сообщения. Я давно наблюдаю за жизнью больших систем в разных компаниях, большинство из которых регулярно ломается. Но ведь можно же делать хорошо, чтоб не ломались? Особенно когда у компании есть буквально армия разработчиков.
Я тоже так думал долгое время, но с годами интуитивно всё чаще избегал и даже активно противостоял сложности в проектировании и реализации программных систем. Сформировалось профессиональное чутьё, идеальное отражающее “закон Мёрфи”: если что-то может пойти не так, оно пойдёт не так.
Но оставалось глубокое неприятие: как же так, стараемся, проектируем и планируем, тратим кучу времени и денег, а получается всё равно говно, которое гарантированно сломается. Что же мы все делаем не так?
И тут мне попалась книжка The Systems Bible, которая волшебным образом разрешила это противоречие. Ненадёжность, как и куча других качеств больших систем - непредсказуемость, сопротивление достижению собственных целей, отрыв от реальности и прочие - просто фундаментальны для них. Проблем не избегает ничто: ни бюрократические аппараты правительств, ни сети супермаркетов, ни программные системы.
Книга достаточно объёмная и написана немного претенциозно, но если вы, как и я, уже не можете спокойно воспринимать вечные поломки и проблемы с системами, в которые вы вложили всю душу, рекомендую к прочтению.
Поделитесь постом с друзьями, которым приходилось исправлять баги там, где их не должно было быть 😁
Было бы интересно читать о чём-то, кроме привычных тем?
Anonymous Poll
48%
Да, обо всем
31%
Только о связанном с IT-индустрией
3%
Нет, мне так нравится
2%
Мне и так не нравится, пиши о другом
15%
Посмотреть результаты
Не успели мы удивиться поломке фейсбука, сдохли и сервисы гугла - ютуб, docs, gmail и прочие. Смешнее всего то, что дашборд состояния их сервисов был весь зелёный первые минут 20 поломки, и только сейчас покраснел. Как будто бы кто-то руками перевёл его в аварийное состояние.
Сегодня рассказываю ребятам из Школы 21 о построении карьеры. Название стрима выбрал немного провокационное - “Попасть в FAANG недостаточно”, чтобы ещё разок проехаться по любимой теме 😁 Поделюсь своими наблюдениями и ошибкам за 13+ лет работы в веб-разработке и, надеюсь, сэкономлю кому-то годы жизни на нелюбимой работе (особенно неприятно, если высокооплачиваемой, но по-прежнему нелюбимой).
Пройдёмся по следующим темам:
- С чего начать карьеру и как нарабатывать репутацию
- Что важнее - деньги или опыт?
- Ненавижу это слово, но другого нет - как быть продуктивным
- Как, чему и где учиться
- Как подавать себя с наилучшей стороны, в том числе на собеседованиях
- Зачем понимать бизнес
- Что дальше?
После трансляции поделюсь с вами записью и конспектом своего рассказа. Всем хорошего дня! 🍉
Пройдёмся по следующим темам:
- С чего начать карьеру и как нарабатывать репутацию
- Что важнее - деньги или опыт?
- Ненавижу это слово, но другого нет - как быть продуктивным
- Как, чему и где учиться
- Как подавать себя с наилучшей стороны, в том числе на собеседованиях
- Зачем понимать бизнес
- Что дальше?
После трансляции поделюсь с вами записью и конспектом своего рассказа. Всем хорошего дня! 🍉
Друзья, как и обещал, публикую конспект стрима Попасть в FAANG недостаточно, или 9 шагов к карьере мечты. Запись тоже доступна на ютубе, а ниже привожу уж самые основные тезисы, хотя сокращать конспект уже дальше некуда, откровенно говоря.
- Карьера ≠ работа
- Учитесь делать крутые штуки
- Выбирайте ответственность, а не деньги
- В совершенстве владейте инструментами
- Учитесь
- Подавайте себя с выгодной стороны
- Организовывайте работу
- Понимайте бизнес и сопереживайте пользователям
- Будьте полезны сообществу
- Найдите своё место
Поделитесь этим постом с друзьями и, пожалуйста, полайкайте и положите в закладки на VC - этим вы сильно поможете попаданию статьи на главную и сделаете мне приятно. Спасибо! 🤩
- Карьера ≠ работа
- Учитесь делать крутые штуки
- Выбирайте ответственность, а не деньги
- В совершенстве владейте инструментами
- Учитесь
- Подавайте себя с выгодной стороны
- Организовывайте работу
- Понимайте бизнес и сопереживайте пользователям
- Будьте полезны сообществу
- Найдите своё место
Поделитесь этим постом с друзьями и, пожалуйста, полайкайте и положите в закладки на VC - этим вы сильно поможете попаданию статьи на главную и сделаете мне приятно. Спасибо! 🤩
vc.ru
Попасть в FAANG недостаточно, или 9 шагов к карьере мечты — Карьера на vc.ru
Привет, с вами Громов. Недавно я провёл стрим про карьеру для студентов Школы 21, который получился очень насыщенным — и я успел коснуться только около трети запланированного. Ниже его основные мысли, если у вас нет времени смотреть часовую запись.
Кому на удалёнке жить тяжело
Классная мысль промелькнула в результатах 2020-го Оли Полищук (про тусовку и её запись я узнал от Вани Замесина, за что ему спасибо - там потрясающая плотность интересных мыслей).
Те, кому на удалёнке стало тяжело и плохо (если дома нет детей, ха-ха), скорее всего страдают не только и не столько от формата, а от неприятия сути своей работы. Когда ты ходишь в большой, красивый, престижный офис, тусишь возле кофе-машины с печеньками, в столовой и после работы с коллегами, жизнь не кажется такой уж бестолковой. Да, задачи скучноваты, да, делается всё долго, да, “зачем это всё?” - но в целом жить можно.
А когда всей мишуры вокруг вдруг не остаётся, а остаётся только высасывающая душу рутина и бессмысленность, немудрено на стену полезть.
Надеюсь, вынужденная удалёнка не прошлась катком одинаково по всем. Но если вам или вашим знакомым прям досталось, задумайтесь, а делаете ли вы то, что хотите, и с теми, с кем хотите. Всем добра! ❤️
Классная мысль промелькнула в результатах 2020-го Оли Полищук (про тусовку и её запись я узнал от Вани Замесина, за что ему спасибо - там потрясающая плотность интересных мыслей).
Те, кому на удалёнке стало тяжело и плохо (если дома нет детей, ха-ха), скорее всего страдают не только и не столько от формата, а от неприятия сути своей работы. Когда ты ходишь в большой, красивый, престижный офис, тусишь возле кофе-машины с печеньками, в столовой и после работы с коллегами, жизнь не кажется такой уж бестолковой. Да, задачи скучноваты, да, делается всё долго, да, “зачем это всё?” - но в целом жить можно.
А когда всей мишуры вокруг вдруг не остаётся, а остаётся только высасывающая душу рутина и бессмысленность, немудрено на стену полезть.
Надеюсь, вынужденная удалёнка не прошлась катком одинаково по всем. Но если вам или вашим знакомым прям досталось, задумайтесь, а делаете ли вы то, что хотите, и с теми, с кем хотите. Всем добра! ❤️
Итоги 2020 подвезли 🤩
Я начал вести канал в апреле, и к декабрю “пробил” тысячу подписчиков. А самое главное - вы все живые, активные и интересные, и я ужасно рад, что у меня в канале собирается такая аудитория! Спасибо вам.
В Новом году желаю вам побольше нормальности, а ещё внимания к личному бренду. Даже в микромасштабе, как у меня, публичность приносит удивительно много знакомств и возможностей.
С наступающим! 🎄
Я начал вести канал в апреле, и к декабрю “пробил” тысячу подписчиков. А самое главное - вы все живые, активные и интересные, и я ужасно рад, что у меня в канале собирается такая аудитория! Спасибо вам.
В Новом году желаю вам побольше нормальности, а ещё внимания к личному бренду. Даже в микромасштабе, как у меня, публичность приносит удивительно много знакомств и возможностей.
С наступающим! 🎄
Занудные вопросы
В фейсбуке наткнулся на прикольный “метод занудных вопросов” от Максима Дорофеева. Помогает разобраться, чего на самом деле хочется - и, бонусом, странные и чужие желания могут отвалиться через несколько итераций.
Инструкция для ленивых:
- Выписываете ответы на вопрос “Чего я хочу?”
- Для каждой хотелки достраиваете причинно-следственную цепочку вопросом “Чтобы что?”
- Каждую прото-цель дополняете вопросами “Что ещё нужно?”
- Проверяете причинно-следственные связи вопросом “Почему?”
- Накидываете бреда - “Как ещё?”
- Фантазируете про MVP каждой цели-хотелки.
Важно честно отвечать на вопрос “чтобы что?”, а потом проверять себя вопросом “почему?”.
Сначала у меня получилась каша на целый лист формата A2, которую невозможно понять. Помучившись, я перенёс её в yEd Live - там можно строить графы и есть сносная авто-расстановка нод.
Но на следующий день, взяв всего одну хотелку-цель, я сделал вполне непротиворечивый граф своих хотелок. Полезная техника, рекомендую!
В фейсбуке наткнулся на прикольный “метод занудных вопросов” от Максима Дорофеева. Помогает разобраться, чего на самом деле хочется - и, бонусом, странные и чужие желания могут отвалиться через несколько итераций.
Инструкция для ленивых:
- Выписываете ответы на вопрос “Чего я хочу?”
- Для каждой хотелки достраиваете причинно-следственную цепочку вопросом “Чтобы что?”
- Каждую прото-цель дополняете вопросами “Что ещё нужно?”
- Проверяете причинно-следственные связи вопросом “Почему?”
- Накидываете бреда - “Как ещё?”
- Фантазируете про MVP каждой цели-хотелки.
Важно честно отвечать на вопрос “чтобы что?”, а потом проверять себя вопросом “почему?”.
Сначала у меня получилась каша на целый лист формата A2, которую невозможно понять. Помучившись, я перенёс её в yEd Live - там можно строить графы и есть сносная авто-расстановка нод.
Но на следующий день, взяв всего одну хотелку-цель, я сделал вполне непротиворечивый граф своих хотелок. Полезная техника, рекомендую!
Придумал я (года полтора назад) сделать веб-свистульку для оценки стоимости жизни в разных локациях. Например, переезжаем из Москвы в Лондон - сколько потребуется денег, чтобы сохранить прежний образ жизни?
Начал с описания образа жизни:
- сколько взрослых и детей в семье
- где хотите жить
- как часто готовите и едите не дома
- кто будет ездить на работу, кто ходить в фитнес
- платные детские сады и школы
Для примера собрал табличку с кучей подобранных руками коэффициентов, и результат вроде даже сходится для еды. Ну и погнали дальше - пока скрэйпятся данные с numbeo.com, буду собирать простое веб-приложение. Надеюсь, без бэкенда - все данные разложу по статичным подготовленным джейсончикам. Так и хоститься проще, и на прототип тратить много времени не хочется.
Рассчитываю, что в приложении будет интересно и удобно (в отличие от таблички или калькулятора с того же numbeo) крутить туда-сюда разные параметры и смотреть, на что можно рассчитывать.
Добавили бы что-нибудь к списку вопросов?
Начал с описания образа жизни:
- сколько взрослых и детей в семье
- где хотите жить
- как часто готовите и едите не дома
- кто будет ездить на работу, кто ходить в фитнес
- платные детские сады и школы
Для примера собрал табличку с кучей подобранных руками коэффициентов, и результат вроде даже сходится для еды. Ну и погнали дальше - пока скрэйпятся данные с numbeo.com, буду собирать простое веб-приложение. Надеюсь, без бэкенда - все данные разложу по статичным подготовленным джейсончикам. Так и хоститься проще, и на прототип тратить много времени не хочется.
Рассчитываю, что в приложении будет интересно и удобно (в отличие от таблички или калькулятора с того же numbeo) крутить туда-сюда разные параметры и смотреть, на что можно рассчитывать.
Добавили бы что-нибудь к списку вопросов?
Калькулятор стоимости жизни, о котором я писал неделю назад, потихоньку воплощается в жизнь 🤩
💾 Данные с numbeo.com, которые можно использовать со ссылкой на них, спарсились за несколько часов без каких-то особых выкрутасов с помощью нескольких скриптов и scrapy (популярная питонячья либа для скрэйпинга). Я допускал, что придётся использовать прокси или как-то ещё обходить блокировки, но 9000 запросов за несколько часов даже с одного IP - детский сад.
💥 Очень рад, что механика работы калькулятора - вводишь параметры своего образа жизни, потом выбираешь интересующие города - позволяет делать HTTP-запрос на каждый новый город. Данные в прототипе статичные (и наверняка такими и останутся), а значит вместо бэкенда с базой данных оказалось достаточно предобработки (надо было разложить чиселки в правильные ключи), чистки (выкинуть города с неполными данными, числа сделать числами) и раздачи статичных JSON-файлов с помощью nginx. Городов с полными данными осталось 900 с небольшим.
⏳ Приложение я сделал на реакте с помощью удобного create-react-app. Не очень люблю такие комбайны (и не боюсь webpack - наконфигурировался в своё время), но экономия времени на разработке бесценна, особенно потенциально бесполезного прототипа. Единственный минус - нельзя задать пути для статики, а у меня уже настроен nginx. Пришлось делать
🧩 В качестве библиотеки компонентов сначала попробовал Material UI, который я использовал в Quiken, но он страшный и тяжёлый - особенно раздражает развесистый API и чрезмерная атомарность компонентов. Перешёл на Blueprint UI от Palantir - он классный, и есть так нужный мне для выбора городов Suggest - это такой компонент для auto complete. Он пока немного тормозит при рендеринге. Все компоненты не настраивал вообще, только раскидал по колонкам.
📝 Первоначально я хотел взять UI kit побогаче, со всякими панельками и всплывашками, но решил не усложнять. Скорее всего, все эти панельки мне всё равно не пригодятся, когда буду делать нормальный интерфейс. Для базовой колоночной раскладки страницы написал немного CSS и HTML руками. В 2021-м с flex-box это кайф, не то что 10 лет назад с float: left и отрицательными полями.
⚙️ Деплой получился чуток замороченный, потому что я решил встроить калькулятор в свой (ещё не доделанный) gromov.com: для этого дописал ansible playbook и поправил nginx-конфиги. Всё приложение - это около 1000 статичных файлов, а раздать статику не проблема. Но от ansible-франкенштейна в будущем хочу избавиться. Хоть он и разворачивает весь сайт с django, nginx, uploads и статикой на пустом VPS с ssh и является infrastructure-as-code, всё равно буду искать что-то попроще и декларативное.
Итого получилось меньше недели от идеи до функционального прототипа 🔥
В течение следующих нескольких недель (надо делать быстро, потому что строить никому не нужные чудо-интернет-проекты годами явно не моё) буду работать над более полной версией с пошаговым мастером для настройки образа жизни и вменяемым интерфейсом сравнения, а пока можете потыкать получившийся прототип.
В колонке слева подставлены дефолтные значения для семьи с маленьким ребёнком, а справа есть почти незаметная кнопочка Select city. Выбирайте первым город, где живёте сейчас, и следом добавляйте интересные вам.
Как вам кажется, полезная штука? Жду ваших комментариев!
💾 Данные с numbeo.com, которые можно использовать со ссылкой на них, спарсились за несколько часов без каких-то особых выкрутасов с помощью нескольких скриптов и scrapy (популярная питонячья либа для скрэйпинга). Я допускал, что придётся использовать прокси или как-то ещё обходить блокировки, но 9000 запросов за несколько часов даже с одного IP - детский сад.
💥 Очень рад, что механика работы калькулятора - вводишь параметры своего образа жизни, потом выбираешь интересующие города - позволяет делать HTTP-запрос на каждый новый город. Данные в прототипе статичные (и наверняка такими и останутся), а значит вместо бэкенда с базой данных оказалось достаточно предобработки (надо было разложить чиселки в правильные ключи), чистки (выкинуть города с неполными данными, числа сделать числами) и раздачи статичных JSON-файлов с помощью nginx. Городов с полными данными осталось 900 с небольшим.
⏳ Приложение я сделал на реакте с помощью удобного create-react-app. Не очень люблю такие комбайны (и не боюсь webpack - наконфигурировался в своё время), но экономия времени на разработке бесценна, особенно потенциально бесполезного прототипа. Единственный минус - нельзя задать пути для статики, а у меня уже настроен nginx. Пришлось делать
npm run eject и менять конфиг руками. Ну да невелика потеря.🧩 В качестве библиотеки компонентов сначала попробовал Material UI, который я использовал в Quiken, но он страшный и тяжёлый - особенно раздражает развесистый API и чрезмерная атомарность компонентов. Перешёл на Blueprint UI от Palantir - он классный, и есть так нужный мне для выбора городов Suggest - это такой компонент для auto complete. Он пока немного тормозит при рендеринге. Все компоненты не настраивал вообще, только раскидал по колонкам.
📝 Первоначально я хотел взять UI kit побогаче, со всякими панельками и всплывашками, но решил не усложнять. Скорее всего, все эти панельки мне всё равно не пригодятся, когда буду делать нормальный интерфейс. Для базовой колоночной раскладки страницы написал немного CSS и HTML руками. В 2021-м с flex-box это кайф, не то что 10 лет назад с float: left и отрицательными полями.
⚙️ Деплой получился чуток замороченный, потому что я решил встроить калькулятор в свой (ещё не доделанный) gromov.com: для этого дописал ansible playbook и поправил nginx-конфиги. Всё приложение - это около 1000 статичных файлов, а раздать статику не проблема. Но от ansible-франкенштейна в будущем хочу избавиться. Хоть он и разворачивает весь сайт с django, nginx, uploads и статикой на пустом VPS с ssh и является infrastructure-as-code, всё равно буду искать что-то попроще и декларативное.
Итого получилось меньше недели от идеи до функционального прототипа 🔥
В течение следующих нескольких недель (надо делать быстро, потому что строить никому не нужные чудо-интернет-проекты годами явно не моё) буду работать над более полной версией с пошаговым мастером для настройки образа жизни и вменяемым интерфейсом сравнения, а пока можете потыкать получившийся прототип.
В колонке слева подставлены дефолтные значения для семьи с маленьким ребёнком, а справа есть почти незаметная кнопочка Select city. Выбирайте первым город, где живёте сейчас, и следом добавляйте интересные вам.
Как вам кажется, полезная штука? Жду ваших комментариев!
Чем круты крутые программисты
Давайте представим, что на свете есть крутые программисты - намного продуктивнее, точнее в принятии решений и богаче нас с вами. Не Керниган, Торвальдс или Кармак, а обычные ребята, сидящие за соседним столом. На самом деле, у меня даже есть друзья - такие крутаны. Я всегда смотрел на них и удивлялся: как им удаётся так (много шипить|правильно принимать решения|мало спать)? Мне вот если и удаётся, то редко, особенно в контексте работы.
Давайте разберёмся, что в них особенного.
🔥 Крутаны сначала делают, чтобы их код работал. Недописанная программа - худший вариант её существования: она не решает никаких проблем, а только создаёт; она уродлива по своей структуре; хуже всего - она оставляет кучу вопросов “а если...”, ответов на которые уже никогда не получить.
На этом этапе код может быть кривым и глючным, тормозить и не проходить ревью коллег - но он уже существует и работает.
Как и любой творец, программист не понимает всех свойств своей программы, пока не побалуется с ней вдоволь, не попробует порефакторить так и эдак, не заметит проблем в первом, наивном исполнении. Поэтому даже грубый работающий прототип чрезвычайно полезен - и, главное, разносит в пух и прах прокрастинацию и запускает думалку на полную катушку.
🎯 Потом крутаны убеждаются, что программа решает задачи, стоящие перед ней - помочь пользователям добиться своих целей, впечатлить инвесторов, порадовать проджект-менеджера или улучшить архитектуру системы. Инсайты, полученные на этапе прототипирования, дополняются обратной связью от пользователей и стейкхолдеров - и становится понятно, что именно нужно делать на самом деле.
Контекст может быть разный - корпоративный, стартаперский или любой другой. Важно, что уже можно правильно спланировать разработку и разделить обязанности в команде, собрать полезный и не страшный MVP, получить первые результаты от введения системы в эксплуатацию.
🏅 И только в самом конце крутаны тратят силы на увеличение эффективности кода и уменьшение издержек его существования: подбирают эффективные алгоритмы, лаконичные структуры данных и оптимальную конфигурацию системы, делают код понятным и поддерживаемым, пишут интеграционные тесты, чтобы не ломать систему с каждым следующим обновлением.
Больше 15 лет назад, только начиная заниматься программированием, я сразу понял эти прописные истины. И следующие лет 10 всё делал наоборот.
Мой код не работал, а я не заканчивал проекты и не получал никаких результатов. Мне было интереснее всего написать код “правильно” и сделать его быстрым (недаром я впирался в Си, Ассемблер и прочую низкоуровневую шнягу), подобрать “наилучшую” архитектуру, пропустить все полезные промежуточные шаги и сразу сделать приложение, решающее все задачи. Разумеется, доступные моему прозорливому взгляду ещё до начала работы.
Проблема в том, что так не бывает - по крайней мере, у меня. Не получается перескочить десятки итераций написания кода и создания продукта. Мозг отказывается работать и сползает в прокрастинацию, пусть даже и с учебником по очередной технологии. Разумеется, большая часть моих программ так и лежит в ящике для недописанных шедевров.
Не повторяйте глупых ошибок, будьте крутанами! Пишите код, который работает, показывайте результаты как можно раньше, переписывайте и дорабатывайте его так часто, как необходимо, и оптимизируйте в последнюю очередь 🤘
А пока будете обдумывать следующий рефакторинг, поделитесь этим постом с друзьями и коллегами 😜
@gromov_com
Давайте представим, что на свете есть крутые программисты - намного продуктивнее, точнее в принятии решений и богаче нас с вами. Не Керниган, Торвальдс или Кармак, а обычные ребята, сидящие за соседним столом. На самом деле, у меня даже есть друзья - такие крутаны. Я всегда смотрел на них и удивлялся: как им удаётся так (много шипить|правильно принимать решения|мало спать)? Мне вот если и удаётся, то редко, особенно в контексте работы.
Давайте разберёмся, что в них особенного.
🔥 Крутаны сначала делают, чтобы их код работал. Недописанная программа - худший вариант её существования: она не решает никаких проблем, а только создаёт; она уродлива по своей структуре; хуже всего - она оставляет кучу вопросов “а если...”, ответов на которые уже никогда не получить.
На этом этапе код может быть кривым и глючным, тормозить и не проходить ревью коллег - но он уже существует и работает.
Как и любой творец, программист не понимает всех свойств своей программы, пока не побалуется с ней вдоволь, не попробует порефакторить так и эдак, не заметит проблем в первом, наивном исполнении. Поэтому даже грубый работающий прототип чрезвычайно полезен - и, главное, разносит в пух и прах прокрастинацию и запускает думалку на полную катушку.
🎯 Потом крутаны убеждаются, что программа решает задачи, стоящие перед ней - помочь пользователям добиться своих целей, впечатлить инвесторов, порадовать проджект-менеджера или улучшить архитектуру системы. Инсайты, полученные на этапе прототипирования, дополняются обратной связью от пользователей и стейкхолдеров - и становится понятно, что именно нужно делать на самом деле.
Контекст может быть разный - корпоративный, стартаперский или любой другой. Важно, что уже можно правильно спланировать разработку и разделить обязанности в команде, собрать полезный и не страшный MVP, получить первые результаты от введения системы в эксплуатацию.
🏅 И только в самом конце крутаны тратят силы на увеличение эффективности кода и уменьшение издержек его существования: подбирают эффективные алгоритмы, лаконичные структуры данных и оптимальную конфигурацию системы, делают код понятным и поддерживаемым, пишут интеграционные тесты, чтобы не ломать систему с каждым следующим обновлением.
Больше 15 лет назад, только начиная заниматься программированием, я сразу понял эти прописные истины. И следующие лет 10 всё делал наоборот.
Мой код не работал, а я не заканчивал проекты и не получал никаких результатов. Мне было интереснее всего написать код “правильно” и сделать его быстрым (недаром я впирался в Си, Ассемблер и прочую низкоуровневую шнягу), подобрать “наилучшую” архитектуру, пропустить все полезные промежуточные шаги и сразу сделать приложение, решающее все задачи. Разумеется, доступные моему прозорливому взгляду ещё до начала работы.
Проблема в том, что так не бывает - по крайней мере, у меня. Не получается перескочить десятки итераций написания кода и создания продукта. Мозг отказывается работать и сползает в прокрастинацию, пусть даже и с учебником по очередной технологии. Разумеется, большая часть моих программ так и лежит в ящике для недописанных шедевров.
Не повторяйте глупых ошибок, будьте крутанами! Пишите код, который работает, показывайте результаты как можно раньше, переписывайте и дорабатывайте его так часто, как необходимо, и оптимизируйте в последнюю очередь 🤘
А пока будете обдумывать следующий рефакторинг, поделитесь этим постом с друзьями и коллегами 😜
@gromov_com
Год в Фейсбуке 👻
Год назад, второй раз в жизни после собеседований, я вошёл в офис Facebook на Rathbone Square в Лондоне. Вошёл с большими надеждами: как и устраиваясь в Яндекс 7 лет назад, я надеялся найти своё место и сделать что-то большое и полезное.
Хотелось уйти с удалёнки, попасть в стабильную компанию (переезд с семьей - та ещё эпопея), получить заветную строчку в резюме - и, где-то в глубине души, даже заняться the most important work of my career, как говорят в буткэмпе.
В честь годовщины порефлексирую вместе с вами о прошедшем годе.
🦠 Коронавирус, подлая тварь, всё испортил. После моих первых 3 недель в офисе Лондон стал постепенно, рывками закрываться - вплоть до полного локдауна. И уже в середине марта стало очевидно, что в офис мы вернёмся не скоро. Я нашёл квартиру побольше и подальше от центра (что оказалось очень мудрым решением) и скрепя сердце отказался от надежды разделить наконец работу и дом.
💷 Ожидания к стабильности компании полностью оправдались. Думаю, я куда сильнее переживал бы, окажись я в компании поменьше (впрочем, совсем маленькие я и не рассматривал вообще), где могли бы быть проблемы с деньгами. Ведь много людей, в том числе программистов, остались без работы во время пандемии!
Фейсбук платит немного выше рынка, даёт бонусы (важнейшая часть - sign-on, торгуйтесь изо всех сил!), акции. Кроме этого, у нас есть оплачиваемый COVID-отпуск (вплоть до десятков недель в год), всякие Laundry & Childcare allowance, было несколько выплат "на домашний офис". Короче, денег могло бы быть больше только в каком-то крутом финтехе или банках, но там свои особенности.
Но, увы, Лондон очень дорогой. И поэтому заработать миллионы в местном Фейсбуке, в отличие от США, обычному разработчику невозможно.
🧗♂️ Сложностей в работе очень много, даже намного больше, чем я опасался. В фейсбуке десятки тысяч программистов (прямо или косвенно я взаимодействую как минимум с полсотней человек) и сотни тысяч коммитов в нескольких громадных монорепозиториях. Кроме того, я работаю в Workplace - это такой "фейсбук для компаний", и он унаследовал огромную часть кода от самого Facebook. Разумеется, не бесплатно - разбираться в этом всём можно годами, и так и не разобраться.
Тут достаточно странная культура разработки: бери и делай всё, что принесёт impact (то есть положительно повлияет на продукт, пользователей, компанию), лезь в любой код и меняй под свою задачу. Конечно, ограничения есть: надо согласовывать планы с командой, и не получится поменять код биллинга или выключить датацентр. Но всё же выходит, что разработчик в фейсбуке - это такой стартапер-продакт, который плюс-минус сам выбирает над чем работать, сам продаёт результаты своей работы и сам за всё отвечает.
С одной стороны, круто. Я вижу людей, которых от этого реально прёт, и на ревью они получают хорошие бонусы и оценки. С другой стороны, просто нормально работать не получается. Приходится конкурировать за интересные проекты, бросать их на полпути, переделывать всё по несколько раз.
И без того сложные (а часто и переусложнённые) системы с таким подходом становятся всё более и более запутанными (особенно продуктовый код), а работа программиста всё больше напоминает небезызвестный подвиг Геракла. Вторые 80% работы - это обсуждения и попытки понять, как это работает и что с этим делать.
Год назад, второй раз в жизни после собеседований, я вошёл в офис Facebook на Rathbone Square в Лондоне. Вошёл с большими надеждами: как и устраиваясь в Яндекс 7 лет назад, я надеялся найти своё место и сделать что-то большое и полезное.
Хотелось уйти с удалёнки, попасть в стабильную компанию (переезд с семьей - та ещё эпопея), получить заветную строчку в резюме - и, где-то в глубине души, даже заняться the most important work of my career, как говорят в буткэмпе.
В честь годовщины порефлексирую вместе с вами о прошедшем годе.
🦠 Коронавирус, подлая тварь, всё испортил. После моих первых 3 недель в офисе Лондон стал постепенно, рывками закрываться - вплоть до полного локдауна. И уже в середине марта стало очевидно, что в офис мы вернёмся не скоро. Я нашёл квартиру побольше и подальше от центра (что оказалось очень мудрым решением) и скрепя сердце отказался от надежды разделить наконец работу и дом.
💷 Ожидания к стабильности компании полностью оправдались. Думаю, я куда сильнее переживал бы, окажись я в компании поменьше (впрочем, совсем маленькие я и не рассматривал вообще), где могли бы быть проблемы с деньгами. Ведь много людей, в том числе программистов, остались без работы во время пандемии!
Фейсбук платит немного выше рынка, даёт бонусы (важнейшая часть - sign-on, торгуйтесь изо всех сил!), акции. Кроме этого, у нас есть оплачиваемый COVID-отпуск (вплоть до десятков недель в год), всякие Laundry & Childcare allowance, было несколько выплат "на домашний офис". Короче, денег могло бы быть больше только в каком-то крутом финтехе или банках, но там свои особенности.
Но, увы, Лондон очень дорогой. И поэтому заработать миллионы в местном Фейсбуке, в отличие от США, обычному разработчику невозможно.
🧗♂️ Сложностей в работе очень много, даже намного больше, чем я опасался. В фейсбуке десятки тысяч программистов (прямо или косвенно я взаимодействую как минимум с полсотней человек) и сотни тысяч коммитов в нескольких громадных монорепозиториях. Кроме того, я работаю в Workplace - это такой "фейсбук для компаний", и он унаследовал огромную часть кода от самого Facebook. Разумеется, не бесплатно - разбираться в этом всём можно годами, и так и не разобраться.
Тут достаточно странная культура разработки: бери и делай всё, что принесёт impact (то есть положительно повлияет на продукт, пользователей, компанию), лезь в любой код и меняй под свою задачу. Конечно, ограничения есть: надо согласовывать планы с командой, и не получится поменять код биллинга или выключить датацентр. Но всё же выходит, что разработчик в фейсбуке - это такой стартапер-продакт, который плюс-минус сам выбирает над чем работать, сам продаёт результаты своей работы и сам за всё отвечает.
С одной стороны, круто. Я вижу людей, которых от этого реально прёт, и на ревью они получают хорошие бонусы и оценки. С другой стороны, просто нормально работать не получается. Приходится конкурировать за интересные проекты, бросать их на полпути, переделывать всё по несколько раз.
И без того сложные (а часто и переусложнённые) системы с таким подходом становятся всё более и более запутанными (особенно продуктовый код), а работа программиста всё больше напоминает небезызвестный подвиг Геракла. Вторые 80% работы - это обсуждения и попытки понять, как это работает и что с этим делать.
Год в Фейсбуке - продолжение
⏰ Начитавшись нытья на Blind, я ожидал, что work-life balance будет поганым. И тут, видимо, мне повезло - а ещё свою роль сыграла пандемия, неготовность компании к удалёнке и какая-то всё же забота о сотрудниках.
У нас в команде достаточно лайтовое планирование и почти нет дедлайнов, не нужно много взаимодействовать с командами в других часовых поясах. Самое плохое, пожалуй, это ужасный on-call, в рамках которого приходится лезть в код, который я вижу в первый раз, и срочно там что-то ремонтировать. Настроение портит изрядно.
В остальном даже удивительно, как ненапряжно выходит работать в фейсбуке. Но с таким подходом мне точно не продвинуться по карьерной лестнице.
🤦🏻♂️ В целом, моя работа очень скучная. Найм устроен так, что ты не устраиваешься в конкретную команду, а сначала проходишь bootcamp, чтобы потом выбрать из доступных команд. В теории звучит круто - ведь можно пойти делать React или Presto! На практике же, в крутую команду практически невозможно попасть, а выбирать приходится из очень ограниченного количества команд, которые нанимают сейчас.
Конечно, Фейсбук - большая компания, и тут явно есть люди, занимающиеся исследованиями в AI или создающие крутые продукты с нуля. Им не просто больше повезло, а у них есть определённые карьерные цели, они зарабатывают репутацию и плюс-минус хорошо работают локтями в толпе.
🤔 Это, пожалуй, самое просветляющее наблюдение для меня (ага, сообразил наконец): корпорация - это не дорога к счастью и богатству, а большой мир в миниатюре. Тут так же, если не сильнее, нужно бороться за место под солнцем с другими, играть в политику и учитывать интересы сотен людей, быть предпринимателем и делателем одновременно.
😎 Подводя итоги, наверное я правильно рассудил, выбрав именно Фейсбук для переезда. Худшее, что тут есть - это Авгиевы конюшни кода объёмнее привычных в десятки и сотни раз. Но в целом в компании довольно комфортно работать. С другой стороны, если посмотреть на несколько лет вперёд, оставаться работать разработчиком тут или в другой корпорации не имеет никакого смысла.
В фейсбук достаточно сложно (но вовсе не невозможно!) попасть, но стремиться к этому или нет - решать вам. Мой вердикт: да, если вы точно понимаете, зачем вам это нужно. Удачи!
@gromov_com
⏰ Начитавшись нытья на Blind, я ожидал, что work-life balance будет поганым. И тут, видимо, мне повезло - а ещё свою роль сыграла пандемия, неготовность компании к удалёнке и какая-то всё же забота о сотрудниках.
У нас в команде достаточно лайтовое планирование и почти нет дедлайнов, не нужно много взаимодействовать с командами в других часовых поясах. Самое плохое, пожалуй, это ужасный on-call, в рамках которого приходится лезть в код, который я вижу в первый раз, и срочно там что-то ремонтировать. Настроение портит изрядно.
В остальном даже удивительно, как ненапряжно выходит работать в фейсбуке. Но с таким подходом мне точно не продвинуться по карьерной лестнице.
🤦🏻♂️ В целом, моя работа очень скучная. Найм устроен так, что ты не устраиваешься в конкретную команду, а сначала проходишь bootcamp, чтобы потом выбрать из доступных команд. В теории звучит круто - ведь можно пойти делать React или Presto! На практике же, в крутую команду практически невозможно попасть, а выбирать приходится из очень ограниченного количества команд, которые нанимают сейчас.
Конечно, Фейсбук - большая компания, и тут явно есть люди, занимающиеся исследованиями в AI или создающие крутые продукты с нуля. Им не просто больше повезло, а у них есть определённые карьерные цели, они зарабатывают репутацию и плюс-минус хорошо работают локтями в толпе.
🤔 Это, пожалуй, самое просветляющее наблюдение для меня (ага, сообразил наконец): корпорация - это не дорога к счастью и богатству, а большой мир в миниатюре. Тут так же, если не сильнее, нужно бороться за место под солнцем с другими, играть в политику и учитывать интересы сотен людей, быть предпринимателем и делателем одновременно.
😎 Подводя итоги, наверное я правильно рассудил, выбрав именно Фейсбук для переезда. Худшее, что тут есть - это Авгиевы конюшни кода объёмнее привычных в десятки и сотни раз. Но в целом в компании довольно комфортно работать. С другой стороны, если посмотреть на несколько лет вперёд, оставаться работать разработчиком тут или в другой корпорации не имеет никакого смысла.
В фейсбук достаточно сложно (но вовсе не невозможно!) попасть, но стремиться к этому или нет - решать вам. Мой вердикт: да, если вы точно понимаете, зачем вам это нужно. Удачи!
@gromov_com
Соберёмся в клабхаусе?
Я попробовал: напоминает глобальное радио - 2.0. Один или несколько ведущих разговаривают на заданную тему, либо отвечают на вопросы аудитории. Прикольная штука, но пока опасаюсь, что сожрёт кучу времени 😊 Ведь, в отличие от подскастов, слушать в удобное мне время не получается - у встреч своё расписание. Зато лайв и вопросы.
Уже зарегистрировались? Мой ник - @oleggromov
Попробуем собраться и что-то обсудить? Если интересно, предлагайте темы 😎
Хороших выходных!
Я попробовал: напоминает глобальное радио - 2.0. Один или несколько ведущих разговаривают на заданную тему, либо отвечают на вопросы аудитории. Прикольная штука, но пока опасаюсь, что сожрёт кучу времени 😊 Ведь, в отличие от подскастов, слушать в удобное мне время не получается - у встреч своё расписание. Зато лайв и вопросы.
Уже зарегистрировались? Мой ник - @oleggromov
Попробуем собраться и что-то обсудить? Если интересно, предлагайте темы 😎
Хороших выходных!
Калькулятор стоимости жизни - вести с полей
По вечерам я делаю калькулятор стоимости жизни - у меня давно была эта идея, но взялся за неё я только в середине этого января. Поначалу казалось, что проект элементарный, но даже в элементарном проекте можно сильно недооценить сложность и объём работы.
В конце января был готов первый юзабельный прототип, который я сразу же выложил на сайт. Он был страшненький, местами кривой и тормозной, но основную функцию выполнял. Можно было выбрать Москву, Лос-Анджелес и сравнить стоимость жизни. Готовность проекта была может быть 50%.
За следующую неделю-полторы я добавил конвертацию валют и сравнение цен, пошаговый мастер на первом экране, селектор слева (там прикольные эмоджи и подписи, покликайте сами) и сделал селектор городов с нормальной фильтрацией, виртуализированным рендерингом (там 1000 элементов), выделением уже выбранных и популярных городов. Готовность подскочила до 80%.
На чём я споткнулся
Мне удавалось фигачить по вечерам примерно по 3-5 часов каждый день, на пределе возможностей, и ощущения от этого фигачинга были как у Микеланджело, ваяющего Давида. Но сейчас, спустя ещё 2-3 недели, готовность проекта по-прежнему где-то на уровне 80%, а я вымотан, и список незаконченных задач только увеличился. Плюс куча дел на основной работе, не говоря уже про семью. Такая вот жизнь стартапера - либо проект делать, либо с ребёнком поиграть и уборку сделать.
1) Я, видимо, перфекционист 🤬 Понимая, что можно сделать лучше (например, я неделю переделывал сравнение городов в более удобочитаемую таблицу), я так и делаю. Поначалу мне удавалось отфутболивать хотелки и делать только абсолютно необходимое, но, вместе с накапливающейся усталостью, я скатываюсь в делание всего подряд.
2) Не надо одновременно продумывать фичу, делать дизайн и реализовывать её 🤹 С дизайном вообще сложно вышло: сначала я рассчитывал сделать всё на готовых компонентах (не вышло: компоненты кривые и слишком атомарные). Потом получить конфетку от дизайнера (тоже не вышло: темпы работы оказались слишком разные). Сейчас я полностью переделываю дизайн своими силами, и это провал и трата времени в контексте MVP. Но мне нравится.
3) Я придумал какие-то сложные и ненужные штуки 🎛 Лендинг с замороченной интеграцией с SPA, перевод интерфейса на русский (я планирую запускаться в том числе на "наших", но сколько кровушки выпил i18n!), шаринг ссылок (бэкенда нет, поэтому все настройки кодируются прямо в URL), сомнительные фичи типа geek mode для расчётов. Часть из этого можно выкинуть и запуститься так, но что-то нужно для метрик и воронок - можно понять, что пользователь вовлекается по переключению в geek mode; посмотреть, как часто ссылками делятся.
4) Очень много пришлось делать руками 🛠 У меня были надежды на Suggest из Blueprint, но он подвёл больше всего: я долго пытался прикрутить к нему сначала правильные стили, потом виртуализированный рендеринг, потом категории городов (выбранные, популярные, остальные) - но не вышло. Он с трудом кастомизируется, а код местами косой. Пришлось делать самому: вышло лучше, но, опять же, куча времени впустую. Ещё и неизбежные рефакторинги, чтобы всё заработало - и, слава богу, мне хватило ума взять TypeScript!
Как надо делать MVP
MVP даже простейшего продукта - сложная штука, которая будет вести себя не так, как я хочу (капризные они, эти программные системы). А я буду пытаться починить её и потрачу кучу сил на скорее всего ненужную разработку. У меня есть стратегия и план продвижения проекта + некоторая уверенность, что продукт "полетит", но пока что всё время я потратил исключительно на разработку.
Понятно, почему весь англоязычный предпринимательский твитер твердит, что делать свой SaaS в качестве первого продукта - это безумие, и начинать надо с курсов, книжек, платных подписок на курируемую рассылку. Можно сказать, я полностью прочувствовал это: калькулятор примерно на порядок проще даже простейшего SaaS, но вожусь я с ним уже второй месяц.
Было интересно? Поделитесь своими мыслями в комментариях, а этим постом - с друзьями.
Удачи! 🤘
@gromov_com
По вечерам я делаю калькулятор стоимости жизни - у меня давно была эта идея, но взялся за неё я только в середине этого января. Поначалу казалось, что проект элементарный, но даже в элементарном проекте можно сильно недооценить сложность и объём работы.
В конце января был готов первый юзабельный прототип, который я сразу же выложил на сайт. Он был страшненький, местами кривой и тормозной, но основную функцию выполнял. Можно было выбрать Москву, Лос-Анджелес и сравнить стоимость жизни. Готовность проекта была может быть 50%.
За следующую неделю-полторы я добавил конвертацию валют и сравнение цен, пошаговый мастер на первом экране, селектор слева (там прикольные эмоджи и подписи, покликайте сами) и сделал селектор городов с нормальной фильтрацией, виртуализированным рендерингом (там 1000 элементов), выделением уже выбранных и популярных городов. Готовность подскочила до 80%.
На чём я споткнулся
Мне удавалось фигачить по вечерам примерно по 3-5 часов каждый день, на пределе возможностей, и ощущения от этого фигачинга были как у Микеланджело, ваяющего Давида. Но сейчас, спустя ещё 2-3 недели, готовность проекта по-прежнему где-то на уровне 80%, а я вымотан, и список незаконченных задач только увеличился. Плюс куча дел на основной работе, не говоря уже про семью. Такая вот жизнь стартапера - либо проект делать, либо с ребёнком поиграть и уборку сделать.
1) Я, видимо, перфекционист 🤬 Понимая, что можно сделать лучше (например, я неделю переделывал сравнение городов в более удобочитаемую таблицу), я так и делаю. Поначалу мне удавалось отфутболивать хотелки и делать только абсолютно необходимое, но, вместе с накапливающейся усталостью, я скатываюсь в делание всего подряд.
2) Не надо одновременно продумывать фичу, делать дизайн и реализовывать её 🤹 С дизайном вообще сложно вышло: сначала я рассчитывал сделать всё на готовых компонентах (не вышло: компоненты кривые и слишком атомарные). Потом получить конфетку от дизайнера (тоже не вышло: темпы работы оказались слишком разные). Сейчас я полностью переделываю дизайн своими силами, и это провал и трата времени в контексте MVP. Но мне нравится.
3) Я придумал какие-то сложные и ненужные штуки 🎛 Лендинг с замороченной интеграцией с SPA, перевод интерфейса на русский (я планирую запускаться в том числе на "наших", но сколько кровушки выпил i18n!), шаринг ссылок (бэкенда нет, поэтому все настройки кодируются прямо в URL), сомнительные фичи типа geek mode для расчётов. Часть из этого можно выкинуть и запуститься так, но что-то нужно для метрик и воронок - можно понять, что пользователь вовлекается по переключению в geek mode; посмотреть, как часто ссылками делятся.
4) Очень много пришлось делать руками 🛠 У меня были надежды на Suggest из Blueprint, но он подвёл больше всего: я долго пытался прикрутить к нему сначала правильные стили, потом виртуализированный рендеринг, потом категории городов (выбранные, популярные, остальные) - но не вышло. Он с трудом кастомизируется, а код местами косой. Пришлось делать самому: вышло лучше, но, опять же, куча времени впустую. Ещё и неизбежные рефакторинги, чтобы всё заработало - и, слава богу, мне хватило ума взять TypeScript!
Как надо делать MVP
MVP даже простейшего продукта - сложная штука, которая будет вести себя не так, как я хочу (капризные они, эти программные системы). А я буду пытаться починить её и потрачу кучу сил на скорее всего ненужную разработку. У меня есть стратегия и план продвижения проекта + некоторая уверенность, что продукт "полетит", но пока что всё время я потратил исключительно на разработку.
Понятно, почему весь англоязычный предпринимательский твитер твердит, что делать свой SaaS в качестве первого продукта - это безумие, и начинать надо с курсов, книжек, платных подписок на курируемую рассылку. Можно сказать, я полностью прочувствовал это: калькулятор примерно на порядок проще даже простейшего SaaS, но вожусь я с ним уже второй месяц.
Было интересно? Поделитесь своими мыслями в комментариях, а этим постом - с друзьями.
Удачи! 🤘
@gromov_com
Четыре модальности написания кода - часть первая
Я достаточно часто переключаюсь между разными модальностями, или режимами написания кода.
Самая распространённая (и моя самая нелюбимая) - промышленное программирование. В работе программиста слишком много мета-активностей: обсуждения и встречи, код-ревью и изучение чужого кода, скрам-ритуалы и прочие групповые встречи.
В больших компаниях всё ещё хуже: в список добавляются корпоративные тренинги, all-hands встречи, регулярные ревью результатов, часто возведённые в абсолют (в Фейсбуке, например), встречи с руководителями и трескотня бесчисленных чатов. Неудивительно, что многие пишут код всего несколько часов в день - часто в формально нерабочие часы.
Разумеется, для работы компании эффективная коммуникация и обмен информацией исключительно важны, но надо быть весьма специфичного склада характера, чтобы получать удовольствие не от создания чего-то нового из ничего - того, ради чего многие и начинали программировать, - а от участия в процессе.
Многие компании, даже став неповортливыми огромными монстрами, по-прежнему стараются получать результаты как можно эффективнее, практически в режиме стартапа: с короткими итерациями и быстрыми результатами - а значит качество кода и архитектуры, а вместе с ними гордость разработчиков за результат стремятся к нулю.
Следующая, куда больше радующая меня модальность - творческое программирование. В результате такой работы получается хорошо продуманный код, правильно моделирующий проблему (и отчасти реальность - привет, ООП) и поэтому решающий её достаточно оптимальным и очевидным способом. Правильно выбранный подход, в свою очередь, приводит к меньшему количеству edge cases, а значит к более простому и надёжному коду.
В творческом программировании по-прежнему много ограничений: например, когда я делал компонент для выбора городов в своём калькуляторе стоимости жизни, мне захотелось не просто выводить плоский список из почти тысячи городов, а как-то выделить популярные и уже выбранные. Сначала я попробовал в дополнение к полному списку городов передавать в компонент два дополнительных подмножества с уже выбранными и популярными, сделав их отдельными категориями с подзаголовками.
Ограничением стали индексы элементов в списке: для правильной и быстрой отрисовки в виде виртуализированного списка (есть в реакте такой способ ускорить отрисовку, которая тормозит уже на сотнях элементов) и для поддержки скроллинга с клавиатуры компоненту нужен индекс элемента, с которого начинается видимая часть списка. Но объединить надмножество всех городов с подмножествами уже выбранных и популярных, правильно транслировав индексы (локальные внутри каждого подмножества) очевидным образом мне не удалось.
Тогда я поменял подход и решил сортировать список так, чтобы на первом месте были уже выбранные города, потом популярные, а в конце - отсортированные по алфавиту оставшиеся города. Получилось намного проще и лучше. Я даже без каких-либо тестов уверен, что этот код не ломается - потому что доверяю старой-доброй сортировке.
Творческий подход также накладывает свои ограничения из-за выбранной модели, а значит допускает более вольное трактование проблемы и подразумевает более гибкий scope - по определению, он подходит не для всех задач. Например, я был рад отказаться от вывода названий подкатегорий и упростить код, но в более зарегламентированном процессе или при наличии жёстких требований к функциональности это было бы невозможно.
Про третью и четвёртую модальности поговорим в следующем посте, а пока поделитесь мнением в комментариях и отправьте этот пост знакомым и друзьям, которым он может пригодиться и понравиться. Спасибо!
@gromov_com
Я достаточно часто переключаюсь между разными модальностями, или режимами написания кода.
Самая распространённая (и моя самая нелюбимая) - промышленное программирование. В работе программиста слишком много мета-активностей: обсуждения и встречи, код-ревью и изучение чужого кода, скрам-ритуалы и прочие групповые встречи.
В больших компаниях всё ещё хуже: в список добавляются корпоративные тренинги, all-hands встречи, регулярные ревью результатов, часто возведённые в абсолют (в Фейсбуке, например), встречи с руководителями и трескотня бесчисленных чатов. Неудивительно, что многие пишут код всего несколько часов в день - часто в формально нерабочие часы.
Разумеется, для работы компании эффективная коммуникация и обмен информацией исключительно важны, но надо быть весьма специфичного склада характера, чтобы получать удовольствие не от создания чего-то нового из ничего - того, ради чего многие и начинали программировать, - а от участия в процессе.
Многие компании, даже став неповортливыми огромными монстрами, по-прежнему стараются получать результаты как можно эффективнее, практически в режиме стартапа: с короткими итерациями и быстрыми результатами - а значит качество кода и архитектуры, а вместе с ними гордость разработчиков за результат стремятся к нулю.
Следующая, куда больше радующая меня модальность - творческое программирование. В результате такой работы получается хорошо продуманный код, правильно моделирующий проблему (и отчасти реальность - привет, ООП) и поэтому решающий её достаточно оптимальным и очевидным способом. Правильно выбранный подход, в свою очередь, приводит к меньшему количеству edge cases, а значит к более простому и надёжному коду.
В творческом программировании по-прежнему много ограничений: например, когда я делал компонент для выбора городов в своём калькуляторе стоимости жизни, мне захотелось не просто выводить плоский список из почти тысячи городов, а как-то выделить популярные и уже выбранные. Сначала я попробовал в дополнение к полному списку городов передавать в компонент два дополнительных подмножества с уже выбранными и популярными, сделав их отдельными категориями с подзаголовками.
Ограничением стали индексы элементов в списке: для правильной и быстрой отрисовки в виде виртуализированного списка (есть в реакте такой способ ускорить отрисовку, которая тормозит уже на сотнях элементов) и для поддержки скроллинга с клавиатуры компоненту нужен индекс элемента, с которого начинается видимая часть списка. Но объединить надмножество всех городов с подмножествами уже выбранных и популярных, правильно транслировав индексы (локальные внутри каждого подмножества) очевидным образом мне не удалось.
Тогда я поменял подход и решил сортировать список так, чтобы на первом месте были уже выбранные города, потом популярные, а в конце - отсортированные по алфавиту оставшиеся города. Получилось намного проще и лучше. Я даже без каких-либо тестов уверен, что этот код не ломается - потому что доверяю старой-доброй сортировке.
Творческий подход также накладывает свои ограничения из-за выбранной модели, а значит допускает более вольное трактование проблемы и подразумевает более гибкий scope - по определению, он подходит не для всех задач. Например, я был рад отказаться от вывода названий подкатегорий и упростить код, но в более зарегламентированном процессе или при наличии жёстких требований к функциональности это было бы невозможно.
Про третью и четвёртую модальности поговорим в следующем посте, а пока поделитесь мнением в комментариях и отправьте этот пост знакомым и друзьям, которым он может пригодиться и понравиться. Спасибо!
@gromov_com
Четыре модальности написания кода - часть вторая
В прошлом посте я рассказал про промышленное и творческое программирование, а в этом поговорим про библиотечный код и программирование в стартапе.
Написание библиотечного кода, третья модальность, перенимает многие свойства творческого программирования, но обязывает разработчика соблюдать больше условий. Код должен быть производительным и надёжным, а ещё обратно совместимым и следующим принципам defensive programming - учитывать максимально возможное количество edge cases и предсказуемо вести себя (и ломаться) при “мусоре на входе” и прочих странных обстоятельствах: когда входные данные не помещаются в памяти, если операция прервалась в процессе выполнения (транзакции в БД) или кончилось место на диске, когда функции библиотеки вызываются асинхронно или параллельно, и возможны race conditions.
В дополнение ко всему, библиотечный код должен быть полностью покрытым тестами (в том числе странными), хорошо задокументированным, сопровождённым большим количеством примеров и описаниями релизов. Создание и поддержка этих артефактов тоже требует времени и сил.
Написание библиотек - классная, глубоко техническая работа, которая может увлечь, но мне в ней не хватает связи с внешним миром. В концепциях и деталях работы библиотеки легко потеряться и отвлечься от решения стоящих внимания проблем, а требование обратной совместимости и надёжности, особенно после десятка релизов, оставляет совсем немного простора для творчества.
Последняя в моей классификации модальность - программирование в стартапе или попросту говнокодинг. Граница между максимально эффективным и быстрым созданием полезных прототипов и небрежным говнокодингом достаточно условна и задаётся размером компании и ожиданиями к времени жизни и качеству кода.
В стартапе на ранней стадии жизни немного разработчиков и мало кода, который выполняет понятные и, вероятно, бесполезные функции. Скорее всего, существенная часть результатов отправится в мусорное ведро в течение считанных месяцев, если не недель, поэтому разработка в режиме “я его слепила из того, что было” вполне оправдана.
В то время как хорошие разработчики пишут прототипы, чтобы исследовать поведение системы и переписать всё правильно, когда поймут её основные свойства, стартаперы пишут плохой код под давлением обстоятельств: короткие итерации помогают быстрее получить необходимый сигнал от первых пользователей с наименьшими затратами, а дурно пахнущий код легко выкинуть и переписать, когда понадобится.
Другое дело, если большие компании пытаются играть по таким же правилам. Цепочка принятия решений в условиях корпорации слишком длинная, разработчиков намного больше, и у них нет ни желания (все работают за зарплату и повышение), ни шанса сопереживать своим пользователям, потому что служба поддержки сидит в лучшем случае на другом этаже, а в худшем - на другом континенте.
Требования к системе нередко приходят откуда-то сверху, а информация распространяется неравномерно и слишком медленно, чтобы все члены команды поспевали за целями компании и идеями коллег и понимали разрабатываемые системы достаточно хорошо. Процесс разработки очень инертный, а анализ результатов занимает не недели, а месяцы или даже годы - в таких условиях говнокод живёт дольше и доставляет много хлопот. Часто уже новым членам команды, которые не имеют представления о том, как всё начиналось.
Я вполне могу принять необходимость писать код быстро и грязно, когда мотивация находится за пределами зарплатной ведомости - например, в ненулевой вероятности создания своей компании, приносящей пользу клиентам и деньги создателям. Но соглашаться на это в условиях обычной компании - чистое безумие.
Какая модальность ваша любимая и что думаете про такую классификацию? Поделитесь мнением в комментариях, а этим (и прошлым) постом со своими друзьями и знакомыми, которым может быть интересно.
Спасибо!
@gromov_com
В прошлом посте я рассказал про промышленное и творческое программирование, а в этом поговорим про библиотечный код и программирование в стартапе.
Написание библиотечного кода, третья модальность, перенимает многие свойства творческого программирования, но обязывает разработчика соблюдать больше условий. Код должен быть производительным и надёжным, а ещё обратно совместимым и следующим принципам defensive programming - учитывать максимально возможное количество edge cases и предсказуемо вести себя (и ломаться) при “мусоре на входе” и прочих странных обстоятельствах: когда входные данные не помещаются в памяти, если операция прервалась в процессе выполнения (транзакции в БД) или кончилось место на диске, когда функции библиотеки вызываются асинхронно или параллельно, и возможны race conditions.
В дополнение ко всему, библиотечный код должен быть полностью покрытым тестами (в том числе странными), хорошо задокументированным, сопровождённым большим количеством примеров и описаниями релизов. Создание и поддержка этих артефактов тоже требует времени и сил.
Написание библиотек - классная, глубоко техническая работа, которая может увлечь, но мне в ней не хватает связи с внешним миром. В концепциях и деталях работы библиотеки легко потеряться и отвлечься от решения стоящих внимания проблем, а требование обратной совместимости и надёжности, особенно после десятка релизов, оставляет совсем немного простора для творчества.
Последняя в моей классификации модальность - программирование в стартапе или попросту говнокодинг. Граница между максимально эффективным и быстрым созданием полезных прототипов и небрежным говнокодингом достаточно условна и задаётся размером компании и ожиданиями к времени жизни и качеству кода.
В стартапе на ранней стадии жизни немного разработчиков и мало кода, который выполняет понятные и, вероятно, бесполезные функции. Скорее всего, существенная часть результатов отправится в мусорное ведро в течение считанных месяцев, если не недель, поэтому разработка в режиме “я его слепила из того, что было” вполне оправдана.
В то время как хорошие разработчики пишут прототипы, чтобы исследовать поведение системы и переписать всё правильно, когда поймут её основные свойства, стартаперы пишут плохой код под давлением обстоятельств: короткие итерации помогают быстрее получить необходимый сигнал от первых пользователей с наименьшими затратами, а дурно пахнущий код легко выкинуть и переписать, когда понадобится.
Другое дело, если большие компании пытаются играть по таким же правилам. Цепочка принятия решений в условиях корпорации слишком длинная, разработчиков намного больше, и у них нет ни желания (все работают за зарплату и повышение), ни шанса сопереживать своим пользователям, потому что служба поддержки сидит в лучшем случае на другом этаже, а в худшем - на другом континенте.
Требования к системе нередко приходят откуда-то сверху, а информация распространяется неравномерно и слишком медленно, чтобы все члены команды поспевали за целями компании и идеями коллег и понимали разрабатываемые системы достаточно хорошо. Процесс разработки очень инертный, а анализ результатов занимает не недели, а месяцы или даже годы - в таких условиях говнокод живёт дольше и доставляет много хлопот. Часто уже новым членам команды, которые не имеют представления о том, как всё начиналось.
Я вполне могу принять необходимость писать код быстро и грязно, когда мотивация находится за пределами зарплатной ведомости - например, в ненулевой вероятности создания своей компании, приносящей пользу клиентам и деньги создателям. Но соглашаться на это в условиях обычной компании - чистое безумие.
Какая модальность ваша любимая и что думаете про такую классификацию? Поделитесь мнением в комментариях, а этим (и прошлым) постом со своими друзьями и знакомыми, которым может быть интересно.
Спасибо!
@gromov_com