Приходите к нам учиться
и корова и волчица.
Вас обучат и взбодрят
наши "Курсы поварят"!

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

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

Также к плюсам "быстрых" курсов можно отнести отсутствие необходимости вдаваться в теоретические глубины и на этом сэкономить то нервное напряжение, которое потребуется для вдумчивого погружения в теорию.

В результате имеем:

Соответствие желаниям обучающихся.
Большие финансовые поступления.
Меньшее напряжение нервной системы.

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

Почему вообще возникла такая волна желающих отдать деньги за обучение? Понятно, что людей манит зарплата, но она не появляется из воздуха и её источники стоит понимать. Исследователи обещают нам рост спроса на связанные с IT специальности на 97 миллионов к 2025 году. Это около 1.3% мирового населения. В то же время, эти же исследователи обещают сокращение более традиционных рабочих мест на 85 миллионов к тому же сроку. То есть 12 миллионов рабочих мест останутся незаполненными даже если все освободившиеся от традиционных работ люди "войдут в IT". И этот тренд возник далеко не вчера, но существует уже десятки лет, ведь автоматизацию придумали очень давно. Поэтому спрос на обучившихся будет, и этот спрос будет уверенно расти.

А теперь давайте всё же подумаем о подводных камнях. У любой лёгкости обычно есть обратная сторона, которая иногда может нас очень сильно разочаровать.

Та же самая статистика говорит нам, что в 2020 году услугами on-line образования воспользовались 180 миллионов человек. Много это или мало? Сравним эту цифру с количеством людей, теряющих работу к 2025-му году (85 млн.). В результате мы видим, что прошедших on-line обучение уже сегодня в разы больше, чем ожидаемое сокращение рабочих мест к 2025-му году. С одной стороны, это означает, что старая истина "спрос рождает предложение" вполне работает и в нашу эпоху. Но раз есть сотни миллионов желающих обучаться новой специальности, значит и спрос на готовых специалистов скоро должен быть удовлетворён. Хотя пока ситуация отличается от ожидаемой. Это говорит нам о потребности в качественных кадрах, а сотни миллионов дают лишь количество, которым все дыры не закроешь.

Раз есть разница в спросе на качество, то мы могли бы сравнить, как сложится судьба выпускников "быстрых" и "медленных" курсов при наличии запроса на качество.

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

Правда стоит отметить, что недостаточно грамотные работники тоже нужны, ведь на них можно переложить простые, но рутинные задачи, которыми более грамотные сотрудники заниматься не хотят. Или по другому (с точки зрения бизнеса): неэффективно загружать высокооплачиваемого сотрудника такой работой, которую сможет сделать низкооплачиваемый. Конечно, такая ниша создаёт спрос и на выпускников "быстрых" курсов. Но если мы зададимся вопросом, кому будет легче и приятнее работать, тому, кто занимается рутиной, или тому, кто отдал рутину другим, а сам занимается творческими задачами? То, даже с учётом всех плюсов «быстрого» образования, результат многим не понравится.

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

Итак, имеем такой список недостатков «быстрых» курсов:

1. Необходимо выполнять неинтересные и рутинные задания.

2. В следствии пункта 1 финансовая выгода существенно сокращается.

3. В следствии пункта 1 возможность осваивать перспективные направления на работе практически исключается.

4. В следствии пункта 3 вы застреваете в очень неудобном положении с весьма рискованными перспективами замены на робота.

Все эти проблемы характерны для тех, кого в разработке IT систем называют "кодерами", что означает людей, выполняющих простую шаблонную работу. Разумеется, на таких кодеров возлагаются только вспомогательные задачи. В следствии же насыщения рынка такой категорией разработчиков среди них очень сильна конкуренция. Приблизительно оценить масштаб этой проблемы может каждый, кто пытался устроиться программистом уровня "джуниор" (от английского junior, что означает "младший" или "моложе", является заимствованием, постепенно вытесняющим слово «кодер»). С таким уровнем подготовки устроиться на работу непросто. Но именно такого уровня специалистов готовят большинство курсов. Как можно ожидать улучшений в этой области, когда огромное количество выпускников "быстрых" курсов (вспомним про 180 миллионов выпускников) будет стучаться в те же организации, куда рассылаете своё резюме и вы?

Из этого вытекает ещё один "скромный" недостаток: вместо быстрой финансовой выгоды после окончания "быстрых" курсов многих ожидает вообще отсутствие какой бы то ни было выгоды.

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

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

Для понимания ситуации приведём список ограничений типичного "быстрого" курса:

1. Студент должен познакомиться с часто используемыми инструментами в таком объёме, что бы у него не возникло мыслей о недостатке его знаний, чем курс и мотивирует учащихся. Для этого достаточно одного перечисления длинного списка названий широко используемых компонентов и их составляющих с некоторыми краткими пояснениями. И если студент не увидел за этими огромными деревьями леса, то и никаких недостатков он тоже не увидит. По сути, студента вводят в заблуждение относительно его уровня, а способ – перечисление непонимающему предмета большого количества известных названий без какой-либо серьёзной системы.

2. Выбор инструментов при таком перечислении не обоснован, то есть весьма произволен и подвержен влиянию моды. Но оправдание всегда очень простое - читайте требования в вакансиях. А там чего только нет, включая и выбранные инструменты. В итоге после непродолжительного периода "хвост начинает вертеть собакой", а модные инструменты вытесняют эффективные из-за того, что под них легче найти работников. Но работников какого уровня?

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

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

Перебрав некоторое количество доступных вариантов мы нашли лишь один более или менее полноценный вариант. Посмотрим, как он выглядит. Он включает более двухсот модулей (jar библиотек) общим объёмом около 100 мегабайт. Задумайтесь на секунду - 200 модулей. И если будет нужно, где-то в них мы должны внести свои изменения. Правда стоит сказать, что плотность переиспользования кода в современных системах оставляет желать лучшего, что означает отсутствие необходимости знать наизусть все 100 мегабайт этих библиотек, но, как минимум, мы должны представлять, что каждая из двухсот делает "вообще". Если бы мы этого не представляли, то, например, запустить систему мы бы наверняка смогли, но вот куда копать, если нужно что-то изменить, мы бы плохо представляли. А изменения реально были нужны.

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

Теперь представим на нашем месте выпускника "быстрых" курсов по Java. От таких курсов обычно студенты получают некоторое знание синтаксиса языка, набор базовых алгоритмов, представление о сервере, о взаимодействии с внешним миром, о базах данных, и вдобавок о нескольких часто использующихся библиотеках (их принято называть английским словом framework, что по русски означает "каркас", "скелет", "основа"). И вот, выпускник курсов, теоретически "знающий", например spring-framework, получает на вход задачу по доработке выбранной open-source системы. Да, в ней есть десяток модулей из spring-framework. Но кроме них там ещё 200 других модулей. И о них выпускник курсов ничего не знает. И как быть? Да и сами имеющиеся модули spring-framework далеко не факт, что были изучены недавним студентом.

Теоретически можно предположить, что выпускник курсов сможет взять на себя хотя бы простого веб-клиента. Для этого из всего серверного хозяйства нужно бережно выделить именно ту часть, которая отвечает за взаимодействие с браузером. И окажется, что веб-клиент там, на самом-то деле, просто отсутствует. Точнее там есть условная "консоль" для администрирования сервера. А реализована она так - в консольной утилите curl (знаком ли выпускник с подобными словами?) руками вводим текст запроса (текст "машиночитаемый", то есть у него строгий формат и ошибаться ни в одном символе нельзя), вызываем сервисы на стороне сервера, которые что-то меняют в конфигурации. И это всё. А нам нужен полноценный клиент, предоставляющий сервис не только для администраторов, а, главное, для пользователей, что бы они, поменяв свои настройки, получали определённым образом фильтрованную и доработанную информацию. И представим, что такую работу будет делать выпускник полугодовых курсов, знания которого были намеренно ограничены для сокращения времени обучения. Для понимания вспомните в своей жизни пример взаимодействия с неудобным и плохо работающим веб-сайтом. Вот примерно так оно в итоге и получилось бы.

Есть ещё вариант. Можно начать искать готовый веб-клиент. А потом неким образом интегрировать его с сервером. Но даже тогда мы не освобождаемся от кучи задач по доработке как клиента, так и сервера. Но вдобавок получаем ещё и все прелести интеграции разнородных систем, плюс удвоенные усилия на изучение чужого творчества. Что здесь могут предложить выпускники "быстрых" курсов? Очень просто - они предложат готовый шаблон, который видели на курсах. Скорее всего это будет что-то вроде "поднимаем очередь (с каким-нибудь модным названием), деплоим клиента туда, потом сюда, ну и обмениваемся сообщениями!", и это если на курсах вообще говорили про очереди. Да, в абстрактной постановке и без учёта деталей оно может выглядеть вот так просто, но в реальности добавляется ещё одна задачка для нашего выпускника - работа с очередями со всеми тонкостями и нюансами. Хорошо, если на курсах разбирали хоть один похожий пример, но весь ассортимент задач там точно никто даже не пытался разобрать. Только мы не будем уходить в сторону очередей хотя бы потому, что у нас ещё и на железо есть некоторые ограничения, а ставить туда кучу взаимодействующих систем означает заметное повышение ценника. И хорошо, что мы не вдавались в вопросы прикручивания бульдога к носорогу, потому что в нашем случае всё решилось при помощи гораздо более простой системы, с на порядок меньшим количеством модулей на все задачи. А если бы мы послушали нашего выпускника, то вместо более 200 модулей, вполне возможно имели бы все 500 в виде зоопарка сложно связанных друг с другом систем. А потом бы обнаружили, что при накидывании на каждом этапе сотен миллисекунд (в оптимальном случае) и количестве этапов эдак штук десять, только на перекладывании из системы в систему время ожидания конечным пользователем увеличивалось бы на несколько секунд, и, не поменяв архитектуру, его было бы невозможно сократить. То есть пользователь платил бы своим временем исключительно за проблемы проектирования, основанного на советах недавнего студента.
Сразу стоит признать, что я не исключаю такого маловероятного явления, как очень грамотный выпускник "быстрых" курсов. И даже может быть такой выпускник действительно сможет сделать приличное решение для клиентов. Но стоит только задуматься о вероятности такого исхода, как сразу становится понятным, за что фирмы платят большие зарплаты действительно грамотным специалистам.

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

А теперь соберём выводы из сказанного. Для устройства на высокооплачиваемую должность разработчика необходимо продемонстрировать умение:

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

2. Разбираться с готовыми системами до таких деталей, которые позволят вносить любые изменения по требованию бизнеса, обеспечивая необходимую надёжность.

3. Заниматься оптимизацией узких мест в системах до состояния, когда производительность улучшается в разы, а то и на порядок-другой.

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

5. Обеспечить всё перечисленное для систем с сотнями, а то и тысячами отдельных компонентов.

Хочется надеяться, что по пунктам 2,3,4,5 читатели увидели обоснование в приведённом выше примере из практики. А вот по пункту 1, который некоторым может всё ещё казаться неочевидным, стоит сказать ещё пару слов. Глубина понимания нужна для вывода частностей из общих принципов. Так, например, какой-нибудь spring-framework считается практически обязательным для обучающихся на курсах по разработке на Java, но там никогда не дадут таких знаний, которые позволили бы осваивать не только эту, но все ей подобные библиотеки, скажем, за пару недель, максимум - месяц. И не в базовом объёме (обычно на курсах изучают лишь малую часть spring-framework), а всё многообразие его компонентов. На это многообразие и нужны две недели, а для освоения чего-то менее сложного (количественно), грамотному специалисту может хватить и пары дней, и даже иногда пары часов. Почему грамотный специалист способен так быстро всё осваивать? Только потому, что он обладает глубоким пониманием всего происходящего внутри информационных систем. А все модные библиотеки, включая spring-framework, всего лишь предлагают частные пути решения абсолютно стандартных задач, общие подходы к решению которых специалист давно и хорошо знает. Поэтому он смотрит не на детали реализации, не на отдельные классы или методы, а на схемы применения предлагаемых компонентов в реальной жизни. И все вариации далее можно обобщить очень просто - одни и те же схемы реализуются лишь с точностью до предпочитаемого автором библиотеки стиля. Повторю – в том числе и spring-framework, это лишь стиль, но ни в коем случае не какое-то откровение или открытие. Хотя не буду спорить, ряд полезных вещей там есть (но без придыхания и восторгов). То же самое относится и к подавляющему большинству других библиотек, хоть на стороне сервера, хоть на клиенте (в любом виде, включая и браузеры, и мобилки, и настольный софт). Из чего следует очередной простой вывод - для понимания библиотеки нужно лишь абстрагироваться от стиля её автора. И в результате часто бывает так, что кроме стиля в библиотеке вообще ничего полезного нет. То есть некто сделал свой личный вариант очередного, давно известного миру велосипеда. А понять это всё можно только лишь обладая глубокими знаниями о работе информационных систем.

Прольём свет на также важный вопрос, как можно не понять очень простые вещи, если у вас нет базы. Допустим, что вы не знаете алгебру. И вам кто-то пытается что-то объяснить, показывая уравнения с X, Y и ещё каким-то математическим символом. Средний школьник класса после 6-го вполне способен понять такие объяснения, но вот в 3-м или 4-м классе - нет, не способен. Потому что он не знает алгебру. А для понимания вашего пояснения он должен за то короткое время, пока он вам окончательно не надоел, успеть в уме вывести базовые принципы алгебры с её символьным обозначением множества допустимых вариантов, с её правилами преобразования формул, со всеми этими переносами, подстановками и прочими манипуляциями. Но такой трюк абсолютно нереален для любого человека. И только обучение в последующих классах, которое длится годами, позволяет как школьнику, так и всем вам, читатели, понять, о чём вообще идёт речь. А на курсах по программированию ситуация точно такая же - если нет понимания основ, то далее можно работать только на уровне каменьщика, кладущего стандартную стену из стандартных кирпичей по заученному однажды сценарию. Шаг влево или вправо - всё, сценарий перестаёт работать.

Также хочется заметить, что глубина понимания не обязательно относится только к сложным технологиям или взаимодействию сложных компонентов. Это скорее "ширина", или кругозор специалиста. А глубина определяется теми деталями, до которых специалист способен опуститься внутрь системы и не потерять способность хорошо разбираться в найденном внутри. Это всё обязательно пригодится при работе как со сторонними системами, так и при разработке своих. Но где конкретно находится граница, дойдя до которой в глубинах, следует наконец остановиться? Видимо, отвечая на такой вопрос, никогда не стоит указывать точные пределы. Для примера возьмём операции с битами. Вроде бы, ну кому они нужны в наш век террабайтных размеров памяти и прочих неограниченных ресурсов? Но возьмём элементарный пример из исходных текстов самого массово используемого в Java класса - String. Заглянем в метод split:

public String[] split(String regex, int limit) {
/* fastpath if the regex is a
(1)one-char String and this character is not one of the
RegEx's meta characters ".$|()[{^?*+\", or
(2)two-char String and the first char is the backslash and
the second is not the ascii digit or ascii letter.
*/
char ch = 0;
if (((regex.value.length == 1 &&

".$|()[{^?*+\".indexOf(ch = regex.charAt(0)) == -1) ||
(regex.length() == 2 &&
regex.charAt(0) == '\' &&
(((ch = regex.charAt(1))-'0')|('9'-ch)) < 0 &&
((ch-'a')|('z'-ch)) < 0 &&
((ch-'A')|('Z'-ch)) < 0)) &&
(ch < Character.MIN_HIGH_SURROGATE ||
ch > Character.MAX_LOW_SURROGATE))
{
... ... ...

Кто из выпускников курсов по Java сможет рассказать, как здесь реализована оптимизация для простых случаев? А может здесь ещё и ошибка есть?

Этот пример приведён потому, что грамотному специалисту всегда будет нужно разбираться в чужом коде. И там вы можете встретить каких угодно монстров. А попадутся они вам даже в самом массово используемом классе в Java, что уж говорить про какие-то другие библиотеки.

Вообще, по теме разбора кода, можно сказать много интересного, но не в этой статье. А здесь я ограничусь лишь ссылкой на разбор кода с помощью программы (используя Reflection API), что бы показать небольшой, но уже сложный фрагмент знаний, который может от вас потребоваться в будущем.

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

1. Курсы должны давать универсальные знания, из которых легко выводятся частные случаи.

2. Курсы должны показывать учащимся, как использовать универсальные знания для перехода к частностям.

3. Курсы должны знакомить учащихся с часто используемыми технологиями, но только после пунктов 1 и 2, одновременно ставя задачу на разбор студентом выбранной технологии до малых деталей, изученных на курсе.

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

5. Итогом курсов должна стать курсовая работа, где выпускник продемонстрирует полностью самостоятельное решение задачи для существующей сложной системы, трудоёмкостью около недели (5 дней по 8 часов). Без такого решения выпускнику нечего будет показать работодателю в качестве доказательства своих умений.

Вот такие мысли появились после создания, как мне кажется, более качественного курса, нежели большинство широко известных, для освоения экосистемы Java (все её стороны, и сервера, и клиенты, и то, что между ними). Но рынок неумолим, большинство всё равно пойдёт на "быстрые" курсы. Это и реклама, и недостаточная грамотность, да и просто вредные привычки или нежелание думать. И всё-таки у меня остаётся надежда на прорастание ниши качественного обучения. Как оно будет на самом деле - посмотрим. Одно наблюдение позволяет смотреть в будущее с оптимизмом - людям хочется развиваться. Не всем, но я вижу тех, кто даже на очень хлебном месте не останавливается и ищет чего-то нового. Быть может, за такими людьми будущее.