Reuse just happens. But you have to do it the right way.
Let's say you write some code. Then, you (or worse, somebody in same team) need to do something similar.
In my experience, the first temptation is not to make the existing code more reusable, by breaking it in components, and using only the required component, or by making it more abstract and parameterized.
The first temptation is to copy-paste a huge chunk of code, and then to modify it in a few places to make it compatible with the new requirements. Most often than not, this is what happens, especially with inexperienced programmers, that barely grasp the concepts of OOP.
And, for a short period, this strategy seems to work, and many young members of the team start to think that copy-paste is a good thing: you can do it fast, you don't affect the original piece of code, so the initial developer won't get mad for ruining his work, and you don't risk breaking other things.
But this will come back to haunt you when you need to fix a bug, only to find out that you need to fix it not only in one place, but in the 100 other places where it was copy-pasted.
Or when you need to do a major redesign of the application, for example to change the theme on a web site, only to find out that there are tenths of similar looking, but different CSS, JavaScript, and template files to modify. That is if you are lucky enough to find any templates at all, because who needs templates when you can copy-paste an existing page and customize it every time you create a new web page.
So, yes you have to think every time you write a piece of code, how likely is that later on someone will need to write something similar. And if you find it likely to happen more than 3 or 4 times in the next 3 years, then you might as well plan for that.
Make the code reusable in the first place. Break it in many small classes or templates. Break the methods / functions in many small methods or functions, instead of a god method, 2000 lines long. Document it, comment it, and make clear its purpose, and that you feel that it should be reused, and in what way.
Someone, possibly you, will thank you later for your foresight.
However if you feel that a piece of code will most likely never be reused, you should document that as well. Then you can allow yourself the luxury of not caring about code reuse, and write the code faster.
You should still not create 2000 line code monsters, because you will have to debug or modify that code at some point, and it will be hell. Furthermore, in my experience, breaking the code into many small pieces and giving each a name, will make the code self documenting, to the extent that you will seldom need to comment the code.
And later on, if you are proved wrong and that code will need to be reused, it will be easier to reorganize the small pieces for reuse purposes.
And for god's sake, don't copy-paste. Or if you really have to, because the deadline is yesterday, document the copy-paste in both the source and the destination, and plan to refactor both code sections to something reusable as soon as possible.
Oh well, this comment is already to long. I should probably break it into multiple smaller, reusable comments :)