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.
--
FalkBruegmann
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.