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