На прошлой неделе прозвучала команда «встряхнуть вузы», а то они «закостенели до неимоверности». Понятно, что вряд ли это «встряхивание» выйдет за рамки идеологического и приобретет форму, например, актуализации программ и подходов. Тем не менее devby.io спросил у студентов и выпускников техвузов, где искать реальное «закостенение». Издание получило много острых реакций, но пока публикует самый насыщенный монолог.
Арсений (имя изменено) — заочник БГУИР и Senior Software Engineer
— Диплом специалиста я получил довольно давно (и по гуманитарному профилю). Программированию учился самостоятельно, уже не первый год работаю по своей новой специальности.
В БГУИР пришел, имея уже достаточный опыт работы в качестве программиста. Достаточный для того, чтобы большинство преподавателей избегало со мной разговора по существу изучаемого предмета, стыдливо оправдываясь. Благо что и возраст мой заставляет их вести себя со мной более-менее на равных.
Как «пользователь», могу сказать, что качество образования в БГУИР очень низкое. Радует, что я учусь на заочке и меньше времени теряю впустую. Программы очников и заочников не отличаются ничем, экзамены одинаковые, предметы, сроки обучения и требования — те же. Иногда за семестр надо сдать чуть меньше лаб, чем очникам, но далеко не всегда.
Недостатки образования, на мой взгляд, следующие.
1. У преподавателей в основном нет практического опыта
Самая существенная проблема — технологии преимущественно преподаются людьми, не имеющими опыта практической работы с этими инструментами или практического опыта за пределами университета вообще.
Человеку, который за свою жизнь не видел исходный код приложения, не считая курсовых проектов своих студентов, непросто объяснять паттерны асинхронной коммуникации и давать своим ученикам какой-нибудь message broker.
Люди, которые не работали программистами на настоящих корпоративных проектах (тот самый Enterprise, который хочет автоматизировать свои сложные бизнес-процессы и кормит большую часть .NET- и Java-разработчиков), а видели только учебные проекты, с трудом представляют себе, что такое приложение на тысячи (десятки тысяч) файлов.
Большая часть паттернов разработки, подходов в объектно-ориентированном программировании, архитектурных принципов — это готовые решения проблем, которые возникают в ходе создания, поддержки и рефакторинга именно таких больших проектов. То есть это решения проблем, с которыми преподаватель, скорее всего, никогда в жизни не сталкивался, и он очень слабо представляет себе реальный контекст и особенности применения того или иного решения.
Это же касается и многих инструментов, например — message broker системы. Это брокеры сообщений, которые позволяют приложениям обмениваться информацией между собой и своими модулями под большой нагрузкой (сотни тысяч сообщений в секунду). Естественно, создать в учебном проекте условия, при которых какой-нибудь message broker будет приносить пользу и решать какую-нибудь проблему, а не только усложнять систему, — довольно сложно. И это почти невозможно сделать человеку, который сам не понимает, зачем в действительности этот message broker нужен.
Преподаватель не может объяснить, как пользоваться тем или иным инструментом, потому что сам не понимает, какую проблему этот инструмент решает. Ведь чтобы столкнуться с этой проблемой, надо быть профессиональным программистом, а не преподавателем. Hello World из туториала он дать, конечно, может (как правило), но вот комплексного понимания проблемы у преподавателя за редким исключением нет.
По отдельным дисциплинам изучение сложных технологий сводится к написанию реферата / отчета / какой-нибудь еще бумажки — главное, чтобы было содержание, много текста и все это в папке-скоросшивателе.
Конечно, качество преподавания конкретной отдельно взятой дисциплины зависит от отдельно взятого преподавателя, но в среднем по больнице пациент скорее мертв, чем жив.
Разумеется, все можно выучить самому. Но в таком случае у меня вопрос, а зачем эти люди получают зарплату?
2. У связанных дисциплин — несогласованные между собой программы, а их преподаватели не коммуницируют друг с другом про общие задачи
И даже если преподаватель — настоящий энтузиаст, работающий в универе на полставки сеньор или тимлид, то все равно есть и другая проблема, которую он в рамках своей дисциплины преодолеть не сможет, — учебная программа.
И я говорю не о перечне тем конкретной дисциплины (преподаватели обладают достаточной автономностью, чтобы протащить в свой предмет что угодно без лишних заморочек — было бы желание и понимание, что надо тащить). Я говорю об учебной программе целиком.
На первый взгляд, если изучить учебный план любой технической специальности, программа вроде бы составлена логично и последовательно. Но это только если не копать глубоко. А так, посмотреть на названия предметов и предположить, что люди, которые читают эти лекции, хоть раз в жизни обсуждали между собой, кого и чему они учат и чему же должны научить.
На практике связанные между собой дисциплины имеют абсолютно несогласованные между собой программы — они могут почти полностью дублировать друг друга или идти в очень странном порядке.
Есть, например, специальность бакалавриата, где 11 дисциплин в той или иной степени связаны с программированием, при этом пять из них завязаны на один язык программирования, что вроде бы звучит хорошо, появляется некоторая специализация.
Но есть ощущение, что предметы разбросаны по учебному плану с помощью рандомайзера: студенты должны писать полноценные веб-приложения с бэкендом и UI, но только в следующем семестре они знакомятся с базовым фронтендом. Работа с базами данных может быть в программе после того, как учащимся надо было написать бэкенд для какой-нибудь информационной системы и сдать его в виде курсового проекта. То есть преподаватель уже должен требовать от студентов писать код для взаимодействия с базой данных, но что такое SQL — им расскажут только в следующем семестре.
А упомянутые выше пять дисциплин по одному языку программирования вообще три раза заставляют студентов проходить один и тот же наиболее популярный в этой экосистеме фреймворк.
И не то чтобы это некий итеративный подход со все большим погружением на каждом проходе — совсем нет. Ребята просто три раза учат Hello World и делают одни и те же действия, полезность которых стремится к нулю. Складывается такая ситуация потому, что преподаватели каждой из дисциплин никак не взаимодействуют между собой и вставляют в свой предмет то, что считают нужным, возможно даже руководствуясь самыми лучшими побуждениями. Но вот получаем мы то, что получаем.
Почему нельзя составить единую программу по какому-нибудь .NET и распределить ее между этими пятью дисциплинами, чтобы студенты последовательно погружались во все аспекты языка и сложившейся вокруг него экосистемы? Это остается загадкой для всех, включая преподавателей этих дисциплин.
Хотя возникает вопрос, а может ли кто-то из них в самом деле сказать, что действительно должен знать и уметь некий Junior/Middle {название технологии} Software Engineer, чтобы быть востребованным на рынке?
3. В итоге низкий уровень подготовки студентов, которых учат писать код, но не программы
Об уровне подготовки студентов я могу судить по собеседованиям, на которые приходит множество вчерашних студентов БГУИР.
Абсолютно бессистемные знания, поверхностное понимание технологий, с которыми они должны работать, и т.д.
Как правило, пришедший «с улицы» условный «Александр, 32 года, 10 лет работаю машинистом поезда, учил все сам на ночных сменах и сходил на полугодовые курсы» будет знать свой стек лучше и глубже, чем тот же условный «Леша, 20 лет, третий курс, иду на красный диплом» из нашего любимого БГУИР.
И абстрактный Александр, может, и не знает, как выглядят системные вызовы операционной системы, но это его в целом роднит с 95% других, в том числе опытных Python/Java/JS-… программистов, войти в число которых он и стремится. Да и код писать он будет, как ни странно, лучше, чем его конкурент из БГУИР.
И проблема не в том, что наш студент Леша что-то не может или не хочет. Проблема в том, что Леша писал код четыре года, делая лабы, и вместо адекватного фидбэка от программистов, у которых кровь из носа пошла бы от Лешиных лабораторных и списка устаревших библиотек, которые он использует для решения давно решенных проблем, — получал свои 9−10 баллов за вовремя сделанную лабу и в целом работающий код.
Но в реальной жизни проблема же не в том, чтобы написать код, понятный компьютеру. Проблема — написать код, понятный человеку. Вначале Леша должен был научиться этот код писать без грубых ошибок, потом — писать его чисто и понятно, позже — писать его расширяемым. И делать понятной уже не функцию или метод, а дизайн своей системы целиком. Но учить его этому было некому, и остался наш Леша на уровне «писать код без грубых ошибок».
Так что писать код он, может, и научился, но вот писать программы его учить в университете было некому.
Идеология
С идеологией и прочим я вообще не столкнулся. Возможно, потому что заочка. Но наслышан о том, как подбирают преподавателей.
[Слышал о кейсе, когда одного специалиста] приглашали на 0,25/0,5 ставки преподавать в БГУИР. Руководство факультета было очень заинтересовано, да в целом это была их инициатива — поэтому они пошли навстречу по всем вопросам, дали переписать программу, расписание выбирать и минимальную загрузку по парам оставить, на которую он был согласен (не больше одного вечера в неделю — по две пары за раз).
Когда дело дошло до заявления на прием на работу, его попросили «не указывать свой номер телефона, если пользовался им в 2020 году», — написать другой или завести новый. Сказали, что по номеру проверяют, чем человек занимался во время протестов, — и лучше всех этих проблем избежать. Но закончилось все тем, что проректор по безопасности не допустил этого человека к преподаванию — он, мол, имеет деструктивные взгляды.
Сроки обучения стоит сократить? И да и нет
Каково мое мнение о том, что срок обучения в вузах стоит сократить? Скажу так: после полугодовых курсов в тренинг-центре EPAM людей разбирали, буквально отрывали с руками и ногами, несмотря на их дипломы (или их отсутствие).
Если специалистов готовить так же сфокусированно и еще более комплексно в течение двух лет, будет интересно посмотреть на этих Uber-солдат? Мой взгляд на этот вопрос — подготовить «специалиста» можно за два года на фул-тайм, и он будет просто суперинженер. Но у него не будет высшего образования.
Другой вопрос, надо ли оно этому специалисту?
Высшее образование — это прежде всего университет, а не профессиональное училище. Тут наукой должны заниматься: не только знания потреблять, но и уметь их производить, расширять границы известного. Разумеется, для этого нужен кругозор — не только технический широкий (то есть быть тем самым специалистом), тут и без какой-нибудь фундаментальной философии и методологии науки уже будет движение вслепую, я уже не говорю про математику и прочее.
Не думаю, что таких людей нужно настолько много, сколько сейчас готовят наши вузы. Но они нужны. И таких людей должно быть явно больше, чем у нас есть в реальности.
Так что если говорить о том, надо ли готовить инженера-программиста 4−5 лет, — однозначно нет, хватит и 2−3. Можно ли дать высшее образование за такой срок — тоже нет: надо больше времени и другой фокус в обучении.
В практической плоскости интересен опыт EPAM в этом плане. Слышал, они открыли свои программы бакалавриата и магистратуры в Литве и Украине, готовят людей под потребности рынка: если это инженер — у него есть бэкенд-язык, профильный, клауд, инфраструктура и т.д., в общем, весь актуальный стек с нужной глубиной. В магистратуре вроде были архитектура и деливери-менеджмент. За развитием этого процесса не следил, просто однажды увидел новость и порадовался за будущих коллег, у которых будет возможность получить, уверен, отличное техническое образование.
Обидно только, что в числе университетов-партнеров не было ни одного вуза из Беларуси.
Читайте также на devby.io:
7 отличных курсов по финансам. Уплыть «с галеры» и основать свой стартап
Самые популярные курсы программирования на DataCamp у белорусов со скидкой 65%
Мечтаете создать собственную игру? Собрали классные курсы по геймдеву всего за 9,99 доллара