这只是个人观点，不一定对，更不可能是唯一对的。
读物的产生
通常是多人协作，分管不同的模块撰写，且手册未必是开发人员亲自编写。
也就是说，精通一门技术需要消耗的时间也必然不小。
技术是人思考和实践出来的，读物也不是无中生有出来的，所以如果说非要考古式的回溯源头，未必是件好事，这就需要权衡。
读物分类
在我看来所有的技术读物应该分为权威刊物和辅助读物两种（当然角度不同，分出的类别也不同）。
权威性读物
其中权威读物应该严谨、完整（比如 Oracle 官方，或者 Apache 官方文档），并且是多个领域专家或者协会的共识，聚焦在某个领域（不是说不会涉及其他领域，而是应该有一个相对聚焦的核心，涉及到其他领域的时候要有适当控制，原则上应该是为了辅助讲好本领域的内容）。
当然权威读物也可以继续分为用户指南和参考手册两大种，或者 tutorial / user guide / reference manual 三种，当然有时候可能用 API DOC 替代参考手册或者作为参考手册的补充。
辅助类读物
所有的辅助性讲授都应该依据权威读物来展开，比如引入趣味性（趣谈 Linux 操作系统），或者删繁就简（Java核心技术36讲）快速建立系统性的认知，或者为了特定受众的定制（说透中台），或者是为了某些特定问题而制作（比如 Java 性能调优实战）。
权威读物是必不可少的，其他读物也是。
补充说明
当然读物远不止这两种，而且还出现了很多人阅读完之后做二次输出。那么究竟是看一手资料好，还是二手资料好？
我的理解是这样的：不同的读物会有不同特点，不同的读者会有不同需求，纷繁复杂的读物就像琳琅满目的商品，质量、外观、易用性都会有所差别。
你需要找到的是合适你的那一款，而不是往家里囤一堆，然后挨个试用，即浪费时间也浪费金钱。大多数情况下你可能真的不需要太多挑拣，任选一个口碑还不错的就够用了。
下面 如何选 也有进一步的挑选说明。
如何读
- 通过 tutorial 快速上手，进入启蒙状态。
- 通过 best practice 或者 user guide 作为晋升教程，“工作状态”。
- 通过 reference manual / apidoc 作为专家级教程。
- 当然需要记住的是，自己一定不能放弃自我思考能力。
当然我觉得在读完 tutorial 之后，最好去刻意的记一下 reference manual 的目录，或者 apidoc 的 Package 目录。
如何选
在一定情况下，读书如同找帮手或者找老师，如果所求非所长、所答非所问，那会很尴尬。
技术是有依赖关系的，就像 Java 的 Jar 包之间的依赖关系错综复杂，没有 Maven / gradle 等工具之前，这种关系会变得管理起来十分困难。由于历史原因每个人的知识体系千差万别，所以选读物要先梳理知识脉络，就像玩游戏需要先看看每个职业的技能树一样。
这个社会上还有很多人喜欢贩卖焦虑和诈骗，所以试读是十分必要的，通常读物目录的组织是否合理也往往能成为一个（读物质量）的参考点，书评里也可以窥见一二（尽管有些评论会有正面或者负面误导性）。
结语
从程序员的角度去看，权威读物是一个个数据库，是一个个后台服务；而辅助性读物是视图，是对后台的整合，是对客户友好性的UI。 当我们能够从多个角度定义自我的时候，我们才能知道自己是谁；当我们随着时间不断的更新自我定义的时候，我们就能看见来路，望见去向。
所有的路都未必是最优路径，从长远看，任何人都不可能在生活里找到最优路径。
不断试错和修正，以及时时做准备可以有效的减少很多错误，避免很多弯路。
