Несколько наблюдений для изучающих программирование

Что значит программировать, почему не понимают этот процесс? Почему мотивация не нужна? Наслоение и ненамеренный снобизм, или почему сложно и непонятно?

Постарался выбрать не самые банальные вещи, руководствуясь тем, может ли незнание о них иметь долгоиграющие последствия. У меня есть канал - https://t.me/tobeprog , там о методах обучения и обзоры на уч.материалы.

Утрированный пример - есть менеджер ничего не понимающий в разработке, при этом стоящий над разработчиком(так быть, разумеется, не должно). Как он видит процесс работы программиста?

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

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

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

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

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

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

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

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

Это настолько естественная штука, даже странно о ней писать. Вообще, способ единственный, по другому, просто не получится. То разделение, о котором ниже - очень искусственное, но мне кажется, так проще объяснить.

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

Какого-то строго перехода/переключения, с одного уровня на другой - нет(понимание придет на практике). Главное помнить - этап планирования происходит постоянно, он не заканчиваться блок схемой/псевдокодом, он параллелен написанию кода.

Похоже на работу какого то предприятия. Вы, как начальник, видите цель, отдаете приказы, смотрите как все в совокупности работает/эффективность, что-то меняете/убираете/оставляете, ищете более экономный/быстрый/правильный способ. И одновременно с этим, как рабочий, с энтузиазмом реализуете все что начальнику придумалось. И как на предприятии, оба процесса идут одновременно и не прекратятся, пока цель не будет достигнута(или рабочий день не закончится).

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

Возьмем того же Свейгарта[Автоматизация рутинных задач с помощью Python]. Прозвучит смешно, но когда новичок видит, что сам может написать программу, которая заполняет осточертевшую таблицу в exсel, или сама играет в динозаврика в Google Chrome, он словно получает суперспособность. Оказывается, эта жужжащая кулером коробка, вполне подвластна, и позволяет делать невероятные вещи, но почему то об этом мало кто знает.

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

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

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

Если книга(или курс) по вводу больше напоминает справочник, она просто не предназначена для новичков. Это не значит что материал должен быть поверхностным, идеальный вариант - когда хочется преодолевать трудности, что бы узнать, что будет дальше. Хороших книг/курсов много, если скучно - лучше сразу менять, а не искать "призрачную" мотивацию.

Кратко - побочка индустрии. Индустрия развивается так быстро, потому что технологии как бы наслаиваются друг на друга. Знания тоже, выучиваешь одно, на его основе второе, третье и так до бесконечности. Ко всему прочему, программирование - ремесло. Сложно вспоминать проблемы с основами ООП, когда они погребены под пластом практики.

И это - очевидный 'затык', сколько про него написано статей, постов, даже книг, предлагающих какой то свой подход к его преодолению. Что уж говорить про то, что рано легло в основу.

Отсюда и появляется проблема ненамеренного 'снобизма'. Вот как программист объяснит работу циклов новичку? Она сверхочевидна, что там непонятного, вот только новичок не понимает, что же делать? Объяснить внутряк, на более глубоком уровне, может так станет понятно? И вот тут появляется эта пропасть, когда простые вещи, вдруг становятся невероятно сложными, непонимание новичка может быть на другом уровне, нежели объяснения учителя.

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

Пример - проблема, когда учат синтаксису, а не программированию. И вроде это плохо, но тут возникает парадоксальная штука. А как делать иначе? Вот предположим программисту предложат прочитать курс по вводу в какой нибудь оояп. Как сделать этот курс максимально полезным? Ну разумеется все возможное время посвятить ООП. И самое странное, курс может быть хорош, может отлично объясняться парадигма и даваться интересные задачи, и при этом ученик не научиться программировать. Так что, в данном случае этот 'спойлер' просто необходим.