In the context of programming, this is the process speeding up time-critical segments of the running program.
This is usually done by shaving off CPU cycles in inner loops and the like. I will put a tool here that will help with that.
An approach that usually yields bigger time gains than focusing narrowly on existing code is thinking about the general problem to solve and reorganize data and distribute the workload for the CPU.
Plus, what good is a slightly faster effect if it has been done many times before? So there's something to be said for creativity.
Regardless, you should of course learn how to write efficient code so other coders don't make demos with <insert your handle> modes in them. ;P

Size coding

You can also optimize a program for the size of the executable file. In the days of floppy disks and tiny amounts of RAM, this was important. Amigas come with a minimum of 512K RAM and can have huge harddisks, so "fitting the program in" is no longer a problem.
So today, you shouldn't waste time size coding. Any restrictions are artificial, such as... in 1K, 4K, or 64K intro competitions! These offer an even bigger challenge of doing a lot with little.
That said, you shouldn't waste kilobytes, either. The AmigaDOS commands always struck me as being bloated ("whaddya mean 11K for a command to change directory??"). These were written in C, of course. Check out my ~300 bytes Assembler CD command in my old snippets directory... ;)
Sometimes size coding can lead to a nice and short little routine, but for the most part, in Assembly, you end up writing pretty much unreadable and obfuscated code.
It's certainly good to not waste memory. If you can, organize your program to avoid bloated data and duplicated (copy+paste+modify) code.
If you're past all these warning and still want to have a go, why not read the article I wrote on my latest 1K Bootblock intro? :)