Лучший способ обучения?

Question

[maksjuk11]

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

Answer 1

[AlikDex]

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

Comments

[AlikDex]

brainick: что я там увижу?

[Сергей Vortoms]

AlikDex: Увидите прогресс. )) если подойдете к обучению серьезно

[Neonoviiwolf]

вам будет стыдно за свой код

[AlikDex]

Neonoviiwolf: чего стыдится? Новичек же, учишься. В целом, с некоторого момента все равно достигнешь своего потолка и выработается определенный стиль. Стыдится будет уже нечего.

Кстати, до сих пор помню как первые программки начал писать еще на бейсике на 286 процессорах ;D
Жаль не сохранилось... было бы круто глянуть свои первые потуги по созданию игрушки ))) Стыдился бы? Врятле, скорее умилялся.

[AlikDex]

brainick: не знаю как вы, а я пишу комментарии в местах, где может быть не понятно со временем. Они ведь для этого и придуманы, верно?

Answer 2

[Сергей Протько]

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

более легкий и эффективный способ обучения

Смотря что считать легким. Можно легко научиться не тому. Скажем пока вы не понимаете как информация внутри комьютера представлена, даже если вы на JS будете писать вы рискуете быстро проиграть. Это фундаментальные основы которые должен знать каждый.

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

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

Comments

[AVKor]

Есть "История информатики".

[maksjuk11]

т.е. в этой книге описаны фундаментальные понятия?

[Сергей Протько]

maksjuk11: часть понятий. Представление информации в компьютере и т.д. (типа особенности вычислений с float и т.д.) - это просто информатика и это просто надо знать всем, чья работа связана с вычислительной техникой.

А приведенная книга, это очень хорошо структурированный материал который с большего покрывает все. Задает основы. Вводит основные понятия. Главное отличие оной книги от большинства других - порядок, в котором выдается информация, он логичен. От простого к сложному. От общего к частному. Вообще это считается чуть ли не самой лучшей книгой по этой теме. Даже то что первая редакция вышла в 80-х не меняет ее актуальности сегодня.

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

[Lkrasnov]

AVKor: Вы не могли бы сообщить авторов книги "История информатики"? Поиском найти эту книгу не получается.

[AVKor]

Lkrasnov: Я не книгу имел в виду. Это университетский курс, который я читал студентам пару раз лет 12-13 назад.

Никаких практически книг тогда найти не получилось, собирал материл там-сям.

На русском не уверен, что вообще книги появились, на английском видел, что уже имеется.

[Lkrasnov]

Понятно, спасибо. На английском какие бы книги порекомендовали (которые покрывают курс истории информатици)?

[Арина Левадная]

Ну почему. Есть в ВУЗах нечто похожее на то, о чем вы говорите, хотя и называется другими словами.
Я оканчивала МАИ.
И программирование было все курсы и по несколько предметов с разными наименованиями.
Основы вычислительных комплексов и сетей, потом базы данных и распределенные вычислительные системы и т.д. и т.п.
Начинали мы с машин Тьюринга и алгоритмов Маркова.
Потом - pascal на Linux
Оканчивали на тот момент С# и Oracle по части баз данных.

И похожее образование в плане программирования в МГУ и физтехе.

[Сергей Протько]

Арина Григорьева: не знаю... у меня как бы тоже вроде бы все было неплохо, у меня был довольно хороший курс по сетям, история железа именно, типа там эволюция архитектуры микропроцессоров - прекрасно давали этот материал. И базы данных были, и C#, и компиляторы/интерпритаторы свои писали.
Системное программирование, алгоритмизация, к этому притензий у меня лично нет. Но...

При изучении скажем ООП даже не пытались объяснять что такое полиморфизм... Про SOLID рассказывали на 4-ом курсе внезапно на курсе лекций по сетям... и так, мельком, просто между делом. Тестирование - это уже была магистратура и я к тому времени уже 4 года как практиковал TDD.

[Арина Левадная]

Сергей Протько: Ну тут согласна. ООП и паттерны были, конечно, где-то так на старших курсах, но в духе "Вот эту книгу почитайте" и напишите лабу с отрисовкой геометрических фигур И всё. Надо сказать, ООП в полной мере не догоняю и до сих пор. Также сложно далось и понимание таких вещей как лисп и иже с ним. Хотя там преподаватель был поответственнее и старался. И вроде в теории всё просто. Впрочем, как и ООП - всего то 3-4 принципа ;-)

[Сергей Протько]

Арина Григорьева: нет, паттерны как раз и были, а вот принципы из которых эти паттрерны выводятся - этого как раз и нет. Паттерны это не важно, важны принципы.

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

И да, принципов там побольше, но по сути они не привязаны конкретно к ООП. Тут больше здравого смысла.

[Арина Левадная]

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

[Сергей Протько]

Арина Григорьева: не, это нужно, и никогда не знаешь когда столкнешься с такими задачами. Просто нужно еще объяснять про то откуда баги берутся, экономическая эффективность разработки и т.д. А то народ из ВУЗов выходит и думают что им за код платить будут.

[Арина Левадная]

...кстати про тестирование, QA в ВУЗе нам вообще ничего не говорили...и даже близко не было поползновений писать тесты к своим лабам, например.
...что-то мы куда-то далеко уплыли.

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

[Сергей Протько]

Арина Григорьева: суть в том, что координально нового в программировании небыло уже лет 30. А стало быть все эти "новые штуки" это всего-лишь видоизменение очень старых идей. Если человек будет понимать примерный ход мысли как мы пришли к такому или к такому решению - то проблем добавить еще десяток новых однотипных фреймворков я не вижу. Да и небыло бы их столько если бы народ знал что они просто переизобретают колесо.

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

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

[Арина Левадная]

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

Только вот сколько времени в среднем занимает подготовка такого специалиста ? И сколько таких спецов потянет бюджет компаний?

[Сергей Протько]

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

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

Что до бюджета компаний... Ситуация не сильно поменяется, наоборот ЗП выравляются. Сейчас у нас ситуация такая что есть 90% дешевых и средних разработчиков, которые так себе разработчики, и 10% сильных и дорогих. Если же уровень разработчика хоть немного выровняется, выровняются и ЗП. Правила рынка труда. Если больше шансов заменить сотрудника, его ценность на рынке падает. А стало быть никаких проблем.

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

[Арина Левадная]

Я бы согласилась в следующих случаях:
1. Проект большой и нужно очень много рук.
2. Он идет джуниором ну на крайняк мидлом под опеку "проверенного" человека.

[Сергей Протько]

Арина Григорьева:

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

2. У нас есть синьер который будет следить.

А что у нас на рынке фриланса? Нет синьеров. Народ не учится, за ними не следят. В целом это общая проблема индустрии. Даже в небольших компаниях может просто не найтись человека который бы в должной мере менторил людей. Я это наблюдаю в половине компаний Минска когда люди просто не развиваются и не знают как.

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

[Арина Левадная]

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

[mbcsoft]

Сергей Протько: так, а что за книгу вы нашли (написанная в 80-х) ?
Основы информатики и вычислительной техники, она?

[Сергей Протько]

mbcsoft: "Структура и интерпритация компьютерных программ".

[Ислам Энгиноев]

Сергей Протько: Какие важные книги вы еще посоветуете которые важно знать как и Структура и интерпритация компьютерных программ .И тому подобные который очень важно знать и что вы здесь описывали всякие штучки

Answer 3

[Merovei]

Эдгар Дейл Вам в помощь.

Comments

[pro100saniok]

читать не нужно ? только работать ?

[Merovei]

pro100saniok: Работать не нужно? Только читать?

Answer 4

[ruGuardian]

Теорию и практику следует правильно дозировать в правильное время. Всегда делал так:
1) Начинаешь изучение новой технологии, больше читаешь, чем пишешь, но обязательно пробуешь задачи, примеры, экспериментируешь до тех пор пока суть не вобъется в голову. Именно поэтому, если я должен выучить новый язык, книгу без задач я не возьму. Здесь цель - понять, как это работает и в каких случаях применяется.
2) Применяешь на практике новые знания, иначе не закрепится. Придумываешь себе задачу на пару вечеров (займет неделю). Больше пишешь, чем читаешь, все проблемы решаешь справкой или погуглив. Здесь цель - выполнить задачу. Не растекаясь на выяснение деталей. Если затык, goto п.1.
3) По окончанию собираешь все мутные темы, с которыми столкнулся, все вопросы, которые решил просто погуглив не разобравшись по сути и goto с ними в п.1.
Это решит твою проблему, когда пишешь в конспект, а не в голову.

Answer 5

[xmoonlight]

Этот вопрос я задаю вам.

Хорошо, что сказали! :)

По теме (кратко, но доходчиво):
©2016
1. Обучиться - значит уметь применять.
2. Уметь применять - значит понимать.
3. Понимать - уметь научить.
©2016

Comments

[Егор]

Есть еще 4(высшее) состояние знания, когда что-то делаешь, у тебя все получается, а ты даже не осознаешь этого.

[xmoonlight]

Егор: а зачем его осознавать, если оно не приносит проблем?!)

[Егор]

xmoonlight: так его и не нужно осознавать. Оно просто "есть".

[xmoonlight]

Егор: тогда его не нужно писать)) а закопирайтить пункты - нужно не забыть)

[Егор]

xmoonlight: Я его написал, потому что встречал в литературе первых 3 написанных вами. И 4-ого не хватало для "полноты картины".

[xmoonlight]

Егор: Ок. Понятно... Ссылка есть под руками или куда копать на первые три? А то вдруг, действительно, уже кто-то придумал)

[Егор]

xmoonlight: сейчас уже не вспомню первоисточник, но в интернете это перефразировали как "теория компетентности".

[xmoonlight]

Егор: почитал, но это совсем не то... Это речь об осознании, а не о владениях навыками на разных стадиях развития (как у меня).

[Егор]

xmoonlight: ну почему же только осознании. О применении также. Разве можно осознать, что умеешь, не применяя этого?

[xmoonlight]

Егор: да. это как раз осознание возможности.

Answer 6

[Saboteur]

"более легкий и эффективный способ обучения"

Взаимоисключающие параграфы.
Эффективные методы - более тяжелые.
Неэффективные - более легкие.

Читайте книги и статьи, пишите код. Секретного ингредиента нет.

Answer 7

[Anton Filippov]

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

Answer 8

[Егор]

Универсального наилучшего способа для любого человека нет.
Человек - существо сложное, и состоит из 3х основных компонентов: тело, эмоции и мозги.
Учится тело. А программирование - это как раз сначала мозги.
Поэтому найдите для себя наилучший способ "опредметить" то, что вы читаете по программированию.

Также лично мне очень нравится все курсы про обучение. Один из них был давно на Coursera, и как раз в понедельник начинается снова.

Ну и практический опыт - конечно же незаменим.

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

Начинайте с самого-присамого простого, и затем разматывайте свой клубок знаний.

Answer 9

[Vov Vov]

Самым коротким путём является обучение с наставником, никакие курсы и книжки не сравняться с этим, но оно стоит денег, другой вопрос если конвертировать зря потерянное время в деньги скорее всего получится в несколько раз больше.
Мой курс на эту тему: propercourse.ru/courses/1

Answer 10

[Кот Учёный]

1. Прочтите учебник.
   
2. Поставьте перед собой простую, но конкретную задачу и решайте её, обращаясь к учебнику. Начинайте с самых азов и элементарных вещей.
   
3. Если задача оказалась слишком сложной, поставьте по-проще или прибегните к её декомпозиции.
   
4. Не стыдитесь пользоваться шпаргалками. То, что Вы пишите, рано или поздно, отложится у Вас в голове. Практика важнее зубрёжки, т.к. развивает соответствующий образ мышления и прививает правильное понимание.
   

Answer 11

[Сергей Некрасов]

Попробуйте читать не одну книгу по программированию, а две параллельно, но связанные одной темой, т.е. к вашей текущей добавьте например алгоритмы или ООП, есть вероятность что учиться будет интересней.
Чем лучше вы овладеваете материалом, тем больше удовольствия начинаете получать.

Answer 12

[Юрий Матюхин]

Лучший способ — найти ментора, который будет говорить что делать и направлять в нужную сторону.
Но хороший ментор — дорогой ментор. Поэтому все читают книги, смотрят курсы и пытаются разобраться сами.
Из курсов я бы советовал egghead.io.