Here, ReadWhatYouNeed is presented as an AntiPattern. See ProgrammingBooksAreaWasteOfTime for a differing opinion.
Summary:
Some developers apply YAGNI (YouArentGonnaNeedIt) to reading technical texts, reading only what is necessary to get started using a new technology or solve a problem. Don't.
As a developer in a commercial setting, you need to decide how much of your work time you spend reading technical texts, and what you spend that reading time on. On the one hand, you are constantly under time pressure, you need to justify the use of work time to your boss/customer, and you want to be seen as an effective worker. On the other hand, you are confronted with new or changing technologies all the time, and need to learn about them.
Therefore,
Don't spend time learning about technologies you are currently not using. When you encounter a new technology you have to use, aim to read/learn the minimum amount necessary to get you started ("... in 24 hours"). Once you feel you know what you need for the task at hand, "start working" and stop reading, except for when you need to look something up.
As a result, you can spend more hours working instead of learning. You look productive to your customer/boss, and can easily justify (read: bill) every work hour spent. Even with new technologies you are quickly able to contribute to the project.
But,
This way, you will only gain insight into a limited set of technologies, so you may end up chosing a sub-optimal tool for the job, or the one after that. Even with the technologies you are using, you may get stuck with inferior ways of doing things you think you know how to do, because there is never a concrete need to look up other ways. Furthermore, you may take longer to develop a deep understanding of these technologies, and easily get stuck on and have to work around bugs or problems which require such a deep understanding.
Therefore,
Fight hard to set aside a certain amount of time for reading/learning, even when not in a "initial learning phase". Of this learning time, reserve a certain percentage for improving your knowledge about technologies you are currently working with, and a certain percentage for technologies which might become relevant in the future.
This way, you will collect a much greater set of technologies in your toolbox, and understand and use the tools you are working with to their full extent. The cumulative effect of these will make you much more productive in the medium and long run, and easily offset the time spent reading.
Personal example, although not strictly about programming: As a student, I once worked as an intern for a group of consultants who did a lot of ad-hoc analysis of business data using Excel. I hadn't done much with Excel before, so I bought a couple of books, and spent a day or two reading up on it, then I spent half an hour reading on the commute to and from the office each day. After two weeks, I had solidly caught up with everyone, after a month, I had become the local "Excel guru" ;).
A number of observations about that: 1) These intelligent, studied consultants had been using Excel as their main tool for years, and yet it was possible for a snotty intern to surpass their knowledge within a month?! 2) My learning about pivot tables, Excel solver etc. saved them at least a dozen person-hours every week, as they had been using simple formulas to emulate those. 3) You will not discover pivot tables by looking up functions you are currently using in the online help. To understand what pivot tables can really do, you have to invest some time into learning something that you may or may not need in the future.
P.S.: This is the first time I tried to use the PortlandForm. Because I see ReadWhatYouNeed as an AntiPattern, I extended it to the Therefore-But-Therefore form you see above. Comments or improvements welcome, as always.