Опускаются руки и хочется бросить задачу? Так выглядит эффективное обучение разработчика

https://medium.freecodecamp.org/why-you-learn-the-most-when-you-feel-like-youre-struggling-as-a-developer-7513327c8ee4
  • Перевод


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

Возможно, это поможет и вам.

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

Знаю, у других это тоже бывает.

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

Очень важно проявлять упорство перед лицом таких трудностей — хотя это и непросто.

За прошедшие годы я научился нескольким ментальных «хитростям», которые помогали мне в сложные минуты, часы и дни.

Я расскажу о тех точках зрения, которые оказались особенно полезны.

Переведено в Alconost

1. Разработчик растет профессионально благодаря упорному труду и прилагаемым усилиям


Что главное в разработчике: талант или упорный труд?

Люди просто рождаются великими разработчиками — или им приходится прикладывать для этого усилия?

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

Такая точка зрения полезнее: она означает, что если что-то мне никак не дается — нужно хорошенько постараться, и я разберусь.

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



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


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

Как-то мне пришлось работать в компании, которая использовала git, и все вокруг меня были специалистами в этой VCS. Было время, когда мне пришлось столкнуться с тем, что мои знания SQL оказались не так уж хороши.

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

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

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

Получается как-то так…
«Я никогда раньше не программировал на Джаве — значит, я и не должен быть хорош в этом. Поэтому я и иду на эти курсы».
«Я никогда не использовал git-репозитории — я не обязан знать, как это делается. Поэтому я попрошу коллегу помочь».
Так я смог обезоружить голос в моей голове, который твердит, что я не гожусь для своей работы, что у меня не получится. Конечно, у меня может не получиться, и естественно, что я пока что не очень хорош — но я и не должен что-то хорошо уметь сразу, поэтому я пробую и постепенно совершенствуюсь.

3. Работа с кодом не всегда должна быть приятной: даже если задача неинтересная, ее всё равно можно сделать


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

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

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

Но я понимаю: программирование не всегда должно радовать — иногда приходится просто засучить рукава и взяться за неинтересную работу.

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

4. Чем сложнее задача, тем большему вы научитесь, и неудача в таких случаях — это нормально


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

И в моей жизни этому есть множество примеров.

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

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

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

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

И этот список можно долго продолжать.

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

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

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

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

Мозг — мощный инструмент


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

Надеюсь, мои ментальные «хитрости» (или те, которые вы придумаете сами) помогут вам справиться с трудностями.

Будьте упрямы и не сдавайтесь.

Если вы чего-то не понимаете, продолжайте упорно трудиться и пытаться это понять: вы удивитесь, на что способны — только попробуйте.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее

Alconost

105,67

Локализуем на 68 языков, делаем видеоролики для IT

Поделиться публикацией
Комментарии 28
    –4
    КЛАССНО!!!
      +11
      Но я понимаю: программирование не всегда должно радовать — иногда приходится просто засучить рукава и взяться за неинтересную работу.

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

      Мне кажется, есть существенная разница между сложной и геморройной задачами. В первом случае, ты развиваешься за счет того, что тебе приходится узнавать что-то новое, пробовать какие-то неизвестные ранее подходы и это прям здорово, это заводит).
      А во втором — ты просто берешь и перегораешь. Например, тебе из легаси-недр в 2к18 прилетают не джсоны, а xml, при чем, написанные криво на коленке человеком, который всю жизнь курил героин. Это сложная задача? Безусловно, понять логику человека, который создает этих франкенштейнов — непросто. Но разве такие задачи развивают? Маловероятно, что ты здорово разовьешься, если будешь понимать, как залезть в недра сложного объекта и попревращать в этих недрах map в array и обратно, ведь по сути, превращать map в array ты и так можешь уметь сотней разных способов. Что именно тренировать в этом случае? Усидчивость? Каменную задницу?
      (с) джуниор-фронтенд
        +1
        Мне кажется, есть существенная разница между сложной и геморройной задачами. В первом случае, ты развиваешься за счет того, что тебе приходится узнавать что-то новое, пробовать какие-то неизвестные ранее подходы и это прям здорово, это заводит).

        Вы подгоняете решение под нужный вам ответ. Я точно так же могу сказать, что сложная задача — это может быть «сделай-ка нам <то, не знаю что>, <так, не знаю как>, собственными силами и до завтра». И ничего нового вы не узнаете и не попробуете, так как неизбежно завалите сроки еще даже до того, как детально поймете, что собственно было нужно.
        (Если вы надеетесь, что в реальной жизни так не бывает — то не надейтесь. Бывает)

        В то время как геморройная задача зачастую вполне себе подлежит изящной автоматизации. Под xml можно удобный парсер сделать, например, причем именно под кривые xml этого конкретного случая. Да, писать парсер — это вам не нейросетки, но я бы не сказал, что это прям никак не развивающая задача.
          +1
          У меня сейчас висит задача «сделать из системы А систему Б для установки у клиента из другого города, по времени согласовано 16 часов».
          И я заранее знаю, что результат будет дерьмовый, потому что код А уже находится в состоянии «отладочная печать ломает реалтайм», а Б предполагает изменения как в логике так и в работе с периферией. Я заранее знаю, что будет масса сбоев, и мне придётся наобум поддерживать единичный экземпляр, стоящий в другом городе. И я точно знаю, что, если оно «выстрелит», то это позорище пойдёт в серию без доработок D:
          Это вы называете эффективным обучением?
            0
            Насчет эффективного поспорить наверно можно, но на таких задачах тоже вполне неплохо обучаешься. Можно увидеть решения которые лучше не повторять, можно узнать решения которые можно иногда закостылить при дефиците времени, навыки отладки, чтения запутанного кода, поиска багов…
              +2
              Из этой задачи можно извлечь хороший урок. А так же сделать выводы о том, кто ставил задачу и оценивал её. Ну и соотвественно если видишь проблемы заранее, почему бы их не озвучить остальным членам команды и найти решение?
                0
                А разработчику точно нужны такие уроки? Может быть, ещё Friendship Lessons устроить?
                  0
                  Собственно к чему это я, если не нравятся правила игры, попробуй их изменить, ну можно и саму игру поменять. Ну и не стоить акцент делать на «разработчике», все-таки это загон в рамки. Можно поменять задачу, декомпозировать её, попросить переоценить, а не говорить «нужно ли это разработчику?», да и говоря «я заранее знаю, что результат будет дерьмовый» ты уже обрекаешь результат на провал.
                +1
                Делается декомпозиция задачи, составные части оцениваются, оценка превышает 16 часов, озвучивается. На приказ «надо уложиться» предлагается вычеркнуть часть функционала или добавить ресурсов.

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

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

                Я точно так же могу сказать, что сложная задача — это может быть «сделай-ка нам <то, не знаю что>, <так, не знаю как>, собственными силами и до завтра»

                На мой взгляд, хорошее описание класса нереалистичных требований/задач.
                  +1
                  Да как угодно определяй термины. Я в общем-то писал о том, что сложная задача не подразумевает программерского развития, захватывающего поиска хорошего решения, и всего такого. Это всё может быть, а может и не быть, и от сложности задачи на самом деле совсем не зависит.
                0
                В приведенном примере, как минимум, вы учитесь читать (понимать) чужой код.

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

                Но со временем начинаешь замечать, что читаешь и понимаешь значительно быстрее многих коллег.
                  0
                  Например, тебе из легаси-недр в 2к18 прилетают не джсоны, а xml, при чем, написанные криво на коленке человеком, который всю жизнь курил героин. Это сложная задача? Безусловно, понять логику человека, который создает этих франкенштейнов — непросто. Но разве такие задачи развивают?

                  Да, развивают — умение рассуждать о коде и данных и извлекать информацию из того, что есть. Есть даже книжка "Working with legacy code"

                  –1
                  Поэтому сегодня я предпочитаю считать, что стресс, трудности и некоторая нервозность — это хороший признак: если мне сложно, значит, я учусь.

                  Мне кажется, что «стресс, трудности и некоторая нервозность» даже могут потом начать нравится, мазохизм какой-то) А вообще, это скорее шутка, чем правда, но в каждой шутке…
                    –2
                    Тот кто поставил минус, явно без чувства юмора…
                      0
                      Отчасти согласен. Стресс нужен ровно в тех количествах, чтобы держать себя в тонусе, но при этом не превращаться в невротика.

                      «У меня все в порядке с нервной системой! Заводится с пол-оборота!»
                      +2
                      Или, например, я как-то попытался взяться за разработку архитектуры крупных приложений. Я долго и напряженно бился над задачей, пока не узнал о структурных и конструктивных шаблонах — после чего нам пришлось выбросить месяцы работы над кодом, начать сначала и построить приложение с нуля за считанные недели — с помощью новых знаний.

                      Хорошо живет.
                      По моим наблюдениям часто вместе с плохим кодом выбрасывают и архитектора
                        0

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

                          0
                          Не согласен. Программирование — это точно не игра. Цена ошибки в игре мизерна по сравнению с ошибкой в боевом продукте, которая в может к финансовым потерям и навредить репутации исполнителя.
                          +1
                          Хуже всего когда: [1] тебе за 30, а ты ещё джуник.Все написанное грузит мозг в разы. [2] Печальтоска, да ещё на умирающем фреймворке (aka codeigniter). P.S. поныл, полегчало.
                            0
                            2. Пытаться сделать что-то впервые может быть сложно, и неразумно ожидать, что вы сразу станете в этом докой
                            Кем станете? «Докой»?
                              0
                              Странно что впервые слышите. По моему не так уж редко выражение встречается.
                                +1
                                Первый раз такое слово вижу, сначала подумал ошибка в переводе.

                                Дока — это человек, который особенно хорошо разбирается в определенной области, знаток и мастер своего дела. Синонимы слова «дока» — мастер, ас, мастак, искусник, знаток, ловкач, умелец.
                              0
                              «Что главное в разработчике: талант или упорный труд?»
                              Этот вопрос в принципе не верен. Главное — что бы разработчику нравилось программирование и/или он считал это чем-то хорошим/замечательным/крутым…
                                0
                                Поэтому сегодня я предпочитаю считать, что стресс, трудности и некоторая нервозность — это хороший признак: если мне сложно, значит, я учусь.

                                Звучит как прямой путь к выгоранию. Не надо так.
                                  0
                                  Странно, что автора ещё не отослали искать вакуумную компанию в сфере, где до такого уныния не доходит. Но как правило, если замечают сверху, что разработчик весел, приветлив, предлагает новведения, то вывод назревает один — надо ему работы подкинуть
                                  и повышать уровень и скилы тут бесполезно.
                                    0
                                    +
                                      0
                                      Спасибо за перевод.
                                      иногда приходится просто засучить рукава и взяться за неинтересную работу

                                      Главное, чтобы это было не часто, иначе
                                      который хочет совершенствоваться профессионально.

                                      придется совершенствоваться в свободное от работы время.

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

                                      Самое читаемое