Опасности обучения по книгам

Original author: Dave Fecak
  • Translation
Сегодня разработчики находятся в состоянии постоянного давления. Желание добиться высокого уровня владения новыми языками и инструментами, боязнь однажды выпасть из информационного потока может затмевать всё. Действительно, с риском потери конкурентоспособности сталкиваются как программисты, не следящие за тенденциями и движениями индустрии, так и постоянно читающие технические новости для ориентации: какие навыки выучить при наличии времени, какие игнорировать, какие методы следует использовать.

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

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


Как менеджер по кадрам, я встречался с кандидатами, которые быстро изучали новый язык (используемый потенциальным работодателем) и решали какую-нибудь проблему из тех, что часто задают на интервью, или даже разрабатывали простое приложение в репозитории GitHub. В качестве лидера группы пользователей Java, я сталкивался с докладчиками, которые собирали простое приложение для знакомства с демонстрируемым фреймворком и показывали его работу. Целью презентации может являться «Я думаю, X выглядит круто. Я с этим не работал, но почитал и написал кое-что для демонстрации опыта работы с X. Я буду готов в течение месяца.»

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

Конкурентоспособность и преимущества интервью


Написать этот пост об обучении по книгам меня побудил обзор трудоустройств после моих собеседований за прошлый год. Разработчики, которым я помог устроиться на новую работу, имели (за редкими исключениями) одну общую вещь — портфолио продуктов и кода. Десять или пять лет назад это было редкостью, но сегодня стало нормой. Разработчики под Android и iOS могли показать по крайней мере одно приложение, доступное для загрузки. Web-разработчики демонстрировали сайты и сопровождающие примеры кода. Даже специализирующимся на back end программистам было что показать на интервью.

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

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

Преимущества интервью


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

tl;dr
Читайте достаточно, чтобы начать работать, и пишите что-нибудь. Не задумывайтесь, изменит ли это мир. Сохраняйте написанное и улучшайте его время от времени. Приносите код на интервью и практикуйтесь рассказывать о своих творениях.
Share post

Similar posts

Comments 26

    +28
    Опасности обучения по книгам
    я, возможно, слишком субъективен (и поэтому пишу сюда на суд общества, а не в личку), но заголовок, на мой взгляд, звучит неподобающе. Думаю, что в оригинале речь идет не про обучение по книгам, а про «книжную ученость», от которой мало пользы.
    Скрытый текст
    что-то в смысле
    book-learning — Knowledge acquired from reading books, as opposed to knowledge gained through experience or feeling; theoretical or academic knowledge as opposed to practical or common-sensical knowledge.
    en.wiktionary.org/wiki/book-learning

      +2
      Да, возможно заголовок неверен. Речь именно об обучении только по книгам.
        +2
        Основной посыл статьи, как я это понял: теория без практики — здоровье на ветер.
          0
          В общем-то, да. И это довольно очевидно.
          Не зря же есть разница между студентом CS- или IT-специальности и промышленным программистом.

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

          Все эти умения позволят человека с опытом использовать эффективнее, чем человека только с теорией.
        +21
        Не увидел в посте описания опасностей от чтения книг. Книга — практически единственный способ получить сразу и в полном объеме знания. Понятно, что этого не достаточно. Далее надо «руку набить».
        А вот без книг получается результат гораздо плачевнее. По статьям на хабре предмет не изучишь. Лучше брать на работу человека, не имеющего опыта, хорошо знающего книгу, чем выскочку, что-то сделавшего по пошаговому руководству. Первый хоть будет встречать в проекте знакомые вещи и быстро научится.
          –1
          Это действительно так? Лучше брать человека, который только книгу прочитал, и всё? Вы это можете аргументировать?
          Мне вот кажется, что человек, который что-то сделал по паре туториалов, пролистал документацию и прочитал энное количество топиков на stackoverflow более быстро обучаем, чем тот, кто прочитал книгу.

          disclaimer: я не утверждаю, что для программирования достаточно погуглить, базовый уровень знания должен быть, и для получения этого уровня лучше подходят книги, но вот изучение новых технологий, имхо, лучше делать на практике. Сужу исключительно по своему опыту, мне легче учиться на примерах, саму проверять, как всё работает. Вопросы в начале не сарказм, а заинтересованность: вы это утверждаете только исходя из своего опыта обучения (как я), или есть какие-то более объективные данные?
            +4
            Лучше брать человека, который только книгу прочитал, и всё?

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

            Книги не достаточны. Нужно иметь опыт. Это значит — и попробовать самому и еще лучше — поработать в коллективе, кто в этих вещах опытный.
            Но книги — самый надежный вариант быстро войти в тему. Хорошая книга дает всю базу, все необходимые знания, кроме нюансов, кроме практики. И если кто-нибудь хочет с чем-то работать, то лучше сразу изучить книгу, потом уже пробовать. Второй шаг тоже обязательный. Без начального изучения материала, человек пробуя, строит нечто несуразное, создает велосипеды, не знает даже, в каком направлении двигаться. Допускает много ошибок и даже не знает, что их можно не допускать. Поэтому — сначала база, потом практика — наиболее быстрый метод.
            И еще, чтение любой книги гораздо меньше времени займет, чем обретение практики. Только лень и высокое ЧСВ заставляют людей думать, что они и без книг умные. А по времени на самом деле выгоднее прочитать книгу.

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

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

              Тогда не закончится все использованием инструментов не по назначению, или использованием не самых удобных инструментов из-за того, что прочитана была лишь статья с решением похожей задачи.
              +1
              Довольно интересное мнение. Я у себя в городе пока что встречал от работодателей прямо противоположное отношение к этому вопросу: лучше нанять человека хоть с каким-то опытом, чем чистого теоретика.
                +7
                Повторю — это мнение основано на ЧСВ. Нет разделения на теорию и практику. Но много людей, не имеющих мозгов, пытаются себя причислить к практикам. Это такой общественный стереотип — если человек знает хорошо науки, математику и т.п., то он в жизни глупее, забывает зонтик, теряет очки и т.д. Причем много людей как раз не осваивают никаких теорий, просто потому, что либо ленивы, либо не дано — но зато себя потом причисляют к умельцам не все руки — противоположность тем, кто все таки что-то изучил. И таких людей больше. Особенно много в бизнесе. Естественно, они поддерживают такой миф. Один раз я удивился, когда вроде опытный программист, на математическом проекте, смеялся с тех, кто знает как взять интеграл. Т.е. считал, что те, кто берут интеграл — немного недоумки. Смешно, правда?

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

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

                  Для меня это вообще выглядит фантастичным, чтобы человек изучал технологию только по книгам. Это, во-первых, странно. Если человек изучает теорию, но не применяет на практике, значит ему эта технология не интересна. Но тогда не понятно, зачем он вообще читал.
                  Ну а во-вторых, это не рационально. Ещё со школы нам говорили, что лучше запоминается информация, которую мы используем. Именно поэтому и пишем конспекты/сочинения.
                  Без практики эти знания со временем просто улетучатся.

                    +3
                    Вы неверно поняли мою фразу. Это при прочих равных условиях. Если взять двух человек и оба не имели опыта работы, но один показывает что-то сделанное, а второй уверенные знания — то второй лучше.

                    Всё верно — книги без практики — пустая трата времени. Но и не надо из этого делать противоположности — либо практика, либо книги. Книга, а за ней практика наиболее быстрый способ получить глубокие знания. Просто потому, что любую книгу прочитаете за неделю/две. А практика нарабатывается дольше. Так удлинять себе путь и учиться на своих ошибках? В конце концов, если захотите стать профи в теме, то Вам рано или поздно придется прочитать книги, чтобы не было упущенных знаний. Так что оптимально начать с книги.
                  0
                  Наверное подразумевается, что человек с опытом и книги читал, и практика у него была (хотя бы на уровне туториала).
                +1
                Как говорится, «совмещайте правильно теорию и практику».
                Думаю, это практически к любой области/отрасли относится.
                  +10
                  Нет ничего плохого, в том, чтобы читать много и не всегда строго по своей теме. Чем больше человек читает и знает, тем лучше.

                  Это совсем не отменяет необходимости заниматься практической работой, правда.
                    –2
                    Я когда общаюсь с человеком чтобы взять его себе в команду или по просьбе знакомых провожу техническое интервью (обычно это Python либо JS frontend) всегда задаю вопрос: «Покажи, пожалуйста, кусок кода который ты считаешь стоящим из твоих прошлых проектов».

                    Книжное знание это практически ничего. Недавно взяли на работу человека, который работал только с РНР на должность Django разработчика. Немного советов и помощи — и я уже уверен что потянет большинство проектов.
                    И он прямая противоположность человека который только прочел какой-нибудь Dive Into Python или Django Book
                      0
                      Всегда было интересно посмотреть на «кусок кода который ты считаешь стоящим». (Хорошо что ниразу не просили меня такого, смотрели только на прошлые проект и/или тестовое задание.) Как по куску неведомого кода определить что он хороший? Сколько кб должен занимать этот кусок?
                      например
                      article=this->db->getarticle
                      this->view->showarticle(article)
                      это хороший код? или пустышка? или надо раскрывать что по getarticle скрывается?
                      а если прошлый код защищен неким договором со стороны работодателей?
                      +19
                      Теория без практики мертва. Практика без теории слепа.
                      /thread
                        0
                        Устраивался в пару на мой взгляд хороших мест, на Android разработчика. Спрашивали помимо собственных приложений про design patterns, почему какая либо часть android framework устроена именно так, алгоритмы, тонкости в java — то, с чем разве как в книгах вряд ли где встретишься.
                          +4
                          Ещё нужно иметь в виду, что книга книге рознь. Одно дело прочитать справочник по языку, а другое книгу, где сущности языка вводятся на примере какого-то более-менее реального проекта. А лучше, конечно, и то, и другое. Ну и собственно качество книги большое значение имеет. Иные так вредно читать в принципе, если не предупреждать читателя «прочитай и никогда так не делай!».

                          Ну а так могу сказать, что из активных своих языков я знаю лучше те, по которым книги читал, а, скажем, JavaScript учил исключительно по образцам кода и отрывочным статьям и знаю его много хуже того же PHP, по которому прочел десятки книг, при этом изучать JS и PHP начал одновременно, придя в веб, и PHP бывало «изменял», а JS — никогда.
                            0
                            Вот именно, лично я привык начинать изучение новой технологии по обзорным статьям на википедии, хабре, а затем обязательно шлифануть все это хорошей книгой по теме, иначе будет в голове каша.
                            0
                            Наличие проектов для «показать» — это, конечно, круто, но поскольку такие проекты под частую являются командной работой, то вклад одного конкретного разработчика в них оценить бывает непросто.
                              +1
                              Вставлю свои три копейки на примере Java. Работал я какое-то время назад с одним мужиком который прочитал книжку и получил SCJP сертификат. Выхлоп с него как с Java developer'a нулевой. Вьорая крайность — обучение через гугл. Товарищ такого типа нагугдивает решения своей проблемы и это даже работает. Но это код который весьма уродлив и неоптимален. БОльшую часть придется переписывать. Результат полезности тоже весьма не велик. Так что имхо:
                              Книга -> Проблвать -> гуглить -> Пробоватб -> книга ->…

                              А иначе результат будет весьма говенен. Проверено и на своей шкуре в том числе ;)
                                0
                                Да, хорошо иногда проблвать после хорошей книжки… :)
                                  +1
                                  Да, хорошо иногда проблвать после хорошей книжки… :)

                                  После некоторых книг хочется попробовать теорию в деле. А есть книги, после которых хочется именно проблевать )
                                +1
                                Не в обиду автору перевода, но я только что пересмотрел фильм «Яйцеголовые» и сходство перевода со стилем повествования «яйцеголовых» мне показалось очень близким.

                                Only users with full accounts can post comments. Log in, please.