"10. Get into a rut early: Do the same processes the same way.
Accumulate idioms. Standardize. The only difference (!) between Shakespeare
and you was the size of his idiom list - not the size of his vocabulary. "
-Alan
Perlis
Thinking about how you spend your time is worthwhile. As a
legitimation for this document, this is the first rule. Just like Paracelsus
said, though, "The dose makes the poison". Spend too much time just planning
how to become efficient, and there will not be enough time left to really be
efficient.
Stay open
To expand your knowledge and understanding, you need to do three things.
If you do not even know of a solution, you cannot learn how to use it.
Therefore, it is important to snoop around and widen your horizon. Stay
informed. The most effective way to do this I know of is reading domain
journals like c't. Journals have lots of staff, who do nothing else than
look around for new products, methods and technologies, and filter the
interesting ones for easy consumption. Of course formal training like
visiting a university, can be very helpful here, too. There you are fed
preselected information to give you an overview. Conferences are another
good way to learn about new developments. As are twitter feeds of eminent people in the field. The limiting resource here as everywhere is time. Getting informed and snooping around can usually be done as a spare time activity, but will take more then half a day per week.
There may be some solution that is so far out that nobody else in the
world before tried to apply it to your problem, like it was the case at some
time with Markov models, or the application of genetics to programming in
genetic algorithms. To be able to discover something like that, you have to
think laterally and also have interests different from your problem field.
Learn from masters
Any first idea you get on how to solve something you do not know anything
about, will be naive. There you go, programming a bubblesort, since you
never heard of quicksort or heapsort. You can save lots of time, get better
results and deepen your insights by looking on how some wizard did that
stuff. It helps immensely if you have masterful works to inspire you and help
direct you in your practice. One has to stand upon the shoulders of giants
to achieve something in a field that is complicated and large. And contrary
to Perlis' epigramm, you should sometimes try to change your behaviour
patterns if there is a better way to do it.
Practice
Then you have to practice, practice, practice, to understand why he did
things that way and not another way. All real understanding comes from
practice. There's a German proverb:
"Übung macht den Meister."
(Practice makes perfect.)
You learn best by solving problems. You learn programming by programming
and examining how good programmers program. Another excellent review on
learning to learn is Peter Norvig's
page. The bottom line is, that you
are learning the best if what you do is fun and if you learn to solve a
direct problem - problem oriented learning. When you are working on a
project you'll experience problems. Since you want to solve the direct
problem, you understand the problem, and you are highly motivated to learn
and understand what to do to tackle it.
I read through general Unix books several times, and still I do not
really have a good grasp on Unix. Because without really working much on
Unix I never knew what of all this stuff was really of practical use for me
in my day to day work, what to watch out for. Also without a direct
application, the urge to really understand something complex was not big
enough - I just skimmed over the difficult parts, never gaining real
insight. The mind is not so easily fooled and protests to remember lots of
probably irrelevant detail. I learned much more about Unix just by looking
over the shoulder of my co-worker, the great INGMAR, for two hours. Because
what he did and used was the stuff that you really needed.
Focus
You cannot learn everything. Just poring through books and more
books doesn't give you real knowledge. There is much more knowledge printed
than you ever could read, much less remember. I still sometimes fall into
the book trap, losing touch with my actual work and thereby learning less,
slower and wasting time. That's not to say books are bad, they help you get
started on a subject, and help you look things up, when you need them. But
you need something to help you focus. You cannot learn everything. You have
to select the important stuff and concentrate on that. Having a goal helps
you to select.
There is a saying from Goethe, the great German writer:
"Ein Mann,
der recht zu wirken denkt, muss auf das beste Werkzeug halten." ("A man that
wants to be effective, has to use the best tools.") It is often worth
to invest the time and learn using a good tool, since the tool will make you
much more productive. How to find the best tools? Just look what the gurus
are using. In hacker culture, these are to a large extent open source free
software
tools.
One of the problems is that the tools on Windows and Unix are so
different. When I switched from NT, Java, Textpad/VisualCafe to Unix, Perl,
Emacs to write a small script, it took me a whole day, since suddenly I had
to use other key bindings, other language syntax etc. Again, focus on one
set of tools, get used to it.
Play
Creativity and fun are important. Half of your brain is
concerned with associative, wholistic thinking. Normally in school you are
taught to use only the other, logical, analytic half. But memory doesn't
work analytically, it works by connecting and associating things, thus
giving them a relation to live in. Just think about how much easier it is
to remember emotionally important stuff than technical facts. Just observe
how much faster you learn by playing around and having fun with what you do.
Actually, enjoying your work should always be the
highest priority
on your list.
First Things First
... second things never. You get work done fast by doing the
work that has to be done. IT'S THAT SIMPLE. It is very easy to get
distracted by all the marvellous toys that are out there, and many of which
probably are even worth looking at, like compiler compilers, how compilers
work, metadata, grammars etc. All of these, if mastered might make it
possible to do your work in a much better way - but mastering them, or even
grasping the concepts, takes time. Time you will not spend on your actual
work, which won't progress. And without the feedback of work, what you look
at cannot be truly understood. So it comes down to this simple phrase
(which I saw in the film "My name is Joe", pinned to the kitchen cupboard of
an alcoholic). Spend too much time on learning, and there will be no time to be
productive. Spend too much time on production, and you will waste it because
there would be a better way. (See
PC/P balance.)
Here is an interesting story by a
real programmer,
jwz, about working. What I
learned from checking his site is something I realised also from reading
Feynman's "Surely you are joking, Mr. Feynman": these guys were or are great
because of a) their huge minds and b) working on their stuff, instead of
reading educated articles about how one should work, or reading biographies
about other great men (or women) and how they did it. I can try that, too.
Knowledge is personal, so is thinking. You have to find your own way. The
only way to learn programming is programming. I also get the impression that
jwz separates his work strictly from his other activities, like private
hacks, writing etc. Good idea.
Get organized*
Structure your work processes and data. You can sort all of your
working activities into three domains: productive work, learning, and
administrative work. I think it is best to try to go into batch mode (to
borrow that idea from
Don Knuth) and do
only one of those at the time. Of course this is often not easy, but improves
productivity. Start with productive work
until you get tired. Then it might be a good time to browse a bit, read up
on news and when you are a bit refreshed, go on to learning (about the
things you encountered during the working part). Don't do the administrative stuff early in the morning "to get it out of the way", do it in the evening, or it will eat up your whole day (downloading, communication, planning). The meta stuff (reflecting
on what you do) can be in between but updating documents such as this should
be done on the weekend.
Try to structure your data and work processes, so you do not have to
spend time re-thinking stuff you thought about before. Organise your
information, so you do not have to search for that address again etc.
When I was back in school I thought people that used index cards were
idiots. I just wrote everything neatly down into my notebook, at the end of
the year I'd have a nice book on linear algebra for example. If I wanted to
look something up later, I just got the book and there it was. Right at my
fingertips. Others wrote everything into one big binder, to "sort it out"
later, and of course, most of the time nothing got sorted, everything was
mixed up, and you couldn't find anything anymore.
Unfortunately I had to
discover, that this plan only works while in school: there you get all the
information pre-ordered. In real life, you work on a lot of things and piece
stuff together all the time. The order of incoming information is not well
structured, and so you are often forced to restructure your notes later. You
always should try to reuse your notes, on the principle that if you don't,
what were they good for in the first place. You will just write that same
stuff down again? Because of that, it is much better to use ring binders,
where you can resort the sheets or even better yet, computer files. Also,
even if you have all the information reorganisable, you should create a
central repository.
I tried several planning systems (a la filofax) and none of them worked
for me. I'd start out with a burst of filled days, then nothing else
follows. I thought that probably I'm just too undisciplined to use them,
until I discovered
Getting Things Done.
I also learned that if it's bigger than my pocket, I won't take it everywhere and
it will be useless. Now, in the age of smartphones, you can always have your calendar and contacts and notes with you.
When working with the computer, look out for repetitive tasks that eat up
time. It might be worth to automate them with a small shell or perl script,
if possible.
Example work distribution during my Ph.D.:
PRODUCTIVE |
LEARNING |
ADMINISTRATIVE |
- programming, debugging
- documenting and application design
|
- staying up-to-date on news, products, technology
discussions
- learning usage of tools, protocols, programming techniques
|
- communicating with programmers, collegues, vendors
- ordering stuff, filling out forms
- meta-work, planning and reflection like this
- downloading stuff
- meetings
|
Learn from mistakes
Do not repeat useless actions. To learn the right things, you
first have to understand what the problem is. You have to ask yourself the
right question, have to limit the options. Maybe in the very beginning when
you do not have enough information to see what is important at all, you have
to just skim around, looking here and there, until some kind of map builds
up in your mind. It will do this automatically, don't worry about it. Your
brain will do this for you. Then, when you recognise the crucial points, you
look there.
When I was small, I lived in a room under the roof. The window above my
bed was set into the roof and thus was not vertical, but tilted at about
45°. To open it, you tilted it a bit more about a horizontal axis. It
also had the glass pane set into a wooden frame, so that the frame worked
like a small rim around the window. Now, under that roof we also had a
wasp-nest, and every now and then, when the window was open a wasp would err
into the room. Once inside it would see the big blue sky through the window,
whereas the room was dark and shady. So in a futile attempt to get out
again, the wasps bumped their head against the glass pane. Again and again,
hours on end. In the end the wasps fell down into my bed, exhausted, and
died there. Some of them checked all of the pane, until they reached the
rim, but they couldn't see an exit there, either, so they went on along the
rim or back inside the pane.
So all the wasps died, because they were too dumb to learn. They just
repeated the same mistake over and over. It would have been so easy to
escape and survive. All they had to do was understand that what they had
done didn't work and back up a bit. Freedom was just a few inches away.
I have seen the same behaviour many times later on, but not with wasps,
which can hold up to their defense that they are only small insects with
even smaller brains, but with people, including myself. They try something,
it doesn't work, they try it again. Then again. If something doesn't work,
try doing it differently. Just repeating it over and over will get you
nowhere. You have to change some parameters.
As an aside, there is the story of the two frogs in a bowl of milk,
drowning, where one gives up and drowns, while the other struggles, trying
again and again to jump out, until finally the milk changes to cream and he
escapes. There also is an variation on this: "I'm so deep in sh*t, I can
struggle all I want, it just won't turn to cream."
Also, if you want to eliminate a problem, first you have to find out what
the problem really is in a complex system like a computer. If something
won't work, there can be lots of reasons. Check out the different levels
from low to high with elementary tests, to find out where things go wrong.
This goes along with finding out what to learn.
*Meetings
Writing this nearly 20 years later in life, the challenges on my time have changed. Back then I was a single contributor, and had the freedom to of having most of my time to myself. I listed meetings and communications as a subitem of administrative. Now with a leadership role in a larger organisation, most of my time is eaten up by meetings, often meetings that I did not put on the agenda.
In this situation, it becomes even more important to batch and compartmentalise time. As outlined in
Maker's schedule, Manager's schedule by Paul Graham, it helps to block at least half-days for immersive work, thinking and learning, and to batch meetings. And I learned via
Tim Ferris, "Your inbox is everybody else's agenda for your time." Control your own priorities and time, and do not let others dictate it to you.