Я б в программеры пошёл, пусть меня научат

Источник: habrahabr

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

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

 


Привет, Хабр! Я работаю в РегионСофт уже 4 года, и за это время успела не только пережить два мажорных релиза нашей CRM-системы, но и трижды поучиться. Сегодня расскажу о подводных камнях корпоративных университетов, вузов, курсов и попробую классифицировать возможные пути обучения и переобучения будущего айтишника. Текст больше ориентирован на тех, кто хочет сменить профессию, но и студентам, уверена, будет полезно. 

Вузы, вы больны

Нашему вузовскому курсу повезло - мы были вторым годом новой специализации "Финансовый менеджмент и финансовая математика", и вуз был вынужден решать кадровую проблему довольно необычным для российского образования путем. Да, часть финансовых дисциплин нам читали всё те же старые профессора, которые начинали свой карьерный путь с политэкономии и особо с него не сворачивали. Но во всём, что касалось рынка ценных бумаг, технического анализа, биржевого дела, специализированной математики они были полные профаны. Поэтому трое преподавателей внезапно отличались от классической школы - это были практикующий программист, профессиональный трейдер и тренер, обучавший первых игроков нынешней Московской биржи (тогда ещё ММВБ). Что их отличало:

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

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

Что плохо в современном вузовском образовании?

  • Устаревшая материально-техническая база и устаревшие учебные планы - согласитесь, странно изучать Windows Server 2003 или Pascal в 2017 году.
  • Преподаватели-теоретики, некоторые из которых просто прошли курсы повышения квалификации и, например из математика превратились в преподавателя по алгоритмам и структурам данных.
  • Отсутствие практики - согласитесь, формальный месяц, за который студенты дважды посещают базу практики, совершенно не то, что нужно разработчикам или инженерам. В то время как вуз может запросто давать первичный и довольно глубокий опыт, припахивая студентов к внутренним проектам или грантам.

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

Почему это важно:

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

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

Корпоративный институт как не идеальная, но лучшая форма обучения

А бизнес - это другие реалии, потребности работодателя и другие схемы обучения. Провожая меня за пределы вуза, мой первый начальник, проректор по науке, сказал: "Каждый год ты должна тратить одну зарплату на обучение - курсы ли, образование, книги, - не важно. Сам процесс обучения упорядочивает мышление". Первый год работы в бизнесе я начисто забыла об этих словах - вся жизнь и без того была похожа на обучение (а точнее, гибрид армейской дедовщины с дрессурой манула). В конце второго года осенило, что работать в ИТ (коммерческая служба) и не понимать внутренностей ИТ чревато ошибками и идиотскими ситуациями, поэтому было решено - учусь. 

Рассматривалось три варианта:

  1. магистратура мехмата - была отвергнута из-за того, что в учебном плане было до кучи ненужного, а времени ушло бы три года. Ну и дорого, конечно;
  2. дополнительное образование в университете - было отвергнуто из-за устаревшей программы (как вам офисное программирование VBA или Access как изучаемая СУБД?) и изученного списка преподавателей-теоретиков;
  3. обучение в корпоративном институте крупнейшей компании-разработчика в городе. Учебный план был актуальный, стек интересный, длина - год (по факту почти полтора), преподаватели - исключительно практики. Бонусом было 100 часов английского - на тот момент не знала его вообще, моим первым иностранным был французский. Курс назывался "Разработка программного обеспечения".

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

Первое и главное: корпоративный университет (даже если это базовая кафедра вуза, свой факультет и т.д.) - это всегда интерес компании. Фактически она готовит кадры для себя, и нужно быть готовым к тому, что на вас перенесут часть корпоративных стандартов. И если для студентов и молодых специалистов это шанс получить и практику, и работу, то взрослым специалистам такая "профильность" может мешать. Например, у нас С, С++ и Java превалировали над всеми предметами, а тот же Python прошёл почти мимо - мы на нём успели написать телепрограмму, турнирную таблицу матчей и календарь с рассылкой напоминалок на e-mail. Опять же, с точки зрения операционных систем нам дали только UNIX - правда, очень круто. Но об этом чуть ниже. 

Итак, минусы:

  • корпоративный интерес и корпоративный стек
  • профильные задачи на практике

Плюсы:

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

Группы сформированы неоднородно - видимо, руководство корпоративного университета рассчитывает на сознательность слушателей. В общем, у нас было 16 человек - 5 девушек, 11 парней, все разные: от нулевого уровня типа меня до высокого уровня профессиональных программистов (был С-шник и реально мощный тимлид 1С-овец). Закончили и защитились семеро, девушек - две. При этом перед поступлением проводится тестирование и собеседование для определения уровня английского языка и распределения по группам. А вот собеседование на уровень знания технологий - нет. 

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

А теперь про UNIX. И лекции, и практику вели сильнейшие парни, которые могли ответить на любой вопрос, как бы криво он ни был сформулирован. На практических занятиях на отстающих не забивали, а всей группой дотягивали того, кто запутался. Например, писали регулярки для девочки-дизайнера, разбирая с ней каждый элемент или сорок минут искали, почему у меня не компилился С-шный код в gcc (оказалось, в хедере была пропущена точка с запятой - классика). В итоге UNIX знали и сдали все, кто до него дожил, а я спустя полгода на раз-два прошла собеседование на позицию инженера по тестированию VoIP c кучей вопросов по командам bash.

Итак, минусы:

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

Плюсы:

  • разбираются самые нелепые и одновременно сложные вопросы
  • сильные, объясняя слабым, получают дополнительное развитие
  • появляется стимул рыться в литературе (правда, не у всех).

А теперь о самом главном - о преподавании языков программирования и сопутствующей ИТ-инфраструктуры. Задачи отдалены от практики. Мы моделировали полёт бомбы на С, на нём же считали многочлены, программировали решето Эратосфена и работали с рядами Фибоначчи. На С++ мы писали и развивали карточку студента вплоть до применения деревьев. В этих задачах были упущены такие вопросы как безопасность, сетевая работа, проектирование и т.д. Разработка на практике выглядит, конечно же, совершенно иначе. И возможно, курс был бы ещё интереснее, если бы из наших выживших остатков группы сколотили настоящий отдел - senior, джуниоры, тестировщики, менеджер проектов. Тогда может и больше народу дошло бы до конца.

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

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

Баги всегда рядом - стоит приступить к коду

Преподаватели демонстрируют код, пишут его в реальном времени на лекции, всем всё понятно, а самим написать - никак. Очень хорошей находкой было давать фрагменты кода, чтобы мы разбирались и отвечали, что он делает. Замечательная наша преподавательница по С/С++ называла это "думай, как компилятор". И это всем нравилось, было живо и местами задорно, хотя и не всегда получалось.

А вот что было по-настоящему неприятно - так это требование писать код на экзаменах и зачётах (да, они были!)…на листочке бумаги. Это вызывало ступор, трепет и блокировало мозги. То есть ты привык, что есть компилятор, что он твой помощник, что есть среда разработки, подсветка кода и тут - бац и ты уже пишешь на бумажке вот это:

#include <iostream> int main() { int i, fact=1, n; cin>>n; for (i=1; i<=n; i++)  {  fact=fact*i;  }  cout << fact;  return 0; }
Это в лучшем случае. С наследованием в С++ было гораздо веселее. Однако про листочек и код есть и вторая точка зрения - на собеседованиях нередко просят написать код или команду ручкой на бумаге, и специалист должен быть к этому готов. А вот правильно ли просить решить задачу с помощью языка программирования вне ПК - это уже тема отдельного обсуждения.

Кстати, про ООП - видимо, чтобы его объяснить, его нужно понимать просто без заминок. Честно говоря, нам на пальцах его так и не объяснили, самым приемлемым было определение "всё есть объект" (аналогично в UNIX мы слышали про "всё есть файл"). Сложные вещи и правда трудно объяснять, поэтому преподавателям стоит заранее формулировать краткие и ёмкие пояснения, чтобы слушатели запоминали эту "выжимку", а потом уже наращивали понимание предмета. Короче, с ООП у большинства не сложилось. 

ООП виделось именно так

Некоторые преподаватели были, что называется, "over qualified". Это умные и опытные тимлиды, для которых всё прозрачно и очевидно, поэтому они дают глубокий и качественный материал без основ - то есть фактически ничего, поскольку слушатели не включились в базу. Однако именно они транслировали практические ценности, рассказывали о продвинутых возможностях IDE (у нас были Visual Studio и Eclipse), открывали для тех, кто не знает, Хабр, книги Шилдта и Страуструпа. Кстати, что характерно, за почти полтора года обучения ни один преподаватель не произнёс слов "github" и "opensource". И это во многом было фатально - настолько, что даже наши решения и проекты ни у кого из нас почти не сохранились.

Под конец курса случилась особая форма извращения, которая называлась "Управление проектами". Мы радовались, думая, что перед дипломом (да, был настоящий проект с защитой на английском языке) нас разгрузили. Но вместо этого на нас обрушилась вся мощь UML-диаграмм. Выше тройки не получил никто, одна из девушек дошла почти до конца, но не сдала экзамены именно из-за этого предмета. Но с другой стороны, именно с этим малоприятным занятием пришло понимание целостности и связности программного проекта. Так что всё не зря.

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

  • Обязательно должны быть введены понятия репозитория, структуры проекта, разделения задач программистов на проекте (junior, middle, senior).
  • Важно показывать роль книг, специализированных сайтов и опенсорса в обучении - только трое из нас купили учебники, только у одного был живой прокачанный аккаунт на Хабре и Тостере. И конечно, нужно обязательно рассказать о существовании курсов MIT, CS50 на русском, доступных записей лекций технических вузов. Примочки типа codecademy тоже не станут лишними в практике программирования - преподаватель просто обязан знать свой арсенал и транслировать его слушателям.
  • На лекциях у каждого слушателя должен быть включён ПК - это золотое, даже платиновое правило. Одно дело смотреть на магию на проекторе, другое - повторять это перед собой и ковыряться в коде. Да, это займёт больше времени, но оно и эффективнее. Сейчас я опять же по доброй воле учусь в том же месте на потоке "Администрирования Windows Server" (RegionSoft CRM - продукт по большей части виндовый, и нужно хорошо знать инфраструктурное окружение проекта) и это очень круто - когда каждое действие, каждую команду мы отрабатываем на виртуалке, причём нередко в нескольких вариантах - например, настраиваем систему через GUI, средствами командной строки и через скрипты/командлеты Power Shell). Во-первых, подключаются все типы человеческой памяти, во-вторых, происходит дополнительное обсуждение косяков и успехов друг друга.

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

Как войти в айти

Способ первый - полное самообразование

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

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

  1. Определиться, зачем вам нужно программирование или администрирование - для развития мозгов, своего проекта, смены работы, эмиграции, для того, чтобы выйти на новый уровень в текущей деятельности. Исходя из этого нужно задать сроки и интервалы обучения.
  2. Выбрать, с чего начать. Здесь все средства хороши, но как ни парадоксально, удачнее всего начинать с приложений вроде codecademy или книги "Python для чайников". Это не испортит вам стиль (его ещё нет), но доступным языком погрузит в основы и даст попробовать код "на пальцах".
  3. Расширить круг читаемой литературы, начать работать в IDE. 
  4. Перестать бояться 127 ошибок в компиляторе, стать более внимательным к синтаксису.
  5. Начать работать со своим или опенсорсным проектом. До этого этапа мало кто доходит. Но если дошли, будьте уверены - всё сложится.

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

Способ первый модифицированный - самообразование + наставник в компании или стажировка

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

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

Способ второй - высшее образование (второе или дополнительное)

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

Способ третий - корпоративный университет

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

О самом главном - без чего не обойтись

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

  • Без непрерывной работы с кодом. Вы должны его писать, разбирать, искать пути оптимизации, просить критики в экспертных сообществах и уметь прислушиваться к ней (хотя вам скажут и про "вон из профессии", и про "руки из ж…", и про "говнокод". Это совершенно нормальный путь.
  • Без знания основ: позиционных систем счисления, устройства ПК, знания алгоритмов, работы с переменными, булевой алгебры, типизации и т.д. Большинство тех, кто хочет присоединиться к разработчикам, почему-то считают эти знания чем-то ненужным и погружаются сразу в готовые фрагменты кода, переделывая их и стряпая свой проект. Это неправильно - рано или поздно в проекте вы встретитесь именно с этими проблемами.
  • Без книг. Ни один гугл, Тостер, Stack overflow и ламповый форум SQL-щиков не заменит книг в плане глубины и основ. Конечно, в идеале это должны быть оригиналы книг зарубежных авторов, благо что сегодня на Amazon потрясающий ассортимент - от классического С до нейросетей и NLP (который natural language processing). Но и переводные издания радуют всё больше. Не бойтесь портить книгу - читайте её с карандашом, ручкой и чем угодно. И да, если в книге приведён код, то недостаточно его разглядывать - лучше воспроизвести его на ПК, скомпилировать, разобрать и вникнуть. От простого чтения кода пользы в разы меньше.
  • Без вопросов себе, преподавателю, гуглу, сообществу, наставнику. Идеальна схема выглядит так: слушаете лекцию, пишете базовые вещи, тут же отмечаете, что стоит изучить поглубже или узнать самому. На следующий день разбираете пометки, опять конспектируете самое важное. Затем практикуетесь в написании кода или, например, администрировании.
  • Без изучения сопутствующего окружения и ИТ-инфраструктуры. Да, можно написать небольшой сайт и даже разместить на нём, например, красивую галерею работ, но потолок придёт быстро, если вы не озаботились изучением вопросов нагрузки, безопасности данных, форм на сайте и т.д. Поэтому стоит изучать нужную технологию комплексно, захватывая остальные.

Это самая точная картинка об изучении программирования

  • Без рефакторинга. При всём старании вы никогда не создадите совершенный код с первого раза. И с десятого не сотворите, это даже у опытных разработчиков не всегда быстро выходит. Но работая с кодом, продумывая варианты оптимизации, вы становитесь профессионалом, который способен не просто накодить, а сделать ПО работающим и качественным. Не бойтесь код-ревью.
  • Без проектирования. Если вы садитесь писать код, но не знаете, что вы пишете и как это должно работать, то вы просто тренируетесь в запоминании синтаксиса языка. Попробуйте нарисовать схему будущего приложения, установите, какие компоненты каким образом будут взаимодействовать, пропишите особенности и фичи. Так вам легче будет собрать проект и заставить его в конце концов работать.
  • Без знания устройства вашей IDE (среды разработки). Все современные среды напичканы кучей возможностей типа автоматической генерации кода, подсветки, элементов управления и т.д. Обязательно разбирайтесь с возможностями, читайте документацию, обращайте внимание на то, как вводится код, как собирается проект, как работает компилятор и отладчик.
  • Без понимания того, что такое библиотеки и как они работают. Во время обучения преподаватели иногда нас троллили - например, однажды мы долго прописывали функции арифметических операций и факториала, а потом нам показали math.h. Для целей обучения - полезный, весёлый и поучительный урок. Для целей работы - трата сил, времени и размножение костылей. Многое придумано до нас - достаточно взять, подключить и научиться использовать.
  • А ещё без тестирования, DevOps, документирования и т.д. Но это продвинутый уровень - как правило, этим занимаются уже на работе.
  • Без английского языка. Но это вы и без меня знаете. На английском доступны материалы, которые способны дать мощный толчок развитию профессионала. Их перевод зачастую выглядит тускло. 

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


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=39382