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

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

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


Привет, Хабр! Я работаю в РегионСофт уже 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, документирования и т.д. Но это продвинутый уровень — как правило, этим занимаются уже на работе.
• Без английского языка. Но это вы и без меня знаете. На английском доступны материалы, которые способны дать мощный толчок развитию профессионала. Их перевод зачастую выглядит тускло.

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

---

Если вы любите IT и вам интересно получить работу в компании RegonSoft — мы с радостью рассмотрим вашу кандидатуру, независимо от наличия свободных вакансий.

Нам интересны специалисты в области разработки IT-решений и техподдержки с широким стеком технологий, а также опытные продажники. Звоните +7 (499) 709-81-41 (Москва), +7 (831) 233-13-03 (Н.Новгород) или присылайте резюме на почту personal@regionsoft.ru