Сегодня многие романтизируют ИТ-сферу, стремятся попасть в неё и остаться в облаке славы, денег и всемирной известности. Конечно, всё не так, как кажется: разработка - это сложный интеллектуальный труд, отнимающий кучу времени. Но если вы всё же решились сменить профессию и войти в ряды айтишников, не промахнитесь со способом обучения.
Мы получили очередное сообщение от сотрудника с просьбой дать свободный микрофон. На этот раз речь пойдёт о программировании (и немного администрировании) как о дополнительном профессиональном образовании. Об опыте, проверенном на собственной шкуре и методах получения сакральных айтишных знаний, расскажет наша сотрудница, которая учится каждый год - не иначе, как завещал великий Ленин.
Привет, Хабр! Я работаю в РегионСофт уже 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 <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, обсуждать в комментариях. Но первый восторг сменяется реальностью: онлайн курс может быть лишь дополнением к собственным занятиям и оффлайновой работе в группе с преподавателем. Сам по себе он лишает возможности разобраться глубоко. Может быть, мне не хватало упорства.
Как войти в айти
Способ первый - полное самообразование
При кажущейся абсурдности абсолютно возможный способ. Главное - правильное мышление, усидчивость и огромное желание. Самообразование не должно быть хаотичным, стоит выбрать стек и начать заниматься в комфортном режиме: например, начать с часу или двух в день.
Единого алгоритма обучения не существует, но цепочка действий может быть такой:
- Определиться, зачем вам нужно программирование или администрирование - для развития мозгов, своего проекта, смены работы, эмиграции, для того, чтобы выйти на новый уровень в текущей деятельности. Исходя из этого нужно задать сроки и интервалы обучения.
- Выбрать, с чего начать. Здесь все средства хороши, но как ни парадоксально, удачнее всего начинать с приложений вроде codecademy или книги "Python для чайников". Это не испортит вам стиль (его ещё нет), но доступным языком погрузит в основы и даст попробовать код "на пальцах".
- Расширить круг читаемой литературы, начать работать в IDE.
- Перестать бояться 127 ошибок в компиляторе, стать более внимательным к синтаксису.
- Начать работать со своим или опенсорсным проектом. До этого этапа мало кто доходит. Но если дошли, будьте уверены - всё сложится.
Большое преимущество этого способа - ваша собственная мотивация, ваши собственные установки. Пока вы не работаете с кодом за деньги, это всего лишь ваше хобби - занимайтесь им в удовольствие. Даже если вы не смените работу и не станете программистом, вы совершенно иначе начнёте смотреть на разработку и на бизнес-процессы, изменится логика. Минус один - риск бросить всё на середине или в самом начале из-за недостатка мотивации, времени и интереса.
Способ первый модифицированный - самообразование + наставник в компании или стажировка
Отличается от первого способа тем, что кто-то в компании заинтересован в вашем развитии и готов выделить ресурсы или даже своё время на обучение секретам мастерства. Преимущество этого метода - в качестве, практической направленности и скорости обучения. А ещё люди склонны быстрее осваивать что-то новое, если это их работа и за неё платят деньги. Всё-таки правильная мотивация - великая вещь.
Отдельно стоит сказать о стажировках и обучении сразу в начале работы в компании. Это всегда удачный опыт и хороший способ адаптации персонала с одной стороны и источник знаний - с другой. Работу с такими компаниями всегда нужно использовать по полной - даже если вы не собираетесь долго задерживаться ( мнение автора здесь не совпадает с позицией компании ).
Способ второй - высшее образование (второе или дополнительное)
Да, можно взять и поступить в магистратуру или отпахать ещё несколько лет на вечернем специалитете. Это интересный процесс, освоение фундаментальных знаний и ноль практики. Она вся сводится к курсовым работам и отдельным контрольным с небольшими задачами. Плюсы - диплом государственного образца (пригодится, если вы собрались делать карьеру в гос. корпорациях или крупных компаниях) доступ к вузовской библиотеке, относительная дешевизна обучения и разнесённость во времени. Минусы - устаревший учебный план, формальность подхода, лишние предметы. Кстати, с преподавателями везёт по принципу 50/50, программы дополнительного образования и магистратуры стали в последнее время приглашать молодых преподавателей-практиков.
Способ третий - корпоративный университет
Хитрый способ, поскольку можно закончить обучение и заодно поменять работу. Вообще, откровенно говоря, наряду со стажировками - это один из способов обойти сотни резюме, стекающих в крупную компанию, и занять своё место. Но для этого нужно показать либо свои умения, навыки и опыт, либо стремление и способность обучаться. Плюсы - практически применимые знания, актуальная программа, удобное время занятий, режим диалога с преподавателем. Минусы - отсутствие диплома (только сертификат), разнородные группы, иногда не самый логичный учебный план, высокая цена и высокая нагрузка по времени.
О самом главном - без чего не обойтись
В любом случае, нет волшебной лекции или супер-чипа, который сделает вас специалистом. И знания в голову вам никто не вобьёт. Кроме самого обучения, есть вещи, без которых вы никогда не станете программистом.
- Без непрерывной работы с кодом. Вы должны его писать, разбирать, искать пути оптимизации, просить критики в экспертных сообществах и уметь прислушиваться к ней (хотя вам скажут и про "вон из профессии", и про "руки из ж…", и про "говнокод". Это совершенно нормальный путь.
- Без знания основ: позиционных систем счисления, устройства ПК, знания алгоритмов, работы с переменными, булевой алгебры, типизации и т.д. Большинство тех, кто хочет присоединиться к разработчикам, почему-то считают эти знания чем-то ненужным и погружаются сразу в готовые фрагменты кода, переделывая их и стряпая свой проект. Это неправильно - рано или поздно в проекте вы встретитесь именно с этими проблемами.
- Без книг. Ни один гугл, Тостер, Stack overflow и ламповый форум SQL-щиков не заменит книг в плане глубины и основ. Конечно, в идеале это должны быть оригиналы книг зарубежных авторов, благо что сегодня на Amazon потрясающий ассортимент - от классического С до нейросетей и NLP (который natural language processing). Но и переводные издания радуют всё больше. Не бойтесь портить книгу - читайте её с карандашом, ручкой и чем угодно. И да, если в книге приведён код, то недостаточно его разглядывать - лучше воспроизвести его на ПК, скомпилировать, разобрать и вникнуть. От простого чтения кода пользы в разы меньше.
- Без вопросов себе, преподавателю, гуглу, сообществу, наставнику. Идеальна схема выглядит так: слушаете лекцию, пишете базовые вещи, тут же отмечаете, что стоит изучить поглубже или узнать самому. На следующий день разбираете пометки, опять конспектируете самое важное. Затем практикуетесь в написании кода или, например, администрировании.
- Без изучения сопутствующего окружения и ИТ-инфраструктуры. Да, можно написать небольшой сайт и даже разместить на нём, например, красивую галерею работ, но потолок придёт быстро, если вы не озаботились изучением вопросов нагрузки, безопасности данных, форм на сайте и т.д. Поэтому стоит изучать нужную технологию комплексно, захватывая остальные.
Это самая точная картинка об изучении программирования
- Без рефакторинга. При всём старании вы никогда не создадите совершенный код с первого раза. И с десятого не сотворите, это даже у опытных разработчиков не всегда быстро выходит. Но работая с кодом, продумывая варианты оптимизации, вы становитесь профессионалом, который способен не просто накодить, а сделать ПО работающим и качественным. Не бойтесь код-ревью.
- Без проектирования. Если вы садитесь писать код, но не знаете, что вы пишете и как это должно работать, то вы просто тренируетесь в запоминании синтаксиса языка. Попробуйте нарисовать схему будущего приложения, установите, какие компоненты каким образом будут взаимодействовать, пропишите особенности и фичи. Так вам легче будет собрать проект и заставить его в конце концов работать.
- Без знания устройства вашей IDE (среды разработки). Все современные среды напичканы кучей возможностей типа автоматической генерации кода, подсветки, элементов управления и т.д. Обязательно разбирайтесь с возможностями, читайте документацию, обращайте внимание на то, как вводится код, как собирается проект, как работает компилятор и отладчик.
- Без понимания того, что такое библиотеки и как они работают. Во время обучения преподаватели иногда нас троллили - например, однажды мы долго прописывали функции арифметических операций и факториала, а потом нам показали
math.h. Для целей обучения - полезный, весёлый и поучительный урок. Для целей работы - трата сил, времени и размножение костылей. Многое придумано до нас - достаточно взять, подключить и научиться использовать. - А ещё без тестирования, DevOps, документирования и т.д. Но это продвинутый уровень - как правило, этим занимаются уже на работе.
- Без английского языка. Но это вы и без меня знаете. На английском доступны материалы, которые способны дать мощный толчок развитию профессионала. Их перевод зачастую выглядит тускло.
Но вообще самое трудное даже не начать. Самое трудное - продолжить, если не получается, не отшвырнуть в отчаянии. Как минимум, обучение вам обязательно пригодится - иногда в такой момент, когда вы даже не предполагаете. Так что не останавливайтесь ни на минуту.