Сразу в продакшн

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

Простой пример - любое объектное хранилище, например Google Storage или Amazon S3. У обоих есть CLI-тулзы, с помощью которых деплой статического файла действительно выполняется одной командой. Второй настраивается edge-кэш - и ваш файлик готов к миллионам скачиваний.

А как же приложения посложнее статики? Когда мы говорим про рабочее окружение, в CI/CD-инфраструктуру вкладываются огромные силы и средства, и деплои для разработчиков, как правило, просты и прозрачны. Смёржил свой пул-реквест в master, и погнали. А под капотом: несколько окружений, тысячи тестов, инкрементальные выкладки и A/B-тесты, миграции схемы БД и данных.

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

А вот в сайд-проектах всё совсем по-другому, и помогать вам некому. Инструменты автоматизации можно либо взять существующие (GitHub Actions, например), либо сделать самому. Какой бы подход вы ни выбрали, постарайтесь сделать так, чтобы ваш код попадал в продакшн максимально просто и быстро. Это увеличит шансы вашего проекта быть запущенным и позволит вам не прокрастинировать из-за очередной хитрой выкладки, а делать что-то полезное.

Первое, что я делаю в своих проектах - это автоматизация настройки серверов и деплоя. После серии экспериментов с Google Cloud и их встроенными инструментами, я ушёл на DigitalOcean и "ручную" настройку через Ansible. Для моих миниатюрных проектов получается и дешевле в рантайме, и не сложнее, а скорее более гибко и надёжно, чем с гуглом.

Когда деплой автоматизирован, разработку я веду в 2 окружениях параллельно: локальном, где я пишу код, и продакшене, куда попадает каждый комит в master. Тестирования, которое могло бы заблокировать выкладку, у меня конечно же нет - я не фейсбук для таких мер. Из тестов - только юнит-тесты на какие-то критические и непонятные куски кода. Для сайта, когда он будет готов, я наверное добавлю интеграционное тестирование для проверки наличия страниц и корректности кэширования, но тоже в продакшене.

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

FizzBuzz Enterprise Edition

Уверен, что вы слышали про FizzBuzz - простейшую задачку для собеседований, которую, по слухам, проваливает немалое количество кандидатов, стремящихся в тот самый кровавый энтерпрайз.

Так вот, есть даже целый почти соревновательный жанр, где разные авторы конкурируют за самую эзотерическую реализацию нехитрого алгоритма. Лучшее решение из увиденных мной пока написано на джаве: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

На скриншоте только один из сотен классов - покопайтесь в репозитории для вдохновения! Можно даже пару-тройку шаблонов проектирования по нему выучить 😉

Как я целеполаганием прокрастинацию победил

Полгода назад, занимаясь Quiken, я активно фигачил. Практически каждый вечер садился и писал код, переписывал код, настраивал деплои, фоновые таски, экспериментировал с дизайном и UX, рисовал логотип, промо-картинки, писал описания в Chrome Store. И так три месяца подряд. Это было непривычно: мне редко удавалось настолько сконцентрированно работать над чем-то "своим", не считая разве что литкода и подготовки к вступительным по математике.

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

Когда активная работа над Quiken завершилась, я взялся за новый сайт. Долго думал, зачем он мне. Увязывал в одну стратегию телеграм, длинные статьи и блогинг; публикации на других сайтах и тактики продвижения; съёмки видео. Пришёл к определённым решениям по технологиям, взялся за прототипы, проверил и подтвердил жизнеспособность всех идей. Всё шло хорошо.

А потом на полной скорости влетел лбом в уже ставшую непривычной стену прокрастинации.

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

Неприятнее всего, что подобный режим, когда много запланировал, а потом только думаешь и почти ничего не делаешь, угнетает психологически. Вроде бы и цели есть, и всё понятно - но ничего не получается. Несложно попасть в downward spiral (это как по-русски?) и утонуть в море вины, жалости к себе и отвращения к работе.

Побарахтавшись чуть-чуть, я стал выплывать. Сначала вернулся к выработанному принципу "деплоить в продакшн сразу же": настроил Ansible, серверы на Digital Ocean, миграции - чтобы каждый комит в master одной командой релизить на живой сайт. Это немного помогло, так как я взялся за работу, но код самого сайта я всё равно не писал. Прокрастинация не уходила.

Тогда я заподозрил целеполагание. Как и многие из вас, я привык ставить цели в контексте работы. Иногда организуя их в иерархию objectives and key results, иногда опираясь на SMART-методологию: чтобы был срок, чтобы было точно понятно, что делать - а потом оценивать результат по заранее определённой шкале. И, кажется, эта привычка сыграла со мной злую шутку.

У меня не так много времени, чтобы заниматься своими проектами; внимания, силы воли и даже желания часто тоже не хватает. И получается, что я не достигал практически ни одной из своих целей, прикреплённых к календарю и выраженных количественно. От этого пропадает уверенность в себе и адекватности целей, и приходит тот самый ступор, заставляющий смотреть сериалы даже тогда, когда отдыхать уже не хочется.

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

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

В эту пятницу в 17 часов по Москве поговорим про собеседования в большие компании с ребятами из g-mate. Я расскажу про свой опыт с Яндексом, Toptal и Facebook и постараюсь дать рекомендации, которые вы сразу сможете применить на следующем собеседовании. Вебинар будет длиться всего час, так что плотность информации будет высокой. Регистрируйтесь!

Ещё я давно хотел сделать форму для вопросов и актуальных тем, чтобы у канала была более широкая повестка. Вот она: предложить тему для обсуждения.

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

Нашёл классный ресурс с “дорожными картами” для разработчиков: https://roadmap.sh/
Особенно полезно и интересно будет тем, кто только начинает или недавно начал, либо тем, кто меняет специализацию. Конечно, это не полная энциклопедия всех возможных навыков (кайф начинается, когда совмещаются специализации - например, backend и devops), но вам наверняка будет интересно сравнить свои знания с commmunity-driven эталоном.

Как разработчику успешно пройти собеседования в FAANG

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

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

📝 Делайте резюме под каждую позицию. Упоминайте только релевантный опыт, а для позиций уровня senior и выше описывайте не только свои достижения в разработке, но и в организации командной работы и найме, достижении бизнес-целей.

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

👩‍💻 Подготовьте связный рассказ о себе и своём опыте. Он точно пригодится на поведенческих интервью, а сокращённая версия с примерами успешных проектов и вашими пожеланиями к новой работе - для вводного рассказа о себе на каждой секции. Репетируйте вслух и с диктофоном.

🦾 Отведите несколько месяцев на подготовку к алгоритмическим задачам. Прорешайте не меньше 30-50 задач на Leetcode по разным темам, найдите или придумайте обобщённый алгоритм решения задач и придерживайтесь его. Старайтесь начинать писать код только когда алгоритм решения задачи известен, включая edge-кейсы и его сложность.

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

⚙️ На system design интервью обозначьте общую архитектуру решения и постарайтесь углубиться в область, в которой вы разбираетесь лучше всего. Ведите себя как техлид, уточняющий требования у заказчика, и двигайтесь от общего к частному. Держите в голове план решения задачи и следите за временем.

🤝 Для позиций высокого уровня ваши софт-скиллы важнее, чем умение писать код. Прокачивайте умение работать в команде - обсуждать, спорить, договариваться. Учитесь презентовать и продавать свои идеи, быть услышанным, принимать чужую точку зрения. Развивайте эмпатию, не поддавайтесь эмоциям и учитесь ладить с другими и собой.

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

💰 Собеседуйтесь в несколько компаний и старайтесь получить несколько оферов. Это поможет торговаться (в пределах рынка и вилки зарплат на данной позиции) и чувствовать себя спокойнее. Будьте открыты к предложениям рекрутеров, держите их в курсе процесса и сообщайте о получении других оферов.

🤯 Будьте готовы к отказам и не принимайте их слишком лично. Несмотря на стремление объективно оценить каждого кандидата, иногда процесс даёт сбой - и вам попадается собеседующий не в настроении или неудачная задача. Крупные компании придерживаются правила "лучше не нанять хорошего разработчика, чем нанять плохого", поэтому иногда отказывают даже лучшим.

Ну и напоследок: не рвитесь исключительно в FAANG только ради строчки в резюме. Лучше оказаться на своём месте в небольшой компании, делать что-то важное, развиваться и иметь слово в принятии решений, чем быть винтиком в большом корпоративном механизме. Удачи!

#вслух

Все мы в существенной степени "продукт среды". Например, я после 9 класса думал не как закончить 10-11 класс получше и поступить в хороший университет, а о том, как бы побыстрее сбежать из школы и начать наконец зарабатывать. Это в 13-14 лет-то! Среда была такая - вечная нужда во всём, привычка выживать. Ну и пошёл настраивать компьютеры, барыжил железками на радиорынке.

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

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

А сегодня? Насколько же круто, должно быть, живётся молодёжи (особенно в пандемию, ха-ха - можно вообще из дома не выходить). В 2020-м нет особенной разницы, живёшь ты в Москве, Лос-Анджелесе или под Волгоградом - при наличии интернета есть возможность находить в сети интересных именно тебе людей, занятия и информацию.

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

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

Не боги горшки обжигают

Классная фраза из обсуждения к статье, написанной по мотивам нашего с Лёшей вебинара полторы недели назад. Читатель отметил, что код “выпускника” из какого-то техногиганта его вообще не впечатлил. А мне кажется, это вполне логично. Вот мой комментарий:

«Разумеется, в фейсбуках работают обычные люди. Чаще всего они заинтересованные, целеустремлённые и продуктивные (система мотивации "выживает" других, как мне кажется), но далеко не обязательно лучшие инженеры.

Более того, сила техногигантов, на мой взгляд, не в их крутейшем коде (хотя и в нём тоже), а в размере (рынка, прибыли, сотрудников). Гипотетически, я бы нанимал как можно больше людей, чтобы проверять как можно больше идей (на микро- и макро-уровнях, внутри существующих продуктов и как совершенно новые инициативы) — ведь всё равно никто не знает что делать. А тут уже относительно абстрактный показатель качества или чистоты кода не слишком важен — вероятно, код будет выкинут, либо, если идея выстрелит, его потом десять лет будут рефакторить уже другие люди.»

Как обычно, в комментариях интереснее, чем в статье: https://habr.com/ru/company/gms/blog/526366/#comments-list

⏱ Программист и дедлайн

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

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

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

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

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

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

Как дела со сроками обстоят у вас в проекте?

Наткнулся на классную рассылку “Career Advice for Tech Professionals”. Например:

- Как спланировать первый год работы, чтобы произвести хорошее впечатление
- Когда пора уходить с работы

Я сам только что подписался, но тематика и подача (с симпатичными графиками) мне уже нравится. Если читаете на английском, рекомендую.

Если вы ищите, искали или собираетесь искать удалённую работу разработчиком в зарубежной компании, и у вас есть какие-то вопросы, напишите в личку @oleggromov - с радостью поговорю о вашем опыте и попробую помочь.

А если вы вдруг не читали мои статьи про поиски работы, вот они:
- Как найти удалённую работу за доллары
- Как пройти собеседования на удалёнку за рубеж
- Как торговаться на собеседованиях

Объясню, почему спрашиваю: я сделал Quiken, расширение для хрома, которое помогает учить английский. Практически сразу после публикации в сторе, гугл распубликовал его, потому что у меня нет странички privacy policy. Я её сделаю и обязательно опубликую расширение снова, а сейчас любопытно узнать, нужно ли поддержать ещё какие-то браузеры.

А вообще расширения для хрома - это как телеграм-боты. Их легко делать в одиночку: можно придумать кучу функций, где вообще не нужен бэкенд, а данные можно хранить в Web Storage или IndexedDB прям на клиенте.

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

Владение кодом

В прошлом гостевом посте Виктор давал советы о том, как пройти собеседования в FAANG и другие крупные компании. А что будет после принятия офера? Как преуспеть в корпорации и построить успешную карьеру разработчика?
Придётся упорно трудиться, прокачивать навыки коммуникации, учиться понимать продукт и его пользователей. И конечно, писать понятный, поддерживаемый и надёжный код. Но не только 😜

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

Я работаю в Фейсбуке в Лондоне. До этого — Toptal, Klarna, Яндекс.
Несмотря на очевидную специализацию, каждый день мне приходится взаимодействовать с разными системами, написанными на TypeScript, React, Electron, CG/SQL, C++, Hack/PHP. Кроме использования совершенно разных платформ и языков, нужно хотя бы поверхностно разобраться со всеми компонентами стека, а ещё лучше — понять архитектуру всей системы и детали реализации.

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

Раз так, почему крупные компании не поощряют strong code ownership, когда за развитие и надёжность каждого модуля отвечает отдельный человек? Разработчики были бы счастливы, код был бы чист, а техдолг канул бы в небытие.

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

Можно подобрать и исключения. Например, библиотечный код: важные для архитектуры сервисы и модули, которые обычно создаются и поддерживаются отдельными командами, но не конкретными людьми. По Фаулеру, это не единоличное владение кодом, а скорее weak code ownership, когда за систему и код отвечает группа разработчиков.

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

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

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

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

Главный навык
Получается, главный навык программиста в современной крупной компании с shared code ownership — не просто писать понятный, поддерживаемый и надёжный код, но и обязательно уметь делать это внутри любой системы, даже той, которую он видит впервые. А свой код проектировать максимально очевидным образом, чтобы будущие изменения минимально влияли на архитектуру и непротиворечивость.

А как организовано владение кодом у вас в проекте? Поделитесь в комментариях.

Это гостевой пост на канале. Если вы тоже хотите поделиться опытом — напишите мне в @winterview_contact_bot

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

Недавно наткнулся на список русскоязычных подкастов про IT и был приятно удивлён количеством 🙂 Что-то слушаете уже? Посоветуйте.

Самые интересные посты с апреля по декабрь 2020

Пока собирал тексты, которые буду публиковать на сайте, подумал, что вы могли что-то пропустить, и собрал всё самое интересное в список.

1. Почему программистом быть хорошо
2. Случай на удалёнке
3. Из офиса в океан
4. Почему быть программистом — отстой
5. Вслух: сложная штука этот софт
6. Я не смотрел «Кремниевую Долину» Дудя
7. Траектория и риски в карьере и вторая часть текста
8. Две недели без кофеина ☕️
9. Месяц без кофеина
10. Проклятие знания наоборот
11. Move Fast and Break Things 🤯
12. Я променял прекрасные статичные сайты на Django-монстра 😱
13. Про мотивацию и impact в Фейсбуке
14. Зачем программисту копаться в мозгах
15. Сразу в продакшн
16. Как я целеполаганием прокрастинацию победил
17. Как разработчику пройти собеседования в FAANG
18. Вслух: все мы продукт среды
19. Программист и дедлайн
20. Code ownership и главный навык разработчика

Поделитесь ссылкой на этот пост с друзьями, если какая-то тема кажется вам интересной. Хорошего воскресенья!