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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

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

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

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

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

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

Плюсы:

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

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

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

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

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

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

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

#include 
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, обсуждать в комментариях. Но первый восторг сменяется реальностью: онлайн курс может быть лишь дополнением к собственным занятиям и оффлайновой работе в группе с преподавателем. Сам по себе он лишает возможности разобраться глубоко. Может быть, мне не хватало упорства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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