Как повторить путь до сильного программиста, ответы программистов из Avito, Однокласники, Facebook, Amazon, Microsoft и других компаний

Как изменится то как ты программируешь, если ты узнаешь, как стали сильными другие программисты, как они решают задачи, и какие инструменты им помогают?

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

Я не хотел останавливаться на своем окружении и поэтому спрашивал: “кого ты считаешь сильным?”, а потом просил познакомить меня с ними. Такой подход сработал здорово! Мне повезло получить ответы и поговорить лично с ребятами, от мысли пообщаться с которыми у меня был здоровый экстаз.

Хоть в заголовке и фигурируют компании с громкими именами, я не ставил целью спрашивать программистов только из топ компаний. Я получал ценные советы наравне от программистов из компаний, которые известны в регионах.

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

Как читать эту статью

В тексте вы найдете [Мои мысли] курсивом, это места, где я делюсь своими мыслями в дополнение к ответам.

“Цитаты приведены в таком стиле” – Дима Швецов

В квадратных скобках [как эти] я дополняю цитаты своими словами, чтобы смысл был понятен, многие цитаты вырваны из контекста и их сложно передать так, как этого хотел автор цитаты.

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

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

В чем разница между посредственным программистом и сильным?

Сильные программисты начинали программировать рано еще в средней школе. В начале двухтысячных с информацией было туго и нужно было набивать руку, программируя много. Такую историю рассказал Денис Баженов, Дима Федоренко и один разработчик, проработавший в FAANG компаниях

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

“Объем знаний в индустрии растет, а времени больше не становится, и люди в этом не виноваты” – Денис Баженов

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

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

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

Если ты бэкенд разработчик, изучай ОС, знай C/C++, языки, на которых написано большинство системных вещей. По языкам, к примеру, если ты Java разработчик, изучай JVM и стандартную библиотеку языка. Пишешь ООП - пойми ООП. Это формирует ту самую глубину знаний, помогает писать осмысленный код и high performant код. Пользуешься БД - пойди дальше, чем изучение языка запросов, разберись, как они работают внутри. Это поможет в проектировании, знании узких мест и отладке.

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

Любопытство ведет вглубь. Если что-то работает не так, как ты ожидаешь, или тебе просто интересно, как устроена та или иная функция (любопытство на стероидах), ты смотришь в ее исходный код, потом на вызов глубже, еще, дальше с прикладного уровня (application layer) ты опускаешься на уровни ниже. Эти знания дают кругозор, помогающий решать сложные задачи.

Важно владеть паттернами. Вот как объясняет это Антон Киреев из Avito.

“Программирование - это как игра в шахматы. Ты не можешь сесть и начать играть в шахматы, изучив только как двигаются фигуры. Безусловно, найдутся люди, которые смогут это сделать, вот только в большинстве случаев эти люди, умея перемножать огромные числа в уме, не могут даже штаны без помощи надеть. Весь прикол в том, что шахматы - это паттерны, которые вначале твой мозг не будет видеть. Именно поэтому первый год рекомендуется выполнять этюды. Чтобы текущее состояние поля у тебя где-то было на подсознании, на уровне рефлексов. [И тогда ты] мог [бы] спокойно заниматься стратегией. Без практики не появится нейронных связей в мозгу, ты не сможешь свободно видеть и применять паттерн к задаче, которая перед тобой стоит и к коду который ты идешь.”

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

Переход от инженерного мышления к продуктовому очень помогает в эффективности. Надо ставить бизнес во главу угла. Этим наблюдением поделился Руслан Торобаев.

“Выбирать эффективные решения, пусть они не всегда самые лучшие, их быстрее делать и проще выкидывать” – Руслан Торобаев

В разработке больших продуктов часто приходится выкидывать проделанную работу. Разработка через эксперименты и маленькими шагами помогает нивелировать эту проблему.

“Больше экспериментируй, иди маленькими шажками” – Руслан Торобаев

Частый совет сильных программистов - не вестись на хайповые технологии, если ты продуктовый программист. Новые технологии с захватывающими success-историями одинаковы: “взяли топовое железо, новую технологию, получили головокружительный результат”.

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

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

Из опыта Руслана часто бывает так, что прототип, попавший на продакшн, часто работает без изменений месяцами.

Вова Попов, архитектор из Kinaxis, в начале своего пути использовал PHP скрипт с одним классом из 25 строк в течение 2-х лет как бэкенд для Flash проектов.

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

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

Личные жизненные проблемы сразу ведут к просадке на работе. Поэтому баланс в жизни вне работы также важен для карьеры, как и сама работа.

[Мои мысли] Здоровье, отношения, финансовая безопасность - это фундамент для всего остального.

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

“Не надо боятся менять чужой код.” – Руслан Торобаев

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

Уверенность в себе - еще одна психологическая черта сильного программиста, которая отмечает Вова.

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

[Мои мысли] У меня бывают моменты, когда я сомневаюсь, правильное ли решение я принял, такие сомнения отбирают очень много “мысленного топлива”, которое у нас в ограниченном количестве на день.

Чтобы набраться уверенности, пишите проекты. Много проектов. Соберите портфолио и сделайте его публичным. То, что для тебя было несколько ночей программирования, для остальных будет как “вау, это ты написал?” Это эффект публичных портфолио.

[Мои мысли] В первую серьезную компанию я попал благодаря портфолио из одного проекта.

6 из 11 программистов, кто дал ответы к этой статье, по моему мнению, обладают заметной скромностью.

“Я выработал в себе привычку считать себя не умнее остальных, поэтому было много людей, кто меня где-то поправлял, а кто-то давал по шее. Для меня не важно, джун это или Линус Торвальдс. Любой человек может меня чему-то научить.” – Антон Киреев.

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

[Мои мысли] Мы не зарабатываем деньги лично, зато мы можем просадить 460 миллионов долларов за 45 минут. Вот история, как крупнейший трейдер США на рынке акций обанкротился из-за мертвого куска кода (ссылка на англоязычный пост). https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

У сильного программиста есть стек, на котором он решает задачи быстро, так как делал это много раз.

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

Каков путь сильного программиста?

“Делай то, что любишь, люби то, что делаешь” – здравый смысл

[Мои мысли] Ниже множество путей как вырасти в сильного программиста. Некоторые советы противоречат друг другу и это нормально. Нет одного единственного пути. Он у каждого свой. Важно выбрать тот, который будет в удовольствие.

Работа в сфере информационных технологиях [далее ИТ] - это постоянная гонка знаний. У информационных систем, над которыми мы как программисты чаще всего работаем, имеют тенденцию к усложнению, растущими слоями абстракции над абстракциями и интеграцией всего со всем. Решение проблемы в такой индустрии всегда требует больших знаний, чем ты имеешь сейчас. Ты постоянно изучаешь что-то новое.

В поиске чувства самозванца

“Если вы самый умный человек в комнате, то вы не в той комнате, где должны находиться” – Конфуций.

Твоя цель попасть в сильную команду. Когда попадаешь в сильное окружение, оно мотивирует тебя подниматься до уровня окружения.

[Мои мысли] Крутые эксперты рядом - один из основных аспектов в выборе места работы.

“Надо стараться работать с людьми, которые знают больше тебя в какой-то области, смотреть, как они работают и учиться.” – Дима Федоренко.

Если попасть в сильнейшие компании не получается, практикуйся и стань по-настоящему хорош в основах. Стартовые навыки можно получить из ресурсов на YouTube, курсов и крутых open source проектов. [О саморазвитии написано далее].

Избегай коллективы и компании с отравленной атмосферой. Там обучение у коллег будет осложнено.

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

“Новое окружение - это новые знания” – Руслан Торобаев.

Для развития нужна обратная связь. Без обратной связи развиваться сложнее. Если не дают обратную связь – проси.

[Мои мысли] 1:1 - незаменимый инструмент для обмена обратной связи как от лидерский ролей к исполнителям, так и от исполнителей к руководящим ролям.

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

“Сложно достичь успеха в ИТ, если приходите туда за деньгами и модой. Это должно быть призвание.” – Дима Федоренко.

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

“Простой вопрос - вы будете программировать, если за это вам не будут платить? Если нет, то мой путь вам не подойдет” – Дима Федоренко.

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

[Мои мысли] В компаниях поменьше чуть проще, особенно зарубежных. С помощью glassdoor.com и teamblind.com можно получить отзывы от бывших и текущих сотрудников. Подчеркну еще раз, что для больших компаний это подход не работает. В этом случае можно найти контакты текущих сотрудников и пообщаться в неформальной обстановке, узнать, есть ли в компании то, что ты ищешь.

Сильные коллеги там, где сложные задачи

“Нет неразрешимых проблем, есть неприятные решения.” – Эрик Берн

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

Путь в сильные программисты лежит через сложные задачи. Зачастую это вторая составляющая сильных коллег. Сильные коллеги там, где сложные задачи.

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

[Мои мысли] Я замечал, как сильно росли мои коллеги и я, когда попадали в условия горящих сроков на не поддающейся задаче. Тот случай, когда у тебя нет выхода кроме как научиться решать задачу здесь и сейчас. В такие моменты ты включаешься по-настоящему на полную. И когда задача завершена, ты ощущаешь, что на голову сильнее вчерашнего себя.

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

[Мои мысли] Не стоит ожидать, что каждая задача будет сложной и интересной. Заниматься рутиной нужно и придется. В твоих силах делать задачу интереснее. Ты можешь делать рутинные задачи на скорость или попробовать ее автоматизировать, решить “раз и на всегда”. Оттачивай на рутине любой другой hard или soft навык, как это делают спортсмены.

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

[Мои мысли] В долгосрочной перспективе интересная работа может оказаться важнее прибавки к заработной плате сейчас.

Саморазвитие

“Без крутых коллег сложно заниматься саморазвитием” – Руслан Торобаев

Окружай себя людьми, которые умнее тебя вне работы.

Open source - самый доступный источник самых лучших программистов, которые “покажут” свой код, свои трюки и дадут обратную связь на твой код. Не использовать эту возможность при отсутствии сильных коллег нельзя.

[Мои мысли] Open source - это источник знаний и новых знакомств.

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

“Любое решение - это паттерн, который решался мной в течении 11 лет и который пополнялся знаниями по запросам наподобие “как устроен Гугл”, “как работает это, как работает то.” – Антон Киреев.

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

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

[Мои мысли] Он был одним из тех, кто топил за Node.JS до ее 1-ой версии и использовал в продакшене Vue.js 7 лет назад, когда фреймворк еще не был так популярен. Сегодня он эксперт в этих двух технологиях.

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

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

Развивать не только hard, но и soft навыки.

“Хороший программист - на 80% не программист” – Денис Баженов.

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

“Можно смотреть табы [табулатура – нотация аккордов для гитаристов] чужих крутых песен как код крутых программистов и извлекать паттерны, оттачивая их исполнение, повторяя их в своей работе. Но, повторяя “песни” чужих исполнителей, ты не сможешь сыграть испанскую пьесу. Чтобы сыграть что-то такое, тебе нужно, чтобы кто-то научил тебя правильно сидеть, правильному положению рук, правильному зажиму. Почему это важно? Потому что при правильной технике будешь лучше извлекать звук и меньше уставать, мышцы будут меньше загружены.”

Источники саморазвития Вадима Цесько, разработчика из Одноклассников:

  • академические статьи;
  • профессиональные книги;
  • доклады с тематических конференций;
  • регулярные митапы и user group;
  • онлайн-курсы;
  • Open source проекты, баги/фичи, code review;

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

В интервью George Hotz, разработавший iOS jailbreaks и работающий над проектом беспилотных авто comma.ai, сказал: “ты никогда не научишься программировать, посмотрев видео, которое называется “learn programming””.

“Книги которые тебе приоткроют “тайну всего мира” нет. Все книги которые я читал дают максимум 60% нужной информации.” – Антон Киреев

[Мои мысли] остальное добывается из личного опыта и опыта коллег

Из Ютуб-каналов Антон подписан на:

По вебу - StackOverflow, Reddit. Частных блогов очень много и их нужно хорошенько фильтровать.

Для развития в глубь технологического стека Антон Киреев рекомендует книги Эндрю Таненбаума.

Чтение документации - еще один источник знаний, там можно найти информацию, что как устроено и работает.

Учи основы информатики (Computer Science), из самых рекомендуемых ресурсов это leetcode.com.

Руслан согласен, что самостоятельное обучение возможно, но считает, что Университет будет более удачным выбором. В программировании нужна хорошая база: высшая математика, комбинаторика, алгебра, ОС, сети, знание железа. Без формального образования получить эти знания сложнее. Это не мешает делать сайты, но отсутствие этих знаний ограничивает тебя.

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

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

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

[Мои мысли] Самое сложное в предыдущем совете - это действительно заметить, когда ты задет и закрываешься от критики. В этот момент мозг работает нерационально, и ты играешь в защиту. Научиться ловить такие моменты и воспринимать советы или искать бревно в себе - еще один важный soft навык. Один из моих инструментов для самоанализа - это вечерние записи “обзор дня” в дневник. Этот приемом я перенял у стоика, философа, и Римского государственного деятеля Луция Сенеки.

Денис Баженов видит большой плюс, когда программисты знают про системное администрирование, и советует почитать блог Linux Performance от Netflix Senior Performance Architect Brendan Gregg.

Для Java разработчиков отличный ресурс советует Руслан Торобаев - shipilev.net

Собственные проекты

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

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

Вова Попов брался за любое проекты, никогда не говорил “нет” возможности поработать. Куча проектов за 0 рублей, за опыт, интерес, референсы и знакомства.

“У меня постоянно было куча проектов одновременно. Я был голодный до проектов.” – Вова Попов.

Работа над разными проектами помогла Вове набить руку. Начни 25 раз с нуля и ты доведешь этот процесс до автоматизма.

[Мои мысли] Четыре года назад мы с ним работали вместе и он искал библиотеку для решения задачи. “Дима, смотри… хорошо написано… вот тут умно… тут круто… хм вот тут бы я написал по-другому, но норм… интересно, кто автор?” Он открывает конфигурационный файл проекта, скроллит файл вниз и видит, что он автор.

Вадим Цесько из Одноклассников дает совет писать just for fun свою реализацию различных слоев технологического стека: загрузчик, ядро, сеть, структуры данных, библиотеку и фреймворк. Это даст лучшее понимание всего стека, на который программисты опираются каждый день.

Учи, чтобы научиться

“Если вы что-то не можете объяснить 6-летнему ребёнку, вы сами этого не понимаете.” – Альберт Эйнштейн

Как можно учить других:

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

Все это поможет доразобраться в деталях, стать спецом в данной области.

[Мои мысли] Здорово, если тебе нравится отвечать на вопросы, объяснять, выступать в роли наставника для других. У тебя наверняка есть склонность к определенной части проекта, любовь к определенной библиотеке, инструменту, подходу, и чему угодно из огромной вселенной навыков и знаний в программировании. Используй эту тему, о которой ты готов говорить часами, чтобы стать экспертом среди коллег или сообщества. Обучая других, ты учишься. Глубина понимания вопроса, которую ты разъясняешь, увеличивается с каждым осознанным объяснением.

О наставниках

“Когда ученик готов появиться и учитель. Когда ученик по настоящему готов… учитель исчезнет.” – Дао дэ цзин

Наставник способен превратить годы самообучения в недели, а месяцы - в дни.

Высшие образовательные учреждения не всегда дают нужные знания. Вова Попов в университете прикладных знаний не получил. Он нашел человека, знавшего интересующую его технологию лучше всех в России. Денис Муравьев проводил интенсив “Advanced Flash programming”, на котором дизайнеры уже после нескольких дней писали код на ActionScript [родственник ECMAScript].

“Когда мне объяснили что такое классы, я не понял, зачем они нужны, можно же писать процедуры” – Вова Попов.

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

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

[Мои мысли] Наставник может и не знать, что он твой наставник. Читая его блог, твиттер, слушая подкасты и просматривая скринкасты и видео на ютуб, ты можешь много перенять у программиста. Вова Попов и я таким образом перенял владение популярным раньше редактором TextMate и научились разрабатывать на фреймворке Ruby on Rails. Выбери 2-3 самых сильных в своей области и поглощай весь контент, что они публикуют.

Денис Баженов сам является наставником для молодых коллег. Он поделился тем, на что нужно обращать внимание при выборе наставника:

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

И как быть желанным учеником:

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

Как быть, если только начинаешь?

Начинающие программисты должны набивать руку как можно больше программируя. Уметь следовать за руководителем.

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

На следующем этапе важно расширять кругозор. Code review, git, debugging, DevOps, problem solving [читай о problem solving ниже]. Развиваясь по этим вопросам, ты становишься самодостаточным.

Начинающим программистам поможет раскрыть свой потенциал:

  • стажировка в командах со сложными задачами и опытными коллегами;
  • драйв;
  • собственные идеи;
  • восприимчивость к критике;
  • умение быть ведомым.

Как находить время на все это?

Никто не отменяет упорного труда.

“Порог входа в программирование и в целом в ИТ большой. 5-10 лет надо усиленно работать, чтобы стать специалистом средней руки. Надо устраивать себе периодически потогонки” - Дима Федоренко.
“Направлять всё свободное время на саморазвитие” – Вадим Цесько.

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

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

“Не знаю, оно само” – Антон Киреев.

Инструменты сильных программистов

Дима Федоренко использует “Getting Things Done” практику.

Инвестируйте время в изучение использования дебаггеров. Дебаггеры очень помогают быстро понять, что происходит не так. Это поможет в решении багов и в разработке, когда код перестал работать так, как вы этого хотели.

Аналитическая отладка [термин от ребят из JetBrains]. Это способ отбросить дебаггер и подумать, что пошло не так. Плюс такого подхода в том, что с его помощью с большей вероятностью находятся источники проблемы, а не ее симптомы, у вас растет общее понимание проекта, вы можете найти сопутствующие баги. Недостаток аналитического дебаггинга в том, что он в разы медленнее использования отладчиков.

Инструменты отладки ОС, которые использует Денис Баженов:

  • strace
  • ltrace
  • pidstat
  • tcpdump
  • linux sar
  • lsof
  • vmstat

Их плюс в том, что они позволяют понять, что происходит с приложением независимо от того, на каком языке оно написано.

Решай задачи как ПРО

“Проблемы все разные но все они сводятся к одинаковым задачам” – Программист из JetBrains.

В решении задач секретов нет. Используйте теорию принятия решений и стандартный подход к решению задач. Замечай паттерны, чем быстрее ты определишь их, тем быстрее у тебя будет получаться решать задачи.

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

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

— Дима, а сделай нам вот здесь кнопку зеленую.

— Нет, сперва опишите, какая у вас проблема? Зачем эта кнопка? Что будет, если ее не сделать?

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

“Нехватка требований и ТЗ - постоянная проблема, с которой я сталкиваюсь.” – Дима Федоренко.

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

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

“От маленьких библиотек больше пользы, чем от одной большой. Идеальная библиотека - это библиотека, которую ты можешь написать за 4 часа и забыть про нее.” – Вова Попов.

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

Учитывай компромиссы между различными решениями, отдавая предпочтения простым решениям.

Если делать все же надо, то старайся собрать минимально рабочий прототип. Делай код из говна и водорослей [Приморский вариант] в сжатые сроки, чтобы посмотреть, как работает фича, и получить по ней обратную связь от заказчика и пользователей.

Ищи самый короткий путь к решению.

“Когда я был неопытным, мне хотелось всё сделать в лучшем виде и я начинал, как мне казалось, “строить мост” основательно с одного конца. Но со временем я понял, что такие мосты другим концом упираются не туда, куда надо. Поэтому с опытом сначала “протаптываю тропинку”, делая хоть какой-то рабочий прототип, потом, когда, и если это добро хоть как-то работает, оно начинает обрастать мясом.” – Программист Одноклассников.

[Мои мысли] Когда у тебя есть готовое решение, на тебя уже не давят сроки. Тут ты можешь определиться что-то улучшить, получить обратную связь по коду и по работе реализованного функционала. Попытки сразу сделать супер-круто для меня часто заканчивались не попаданием в сроки.

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

Используйте аналитику, это пригодится и для бизнеса, мониторинга, отладки.

Когда не знаешь, как решить проблему, сделай максимально простое решение. Вплоть до if a = some_value then return expected_result. Это нужно, чтобы начать. Как будет простейшее решение, реши следующий шаг из требований в задаче. Подолжай этот процесс пока не решишь всю задачу.

Часто задачи, которые ты не знаешь как решать, очевидно решаемые. Решение для них добывается интенсивным поиском в интернете, в статьях и академических публикациях [white papers]. Минус этого подхода – он занимает много времени, дни и недели.

“Неберущиеся” задачи можно отложить на пару часов или до завтра. Засыпай с задачей, часто идея приходит по утру или в душе.

[Мои мысли] это связано с тем, что наш мозг работает в двух режимах: сфокусированный и рассеянный. Сфокусированный режим позволяет нам держать больше и более сложные детали в голове. Это больше про глубину знаний. Тогда как рассеянный режим - это работа креативная, использующая всю широту наших знаний. Новые идеи приходят как раз в рассеянном режиме. Это объясняет устойчивое мнение, что идеи приходят в душе. Для меня расслабиться и отправить вопрос в фоновый режим работает почти всегда, через 5-20 минут у меня появляется отличная идея.

Подробным списком о подходе к problem solving поделился Вадим Цесько:

  1. Сбор всех требований и вводных, погружение в предметную область;
  2. Тщательное документирование через Design Doc или SRS для последующей ретроспекции, поддержки и развития системы;
  3. Поиск и общение с коллегами с релевантным опытом с целью сбора исчерпывающего множества альтернатив;
  4. Изучение существующих решений на рынке, академических статей, если релевантно;
  5. Анализ достоинств и недостатков каждого из вариантов решения, выбор решения;
  6. Итеративный Design Review и сбор мнений у более опытных коллег;
  7. Ключевое: не замыкаться и не зацикливаться, проактивно собирать мнения, быть открытым и толерантным к критике, честно взвешивать достоинства и недостатки, опираться на логику, рациональность и данные.

Советы от Дениса Баженов:

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

Руслан Торобаев рассказывает о том, как реализовывать принятые решения:

  • Пиши модульные тесты, если задача большая и держать все ее части в голове невозможно.
  • В задачах на интеграцию используй больше специальных логов. Все покрыть тестами в интеграции невозможно.
  • Для маленьких компонентов полезен test-driven developmet подход. Он помогает находить огрехи в интерфейсе. Если компонент не получается протестировать, сразу понимаешь, что нужно менять интерфейс.

Важно уметь решать блоки в работе над задачей. Вот куда нужно обратиться и что сделать:

  1. Внутренняя база знаний, документация по продукту;
  2. Помощь коллег;
  3. StackOverflow, каналы сообществ в Slack, Discord, user groups, issues в репозитории библиотеки или продукта, каналы продукта;
  4. Последний способ, хотя его можно применять совместно с предыдущими пунктами, это заглянуть в исходный код. Можно скачать Docker image, запустить отладку с breakpoint-ами и посмотреть, как продукт работает изнутри.

Это еще не все…

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

Эта страница будет обновляться со временем.

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

Герои этой статьи

Огромное спасибо ребятам за ответы и интересное общение.

  • Антон Киреев (Anton Kireev), программист, Avito
  • Вадим Цесько (Vadim Tsesko), Одноклассники, преподает в Технополис
  • Вова Попов (Vlad Popov), архитектор, Kinaxis
  • Денис Баженов, техлид, Farpost
  • Дима Федоренко, CTO, 100sp.ru
  • Рома Дмитриенко, техлид, drom.ru
  • Руслан Торобаев, тимлид, Одноклассники

Попросившие остаться неизвестными:

  • один программист из Одноклассников
  • один программист из JetBrains
  • один программист из Facebook
  • один ex. Amazon, ex. Microsoft программист