Как достичь цели

Несколько полезных для начинающих разработчиков статей:
Как разработчику понять, что он готов искать первую работу
Как 65 разработчиков-новичков без опыта в программировании получили свою первую работу
Как найти первую работу в IT: план действий для начинающих
Как разработчику-самоучке найти первую работу
Как стать Java разработчиком за 1,5 года
Поиск первой работы: советы разработчику
Первая работа в IT: получаем должность без опыта
Как научиться программировать с нуля и найти первую работу. Большой FAQ от Reddit
Мои странные правила, благодаря которым я получил работу

В статьях много и несколько туманно пишут о том, что можно изложить в трёх пунктах:

1. Составь план. 
Любой. Пусть он будет самым общим, без конкретных цифр. Лишь бы он был реальным и следование ему вело тебя к цели.

2. Следуй плану.
Без активных действий с твоей стороны - никак. Под лежачий камень вода не течёт. Путь в тысячу лье начинается с одного шага. И т.д. Не будешь следовать плану, не сможешь его выполнить.
Есть одна притчу про один шаг вперёд и два шага назад. Так вот, каждый день, когда ты следуешь плану - это шаг вперёд к твоей цели. Каждый день, который ты не следовал плану - это два шага назад.
Если при следовании плану ты понимаешь, что нужно скорректировать план - это нормально. Корректируй и следуй ему дальше. Главное при этом - видеть свою цель и понимать, что корректировка плана не отдаляет тебя от цели.

3. Учись.
Учись всегда и везде тому, что нужно для выполнения твоего плана и его корректровки. Постоянная практика - часть учёбы. Без практики, изучение только теории малоэффективно. Если цель - изучить язык программирования, то решай задачи, пиши мини-проекты. Чем больше практики, тем лучше.

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

Должен ли я читать книги?

Оно мне вообще надо - читать книги?
Конечно надо! На собеседованиях постоянно просят наизусть декламировать отдельные определения или даже целые главы из "Чистого кода", "Чистой архитектуры", книг "Банды Четырёх" и других классических трудов.
Шучу.
Ну, кому ещё это может понадобиться, кроме преподавателей-теоретиков в вузе? Хотя, у меня пару раз на собеседованиях придирались к неточным формулировкам.
Так что, не боись теории, но и "булки не расслабляй".


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

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

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

А что читать?
Вот тут обсуждается список книг, которые должен прочитать каждый программист.
Если коротко, то это:

1. The Pragmatic Programmer by David Thomas & Andrew Hunt (67% recommended)
2. Clean Code by Robert C. Martin (66% recommended)
3. Code Complete by Steve McConnell (42% recommended)
4. Refactoring by Martin Fowler (35% recommended)
5. Head First Design Patterns by Eric Freeman / Bert Bates / Kathy Sierra / Elisabeth Robson (29.4% recommended)
6. The Mythical Man-Month by Frederick P. Brooks Jr (27.9% recommended)
7. The Clean Coder by Robert Martin (27.9% recommended)
8. Working Effectively with Legacy Code by Michael Feathers (26.4% recommended)
9. Design Patterns by by Erich Gamma / Richard Helm / Ralph Johnson / John Vlissides (25% recommended)
10. Cracking the Coding Interview by Gayle Laakmann McDowell (22% recommended)
11. Soft Skills by John Sonmez (22% recommended)
12. Don’t Make Me Think by Steve Krug (19.1% recommended)
13. Code by Charles Petzold (19.1% recommended)
14. Introduction to Algorithms by Thomas H. Cormen / Charles E. Leiserson / Ronald L. Rivest / Clifford Stein (17.6% recommended)
15. Peopleware by Tom DeMarco & Tim Lister (17.6% recommended)
16. Programming Pearls by Jon Bentley (16.1% recommended)
17. Patterns of Enterprise Application Architecture by Martin Fowler (14.7% recommended)
18. Structure and Interpretation of Computer Programs by Harold Abelson / Gerald Jay Sussman / Julie Sussman (13.2% recommended)
19. The Art of Computer Programming by Donald E. Knuth(10.2% recommended)
20. Domain-Driven Design by Eric Evans (10.2% recommended)
21. Coders at Work by Peter Seibel (10.2% recommended)
22. Rapid Development by Steve McConnell (8.8% recommended)
23. The Self-Taught Programmer by Cory Althoff (8.8% recommended)
24. Algorithms by Robert Sedgewick & Kevin Wayne (8.8% recommended)
25. Continuous Delivery by Jez Humble & David Farley (8.8% recommended)

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