Каков путь к тому, чтобы стать сильным программистом? Ответы программистов из Facebook, Amazon, Microsoft и других.
Первоначально опубликовано на https://dmitryshvetsov.com 25 марта 2021 г.
Как изменилось бы ваше программирование, если бы вы могли узнать, как другие программисты стали сильными, как они решают проблемы и какие инструменты используют?
Для меня все началось с идеи унаследовать опыт программистов моего круга. Я спросил своих друзей и бывших коллег, кого они считают сильными программистами, затем составил список, подготовил несколько вопросов и начал задавать!
Я не хотел ограничивать себя этим кругом, поэтому включил вопрос «каких программистов вы считаете «сильными»?», а затем попросил их познакомить меня с этими программистами. Этот подход сработал блестяще! Мне посчастливилось получить ответы и лично поговорить с людьми, с которыми я всегда мечтал поговорить.
Хотя в заголовке указаны компании с громкими именами, я не ставил задачу спрашивать программистов только из известных «топовых» компаний. Я обнаружил, что ценные советы исходили и от людей, работающих в региональных компаниях.
На этой странице вы найдете некоторые редкие крупицы мудрости, а также приземленные вещи, которые делают сильного программиста сильным.
Как читать эту статью
В тексте вы найдете [Мои мысли], выделенные курсивом. Это места, где я делюсь своими мыслями в дополнение к ответам.
«Цитаты даны в таком стиле» — Дмитрий Швецов
В квадратных скобках [вроде этих] цитаты дополняю своими словами, чтобы смысл был ясен. Многие цитаты, вырванные из контекста, трудно понять так, как задумал автор.
Остальной текст — это дистиллированные ответы и размышления героев этой статьи. В большинстве случаев я использовал исходные слова, и моя задача здесь состоит только в том, чтобы обобщить и выделить самое важное.
Поэтому хочу сказать огромное спасибо всем, кто согласился поделиться своим путем в программировании. Их список находится в самом конце этой статьи. Некоторые пожелали остаться неизвестными.
Чем отличается посредственный программист от сильного?
Сильные программисты начинали рано в старшей школе. Двадцать лет назад информации не хватало, и нужно было много программировать, чтобы стать мастером. Так было с Денисом Баженовым, Дмитрием Федоренко и еще одним разработчиком, работавшим в компаниях FAANG.
Сложность современной разработки такова, что сейчас инструментарий разработчика огромен и продолжает расти и усложняться. Нужно многое знать.
«Объем знаний в отрасли растет, но время у людей остается в наличии, и это не их вина» — Денис Баженов
Сильные программисты любят копаться в языке программирования глубже в платформу и в аппаратное обеспечение, разбирая код по частям, опускаясь все ниже и ниже по уровням абстракции, от уровня программного обеспечения к аппаратному обеспечению.
Когда программа работает не так, как ожидалось (а это происходит постоянно), возможность отладки позволяет двигаться с постоянной скоростью, несмотря на постоянную тенденцию усложнения систем.
Когда программисту необходимо посмотреть на программу не с точки зрения программиста, а с точки зрения языка, возможность использования отладчика с одной стороны, и операционной системы и средств диагностики с другой рука будет незаменима. Это позволит вам увидеть общую картину, например, какие файлы открыты, что происходит в памяти, что происходит в ЦП и какие пакеты перемещаются по сети. Знание DevOps помогает в этом отношении.
Если вы бэкэнд-разработчик, изучите операционные системы! Познакомьтесь с языками C и C++, на которых написано большинство системных приложений. Если вы разработчик Java, изучите JVM и стандартную библиотеку. Если вы пишете ООП, убедитесь, что вы понимаете ООП. Это формирует глубокую глубину знаний и помогает писать осмысленный и высокопроизводительный код. Если вы используете базу данных, не ограничивайтесь изучением ее языка запросов; понять, как это работает внутри. Это поможет в проектировании, выявлении узких мест и отладке.
Сильные программисты не принимают факты как должное. Они задают вопросы «почему это так?» Хорошо, если есть коллега, у которого есть ответ, но его отсутствие не останавливает сильного программиста, которым движет любопытство.
Любопытство ведет глубже. Если что-то работает не так, как вы ожидаете, или вам просто интересно, как работает та или иная функция, вы заглядываете в ее исходный код, затем углубляетесь, еще дальше от прикладного уровня, спускаясь на уровень ниже. Эти знания дают перспективу, помогающую решать сложные проблемы.
Важно уметь работать с узорами. Вот как это объясняет Антон Киреев из Авито.
«Программирование похоже на игру в шахматы. Вы не можете сесть и начать играть в шахматы, изучая только то, как ходят фигуры. Конечно, найдутся люди, которые смогут это сделать, но в большинстве случаев это люди, которые могут умножать в уме огромные числа, но не могут без посторонней помощи даже штаны надеть. Самое смешное, что шахматы — это шаблоны, которые ваш мозг сначала не увидит. Вот почему в первый год рекомендуется начинать с небольших упражнений, а не с полной игры, чтобы текущее состояние игры просачивалось в ваше подсознание, а ходы становились рефлексами. Тогда вы сможете с легкостью заниматься стратегией. Без практики в мозгу не будут развиваться нейронные связи, и вы не сможете свободно видеть и применять шаблоны к задаче, которая стоит перед вами, и к коду, который вы видите».
Сильные программисты отдают приоритет бизнесу, а не коду, и это меняет их подход к решению проблем и выбору технологий.
Переход от инженерного мышления к продуктовому — это шаг к повышению эффективности. Во главу угла надо ставить бизнес, — объясняет Руслан Торобаев из ok.ru.
«Выбирайте эффективные решения. Даже если они не всегда самые лучшие, их быстрее сделать и легче выбросить», — Руслан Торобаев.
При разработке больших продуктов часто приходится выбрасывать свою работу. Развитие путем экспериментов и небольших шагов помогает свести на нет эту проблему.
«Экспериментируйте больше — идите маленькими шагами» — Руслан Торобаев
Частый совет от сильных программистов — не увлекаться «хайповыми» технологиями, если вы программируете продукты. Новые технологии с захватывающими историями успеха часто одинаковы: «взяли топовое железо, новые технологии и получили головокружительный результат».
Истории сбоев гораздо интереснее, говорит Руслан, так как позволяют узнать, где технологию нельзя применить, в каких случаях она не решает проблему и какие у нее есть баги.
Сильные программисты прагматичны. Не всегда нужно элегантное решение, о котором написано в книгах или о котором говорят на конференциях.
По опыту Руслана, часто бывает так, что прототип, попавший в производство, работает без изменений много месяцев.
В начале своей карьеры Влад Попов, архитектор из Kinaxis, два года использовал PHP-скрипт с одним классом из 25 строк в качестве бэкенда для Flash-проектов.
Сильные программисты отличаются умением решать ситуации, которые блокируют продвижение по задаче. Они не боятся задавать коллегам вопросы и просить о помощи.
Руслан говорит, что большую роль играют психологические моменты.
Проблемы в личной жизни сразу приводят к просадке на работе. Поэтому баланс в жизни вне работы так же важен для карьеры, как и сама работа.
[Мои мысли] Здоровье, отношения и финансовая безопасность — основа всего остального.
Еще один момент в психологии — сильные программисты не боятся менять чужой код. Это часто бывает, когда программист начинает работать над новым проектом.
«Не бойтесь менять чужой код». — Руслан Торобаев
Вы должны понимать, что код был написан до вас такими же программистами, как вы, которые решали локальную проблему и обладали локальными знаниями о системе и продукте.
Уверенность в себе — еще одна психологическая черта сильного программиста, которая помогла Владу.
Когда ты уверен, что ты сильный программист, независимо от опыта, это помогает на собеседованиях, в общении, написании кода и комментировании в код-ревью.
[Мои мысли] Бывают моменты, когда я сомневаюсь, что принял правильное решение. Такие сомнения расходуют много «умственного топлива», которое у нас есть в ограниченном количестве на день.
Пишите проекты, чтобы обрести уверенность. Много проектов. Создайте свое портфолио и опубликуйте его. Что для вас несколько ночей программирования приведут к «вау, ты это написал?» отклик. Это эффект публичных портфелей.
[Мои мысли] Я попал в свою первую серьезную компанию благодаря портфолио из одного проекта.
Шестеро из одиннадцати программистов, давших ответы на эту статью, обладают заметной (на мой взгляд) скромностью.
«У меня выработалась привычка считать себя не умнее остальных, поэтому было много людей, которые могли бы меня поправить. Неважно, джуниор это или Линус Торвальдс. Любой может меня чему-то научить». — Антон Киреев
Несмотря на то, что им хорошо платят, не программисты приносят деньги в бизнес. Тот факт, что вам платят больше, чем многим вашим коллегам, может привести к высокомерию. Это может вызвать проблемы, предупреждает Руслан. Высокомерие только мешает.
[Мои мысли] Мы не зарабатываем лично, но можем потерять 460 миллионов долларов за 45 минут. Вот история о том, как крупнейший биржевой трейдер США обанкротился из-за мертвого кода.
Все вышеперечисленное объединяет любовь к своему делу и желание работать не в одиночку.
Каков путь к тому, чтобы стать сильным программистом?
«Делай то, что любишь, и люби то, что делаешь» — здравый смысл
[Мои мысли] Ниже описано множество способов стать сильным программистом. Некоторые советы будут противоречивыми, и это нормально. Единого подхода нет. У каждого свой путь. Важно выбрать тот, который вам понравится.
Работа в сфере информационных технологий (ИТ) – это постоянная гонка за знаниями. Системы, над которыми мы, программисты, чаще всего работаем, становятся более сложными, с растущими слоями абстракции над абстракциями и интеграцией всего со всем остальным. Решение задач в такой отрасли всегда требует больше знаний, чем у вас есть сейчас. Вы постоянно учитесь чему-то новому.
В поисках синдрома самозванца
«Если вы самый умный человек в комнате, вы ошиблись комнатой» — Конфуций
Ваша цель - попасть в сильную команду. Когда вы попадаете в сильное окружение, это мотивирует вас подняться до уровня окружения.
[Мои мысли] Присоединение к компании с сильной командой инженеров — это хороший способ найти следующую работу.
«Стремитесь работать с людьми, которые знают больше вас в какой-либо области, наблюдайте, как они работают и учатся». — Дмитрий Федоренко
Попробуйте работать в лучшей компании, которую вы можете найти. Если вы не можете этого сделать, потренируйтесь и освойте фундаментальные концепции. В наши дни существует множество ресурсов, таких как онлайн-курсы, YouTube и проекты с открытым исходным кодом. [Подробнее о саморазвитии будет сказано позже.]
Избегайте команд и компаний с токсичной атмосферой. В такой среде трудно учиться и расти.
Если вы не чувствуете, что постоянно учитесь, то пора задуматься о смене проекта или работодателя. Если вы не растете, это вредит вам и вашим коллегам.
«Новые среды — новые знания» — Руслан Торобаев
Обратная связь необходима для личностного роста. Без обратной связи расти сложнее. Если вы не получаете обратную связь, попросите ее.
[Мои мысли] 1 : 1 — это незаменимый инструмент для обмена отзывами как от руководящих должностей к разработчикам, так и от разработчиков к руководящим ролям.
Много времени придется потратить на обучение, и если вы не получите удовольствия от процесса, это будет казаться очень тяжелой работой.
Если вы увлекаетесь программированием и готовы проводить за этим выходные и вечера, занимаясь чем-то в свое удовольствие или программируя бесплатно, то, скорее всего, из вас получится хороший программист. И наоборот — редко те, кто сидит на работе с 9 до 5 и не занимается вне ее в качестве хобби, становятся топовыми или даже средними специалистами.
«Трудно быть успешным в IT, если ты приходишь туда за деньгами и хайпом. Должно быть, это призвание». — Дмитрий Федоренко
Хорошим местом для начала является должность веб-разработчика в веб-студии. Это часто место, где из вас выжимают соки, но они берут младших разработчиков с базовыми навыками, обучают их, дают им определенный опыт и прививают им привычку выполнять свои задачи в установленное время. Все это важные навыки.
«Простой вопрос — будете ли вы программировать, если вам за это не будут платить? Если нет, то мой путь не для вас» — Дмитрий Федоренко
Выбрать компанию сложно. Получить работу в «топовой» компании — это лотерея. Вы можете оказаться не в том проекте, или с не тем лидером, или со слабой командой.
[Мои мысли] В небольших компаниях немного проще, особенно в международных. Через glassdoor.com и teamblind.com/company вы можете прочитать отзывы бывших и нынешних сотрудников. Еще раз подчеркну, что такой подход не работает для крупных компаний. Но если вы сможете найти контакты действующих сотрудников и пообщаться в неформальной обстановке, то сможете узнать, есть ли в компании то, что вы ищете.
Там, где есть сложные задачи, есть сильные товарищи по команде
«Никакого давления, никаких бриллиантов». — Томас Карлайл
Как можно раньше начать участвовать в крупных, технически сложных (не путать с логически сложными) проектах и/или участвовать в программах стажировок для «топовых» технологических компаний.
Путь к сильным программистам лежит через сложные задачи. Это часто дополнение к сильным коллегам. Там, где есть сложные задачи, есть сильные коллеги.
Идеальной ситуацией было бы попасть в сильную команду, где вас могли бы наставлять и помогать в случае возникновения сложных проблем.
[Мои мысли] Я заметил, насколько я и мои коллеги выросли, когда работали в сжатые сроки над сложной задачей. Те времена, когда у вас нет другого выбора, кроме как научиться решать насущную проблему здесь и сейчас. В такие моменты действительно включаешься на полную катушку. А когда задание выполнено, чувствуешь, что ты на голову выше того, кем был вчера.
Ищите проекты и вызовы и выходите из зоны комфорта, если вам хочется постоянно заниматься рутинными задачами. Если не можете найти сложные задачи — смените проект или команду. Смена работы — еще один способ выйти из зоны комфорта и найти место для роста.
[Мои мысли] Не ждите, что каждая задача будет сложной и интересной. Нужна будет рутина. В ваших силах сделать задание более интересным. Например, вы можете оттачивать свои навыки, как спортсмен, чтобы быстрее и лучше выполнять свои обычные задачи, или автоматизировать рутинную задачу и чему-то научиться.
Следите за своими интересами. Выбирайте компанию, в которой вам будет очень интересно работать над продуктом, и сосредоточьтесь больше на отрасли или предметной области, а не на технологиях.
[Мои мысли] В долгосрочной перспективе интересная работа может быть важнее повышения зарплаты сейчас.
Саморазвитие
«Без отличных товарищей по команде сложно заниматься саморазвитием» — Руслан Торобаев
Вы можете найти умных людей за пределами рабочего места.
Открытый исходный код — это самый доступный источник самых лучших программистов, которые «покажут» свой код, свои приемы и дадут отзыв о вашем коде. Не воспользоваться этой возможностью в отсутствие сильных коллег невозможно. Open-source — это источник знаний и новых знакомств.
Читайте много кода. Откройте библиотеку, которую вы используете, и просто прочитайте ее.
«Каждое решение — это паттерн, который я разгадывал одиннадцать лет, и который пополнился знаниями по вопросам вроде «как работает Google», как это работает, как это работает». — Антон Киреев
Влад Попов обсуждает распространенную угрозу, когда современные программисты пишут неидиоматический код, не соответствующий используемым в проекте библиотекам. Загляните внутрь библиотек, которые вы используете, выясните, как они написаны, и используйте эти знания для написания лучшего кода.
Влад считает, что ему помогла привычка пробовать все экспериментальные технологии, как только они появляются. Так вы сможете стать опытным специалистом по успешным технологиям.
[Мои мысли] Он был одним из тех, кто увлекся Node.JS еще до первой версии и использовал Vue.js в продакшене семь лет назад, когда фреймворк еще не был так популярен. Теперь он эксперт и в том, и в другом.
С другой стороны, Денис Баженов считает, что размер стека нужно держать небольшим, не давая ему расти. Не гонитесь за каждой технологией, популярной сегодня. Используйте освободившееся время для углубленного изучения своего стека.
Зачастую от «топовых» компаний требуется глубокое знание языка и платформы, а начинающие программисты часто изучают фреймворки и библиотеки.
Антон Киреев изложил идею обучения программированию путем копирования других в сравнении с обучением игре на гитаре следующим образом.
«Можно смотреть табы [табулатура — нотация аккордов для гитаристов] чужих крутых песен, как код крутых программистов, и извлекать паттерны, повторяя их в своей работе. Но, повторяя «песни» других исполнителей, вы не научитесь играть испанскую пьесу. Чтобы играть что-то подобное, нужен кто-то, кто научит сидеть, правильному положению рук, правильному зажиму. Почему это важно? Потому что с правильной техникой вы получите лучший звук и меньше устанете».
Источники саморазвития Вадима Цеско, разработчика из odnoklasniki.ru:
- чтение академических статей
- технические книги
- переговоры на конференции
- участие в регулярных митапах и группах пользователей
- онлайн-курсы
- open-source проекты, баги/фичи, код-ревью
Не полагайтесь на обучение только через курсы и книги. Они не помогут вам выйти за рамки изучаемого стека в ОС и сеть, где чаще всего возникают проблемы.
Джордж Хотц, разработчик джейлбрейка iOS и основатель проекта машинного обучения для автоматизации транспортных средств comma.ai, сказал: Вы никогда не научитесь программировать, просматривая видео под названием «Учиться программировать».
«Книг, которые раскроют вам «тайну всего мира», не существует. Все книги, которые я прочитал, дают мне максимум 60% информации, которой я располагаю». — Антон Киреев
[Мои мысли] Остальное основано на личном опыте и опыте коллег.
Антон Киреев рекомендует книги Андрея Таненбаума для разработки вглубь технологического стека.
Чтение документации — еще один источник знаний. Там вы можете найти информацию о том, как все работает.
leetcode.com — это наиболее рекомендуемый ресурс для изучения основ компьютерных наук.
Руслан согласен с тем, что саморазвитие возможно, но считает, что университет будет лучшим выбором. Для программирования нужна хорошая база: высшая математика, комбинаторика, алгебра, операционные системы, сети, знание железа. Без формального образования получить эти знания сложнее. Хотя это не помешает вам создавать веб-сайты, отсутствие знаний будет ограничивающим фактором.
Попов советует обратить внимание на особенности новых языков программирования, которые учитывают проблемы, с которыми сталкивались предыдущие поколения программистов.
Чтобы научиться чему-то новому, нужно выбрать язык программирования, который будет вас выбивать из колеи, — делится Баженов. Он должен полностью отличаться от того, что вы используете ежедневно. Такой подход расширит ваш арсенал.
Не менее важно, чтобы рост был открыт для критики, считает один из программистов Facebook.
[Мои мысли] Самое сложное в предыдущем совете — обратить внимание на то, что вы чувствуете, когда вас критикуют, и убедиться, что ваша уязвленная гордость не заставляет вас отгораживаться от критики. В этот момент мозг не работает рационально и ты играешь в защите. Научиться ловить такие моменты и прислушиваться к советам — еще один важный soft skills. Один из моих инструментов для самоанализа — написать «дневной обзор» в дневнике перед сном. Я перенял этот инструмент у стоика, философа и римского государственного деятеля Луция Сенеки.
Денис Баженов видит большой плюс в том, что программисты знают о системном администрировании, и советует прочитать Блог о производительности Linux от Netflix Senior Performance Architect Брендана Грегга.
Для Java-разработчиков Руслан Торобаев советует отличный ресурс: shipilev.net.
Домашние проекты
Денис Баженов считает, что ему очень помогло создание чат-проекта для вуза, над которым он работал с Дмитрием Федоренко.
Часто отмечалось, что над любимыми проектами лучше работать с кем-то, чем в одиночку. Трудно работать над длительными проектами в одиночку. В какой-то момент вам неизбежно станет скучно, и ваш энтузиазм может угаснуть. Это случается реже при работе в команде.
Влад Попов брался за любое предложение, которое ему предлагали поработать над проектами. Он никогда не отказывался от работы и участвовал во многих проектах вообще без денег, просто ради опыта, интереса, рекомендаций и знакомств.
«У меня постоянно была куча проектов одновременно. Я был голоден по ним». — Влад Попов
[Мои мысли] Четыре года назад мы вместе работали над проектом, и он искал библиотеку для решения проблемы. «Дима, смотри, — сказал он, — хорошо написано… умно… тоже круто… хм, вот я бы по-другому написал, но нормально… интересно, кто автор?» Он открывает конфигурационный файл проекта, прокручивает вниз и видит, что он автор.
Работа над различными проектами помогла Владу освоить свой технический стек. Начните 25 проектов с нуля, и вы сделаете этот процесс безупречным!
Вадим Цеско советует написать — просто так — собственную реализацию различных слоев технологического стека: загрузочного файла, ядра, сети, структур данных, библиотеки и фреймворка. Это даст лучшее понимание всего стека, на который программисты полагаются каждый день.
Наставничество
«Когда ученик будет готов, появится учитель. Когда ученик действительно готов… учитель исчезнет». — Тао Тэ Цзин
Наставник может превратить годы самообучения в недели или месяцы в дни.
Влад Попов не получил желаемых знаний в университете. Вместо этого он отправился учиться к человеку, который знал интересующую его технологию лучше, чем кто-либо другой в его стране. Денис Муравьев провел интенсивный курс «Advanced Flash Programming», где уже через несколько дней дизайнеры смогли написать код ActionScript [родственник ECMAScript].
«Когда мне объяснили, что такое классы, я не понял, зачем они нужны, когда вместо них можно писать процедуры» — Влад Попов
Следите за самыми крутыми разработчиками на Github и Twitter, а также за разработчиками Core в своем стеке.
Их примеры того, как писать хороший код, вдохновят вас продолжать расти и находить дополнительное время для своих увлечений, чтобы двигаться вперед.
[Мои мысли] Наставник не обязательно должен знать, что он ваш наставник. Читая их блог, Twitter, слушая подкасты и просматривая скринкасты и видео на YouTube, вы можете многому научиться у программиста. Мы с Вовой Поповым взяли на вооружение ранее популярный редактор TextMate и научились разрабатывать на фреймворке Ruby on Rails. Выберите двух-трех сильнейших в своей области и прочитайте все, что они публикуют.
Сам Денис Баженов является наставником для юных одноклубников. Он поделился, на что обращать внимание при выборе наставника:
- Отдайте предпочтение узкоспециализированным, которые давно копаются в своей теме
- Избегайте людей, которые критичны в своем мышлении
- Выберите того, кто может рассказать не только о плюсах, но и о минусах технологии, которую вы хотите изучить
Как вы можете быть хорошим учеником для наставника:
- Не будь равнодушным, ты должен проявлять интерес
- Заниматься чем-то помимо работы с 9 до 17, например, открытым исходным кодом, любимым проектом или писать в блог.
- Работайте над тем, чтобы быть более открытым для идей других людей
Что, если вы только начинаете?
Начинающие программисты должны как можно больше заниматься программированием на практике. Они должны быть в состоянии следовать за лидером.
Цель — быть максимально полезным без постоянных вопросов и уметь самостоятельно решить грамотно поставленную задачу.
Следующим шагом будет расширение кругозора. Проверка кода, git, отладка, DevOps, решение проблем [о решении проблем читайте ниже]. Развитие этих доменов позволит вам стать самодостаточным.
Что может помочь начинающим программистам реализовать свой потенциал?
- Стажировка в командах со сложными задачами и опытными коллегами
- Водить машину
- Наличие собственных идей
- Открыт для критики
- Способность быть ведомым
Как найти время на все это?
Тяжелую работу никто не отменяет.
«Порог для поступления в программирование и IT в целом высок. Чтобы стать средним специалистом, нужно много работать пять-десять лет. Мы должны убедиться, что мы планируем регулярные «потогонные» для себя »- Дмитрий Федоренко
«Все свободное время направляйте на саморазвитие» — Вадим Цеско
У многих есть семьи и дети. Как найти время хотя бы на что-то из перечисленного?
Главный секрет – сильное внутреннее желание. Делай то, что любишь, люби то, что делаешь. Вы всегда найдете время для того, что делает вас счастливым.
«Не знаю, просто так бывает!» — Антон Киреев
Инструменты сильных программистов
Дмитрий Федоренко использует практику «Getting Things Done».
Потратьте время на изучение того, как использовать отладчики. Отладчики очень помогают быстро понять, что происходит не так. Это поможет в устранении ошибок и в разработке, когда код перестанет работать так, как вы хотите.
Аналитическая отладка [термин не мой, но от разработчиков JetBrains] — это способ отказаться от отладчиков и подумать о том, что пошло не так. Преимущество такого подхода в том, что вы с большей вероятностью найдете источники проблемы, а не ее симптомы. У вас растет общее понимание проекта, и вы можете найти сопутствующие ошибки. Недостатком аналитической отладки является то, что она во много раз медленнее, чем при использовании отладчиков.
Средства отладки ОС, которые использует Денис Баженов, включают:
Преимущество этих средств диагностики в том, что они позволяют понять, что происходит с приложением вне зависимости от того, на каком языке написано приложение.
Решайте проблемы как ПРО
«Проблемы у всех разные, но все они сводятся к одним и тем же задачам» — программист из JetBrains
В решении задач нет секретов. Используйте теорию принятия решений и стандартные подходы к решению проблем.
Обратите внимание на шаблоны. Чем быстрее вы их определите, тем быстрее сможете решить проблемы.
Наилучший подход к решению проблем — рассматривать их как задачу оптимизации с довольно сложными граничными условиями. Поэтому самая сложная часть этого процесса — выбрать наилучшее решение.
Не верьте слепо описанию проблемы. Прежде чем ее решать, нужно хорошо в ней разобраться. Узнайте, кому именно это нужно и зачем. Для этого нужно задавать вопросы. В трети случаев задача может вообще исчезнуть, а в другой трети сильно измениться.
- Дмитрий, сделайте здесь зеленую кнопку. — Нет, сначала опишите, какая у вас проблема? Зачем тебе кнопка? Что произойдет, если мы этого не сделаем?
Такой подход экономит много энергии. Часто перед началом работы выясняется, что нужна не кнопка, а ссылка, или текст на странице, или вообще ничего делать не нужно. Лучше сначала потратить время на разговор, а потом на программирование.
«Отсутствие требований — постоянная проблема, с которой я сталкиваюсь». — Дмитрий Федоренко
Разбивайте сложные задачи на небольшие управляемые части, детали которых легко умещаются в вашей голове и которые вы можете решить за четыре часа.
«Маленькие библиотеки более полезны, чем одна большая. Идеальная библиотека — это библиотека, которую можно написать за четыре часа и забыть о ней». — Влад Попов
Большие задачи занимают часы, чтобы погрузиться в них каждый раз, когда вы начинаете над ними работать. Избегайте переключения контекста — в этом помогают небольшие задачи.
Попробуйте использовать первые принципы и подумайте, как лучше решить проблему без ограничений. Рассмотрите компромиссы между различными решениями и уклоном в сторону простоты.
Стремитесь собрать минимальный рабочий прототип. Не беспокойтесь о качестве или использовании лучших инструментов, таких как базы данных, очереди и т. д. Сделайте это в короткие сроки, чтобы увидеть, как работает функция, и получить отзывы о ней от пользователей.
Ищите кратчайший путь к решению.
«Когда я был неопытен, я хотел сделать все как можно лучше, и я начинал с желания тщательно «построить мост» от одного конца до другого [внедрить полный функционал с первого раза]. Но со временем я понял что такие мосты оказываются не в том месте. Поэтому с опытом я сначала «протаптываю дорожку», делая хотя бы работающий прототип, потом, когда (и если) эта штука как-то заработает, начинаю класть мясо на кости [итерировать в сторону более полной функциональности]. ». — программист из ok.ru
[Мои мысли] Когда у вас есть готовое достаточно хорошее решение, сроки больше не давят на вас. Здесь вы можете принять решение что-то улучшить, получить отзыв о коде или сэкономить время для другой задачи. Пытаясь сделать его гладким сразу, я часто пропускал крайний срок.
Учитывайте требования и ресурсы, которые у вас есть. Одни задания требуют погружения в предметную область, другие – пустая трата времени.
Использование аналитики полезно для бизнеса, мониторинга, отладки.
Когда не знаешь, как решить проблему, придумай самое простое решение. До if a = some_value then return expected_result. Вам просто нужно начать, и как только вы решили простейший случай, выберите следующее требование и повторите, а затем продолжайте в том же духе.
Часто задачи, которые вы не знаете, как решить, заведомо решаемы. Решение для них приходит из интенсивного поиска в Интернете. Недостатком такого подхода является то, что он занимает много времени, дней и недель.
Задачи, которые вы не можете решить сейчас, можно отложить на пару часов или на завтра. Засыпайте с мыслью о сложной задаче — часто идея приходит утром!
[Мои мысли] Это связано с тем, что наш мозг работает в двух режимах: сосредоточенном и рассеянном. Сфокусированный режим позволяет нам держать в голове более сложные детали. Это больше касается глубины знаний. В то время как диффузный режим — это режим творческой работы с использованием всей широты наших знаний. Новые идеи приходят в рассеянном режиме, при котором мозг работает в фоновом режиме. Это объясняет мнение, что идеи приходят в душе.
Подробным разбором подхода к решению проблем поделился Вадим Цеско:
- Сбор всех требований, погружение в предметную область
- Тщательная документация (проектная документация) для последующего ретроспективного анализа обслуживания и развития системы
- Поиск и общение с коллегами с соответствующим опытом для сбора исчерпывающего набора альтернатив
- Изучение существующих решений на рынке, чтение актуальных научных статей
- Анализ преимуществ и недостатков каждого из вариантов решения, выбор решения
- Итеративный обзор проекта и сбор мнений от более опытных коллег
- Важно: чтобы не замыкаться и не застревать, активно собирать мнения, быть открытым и терпимым к критике, честно взвешивать все за и против, принимать решения на доказательной основе.
Советы от Дениса Баженова:
- Концептуализируйте задачу с точки зрения технических и бизнес-ограничений, а также при каких условиях решение не будет работать.
- Если задача не требовательна к ресурсам, то разработайте прототип с помощью автоматизированного тестирования. Легче сформировать дизайн, и любые недостатки могут быть обнаружены раньше.
- Если задача технически сложная или связана с распределенными системами, важно проанализировать, что может дать сбой, какие шаги необходимо предпринять, чтобы сделать систему диагностируемой, что мы будем делать, если части системы начнут сбоить, как устранять сбои и как перестраховаться, например собрать специальные журналы.
- Когда все сходится, то дело доходит до программирования, и нужно прийти к пониманию, на какие модули разделить систему и как организовать работу.
- Подумайте о создании прототипа (возможно, даже без программирования)
Советы по реализации решений от Руслана Торобаева:
- Пишите юнит-тесты, если задача большая и нет возможности держать в голове все ее части.
- Используйте специализированные журналы для кода интеграции. В интеграциях невозможно все покрыть тестами.
- Для небольших компонентов полезна разработка через тестирование. Помогает найти недостатки в интерфейсе. Если компонент нельзя протестировать, вы сразу понимаете, что нужно менять интерфейс.
Важно уметь решать блоки во время работы над задачей. Вот как к этому подойти:
- Используйте внутреннюю базу знаний или документацию или внешнюю документацию по продукту
- Получите помощь от коллег
- StackOverflow, каналы сообщества Slack, Discord, группы пользователей, проблемы в библиотеке или репозитории продуктов, каналы продуктов.
- Посмотрите исходный код. Для сторонних продуктов вы можете получить образ Docker, начать отладку с помощью точек останова и посмотреть, как продукт работает изнутри. Делайте это одновременно с первыми тремя действиями!
Еще не все…
«Искусство никогда не бывает законченным, его можно только оставить». - Леонардо да Винчи
К тому времени, когда я решил опубликовать эту статью, в моем списке было еще больше программистов, с которыми я мог поговорить, чем когда я начинал этот проект.
Эта страница будет обновляться с течением времени.
Подпишитесь на мою рассылку сейчас, чтобы узнать, когда будет добавлено больше крупиц мудрости и легко забываемых простых правил.
Герои этой статьи
Большое спасибо этим людям за их ответы и за отличный чат!
- Антон Киреев, программист Avito
- Денис Баженов, технический руководитель Farpost
- Дмитрий Федоренко, технический директор 100sp.ru
- Роман Дмитриенко, тимлид drom.ru
- Руслан Торобаев, тимлид, на ok.ru
- Вадим Цеско, программист ok.ru, педагог
- Влад Попов, архитектор Kinaxis
И те, кто пожелал остаться неизвестным:
- программист из фейсбука
- бывший Амазонка, пр. программист майкрософт
- программист из JetBrains
- программист с ok.ru
