Как вы читаете книги?
 

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

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

Мне было бы интересно узнать какой ваш подход к чтению: может быть вы пишете статьи или создаете интеллект-карты по прочитанному?
Спасибо.

Я просто пишу код, по 8-10 часов в день, а книги как дополнительный бонус :)

Повторение мать учения?:)

чем плох ваш вариант автор? Вот к примеру здесь проводят отличный ремонт и дешевый холодильников http://pro-xolod.ru/remont/remont-ko...i-split-sistem ничто не поставит под сомнение их качество работы.

Сначала желательно пролистать книгу и выделить самые приоритетные разделы
потому что много информации, которую лучше всего оставить на потом

в туалете, в лучшем случае.

Это не касается конечно чего то эпического, типа SICP или митовских бумаг по AI

не слушай дебилов. Основная соль не в количестве, а в качестве. К слову, нормальных книг по JS вообще нет, практически. Хочешь понять лучше JS, читай что-нибудь по смоллтоку, селфу и ио. Будешь в общих чертах иметь представление о модели исполнения и проектировании в этой модели. Еще могу порекомендовать вот эту вот брошюрку: http://norvig.com/design-patterns/design-patterns.pdf

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

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

Внезапно, есть еще один вариант: написать код(реализовать задачу) Нормальные люди для этого и учатся, чтобы уметь что-то делать самостоятельно.

ты забыл зацитировать "и т.п." ;)
написать код (реализовать задачу), чтобы его (её) нельзя было повторно использовать вновь это тоже искусство, согласен :D

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

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

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

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

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

bes,
кстати, инкремент и сложение это 2 разные вещи.

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

bes,
вот одна из причин, почему это плохо (существует масса других, но не будем лезть в дебри). Ты сильно ограничен в свободе синтаксиса. В *настоящем* ООП, где все есть сообщение, нет никаких ограничений в именовании, а это одна из основ полиморфизма

List ++ := method(append(1))
Sequence ++ := method(appendSeq("1"))
Object ++ := method(self one := 1)

l := list(1, 2, 3)
s := "123" asMutable
o := Object clone

list(l, s, o) foreach(++)

list(l, s, o one) foreach( println )

#>>>> list(1, 2, 3, 1)
#>>>> 1231
#>>>> 1

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

в этом случае, если ты не хочешь мыслить шире, звучало бы так: если бы ты их не нашёл, придумав их, ты бы не смог их использовать ;)

пояснишь на свой лад как ты себе это представляешь?

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


жизнь она такая :yes:

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