Recently posted onto Wolfram's Blog is a set of 10 tips for how to write fast Mathematica code.  It is a very amusing read -- go read it now, because below I am going to make some comments on it, assuming that you have read it.

1. Use floating-point numbers if you can, and use them early.
   Basically: if you're using Mathematica as a glorified calculator, say so, else Mathematica will be slow.  The subtext is also that symbolics are slow.  Kind of a great opener for advice on using a symbolic system, no?
2. Learn about … (and 2.5 …and use to generate C code.)
   In other words, Mathematica's language interpreter really is slow, so you'd better compile.
3. Use built-in functions.
   This one I have some sympathy for.  You can't expect user-written code to be better (usually) than code written by experts.  But the flip side is a problem too: the Mathematica library (same as Maple's) is huge, and finding a useful routine for any task is extremely difficult.  Often, searching the help doesn't help at all, as the terms used in the help to describe the functionality might be entirely different than the functionality sought for, but the functionality is nevertheless there, just described 'differently'. 
   This is often a big lost opportunity, as better (read: with lots of redundancy) documentation can greatly increase the effective use of the product, thereby creating much happier customers, who then tend to try to get their colleagues hooked too.
4. Use Wolfram Workbench
   Really what is meant here is 'profile your code', but the author couldn't escape "the corporate message" mindset, so touted the latest wizz-bang tool instead of being more straightforward.  Maple has had profiling tools for over 20 years to do the same thing.  Of course, they are not part of Maplesoft's "corporate message", so I bet that the vast majority of Maple users don't have a clue they are there.
5. Remember values that you will need in the future.
   In Maple, this is "use option remember".  Funnily, this was part of the 'how to make your Maple code faster' advice from about 25 years ago... and some years ago it became clearer and clearer that this is generally stupid advice.  This is really bad programming practice, and should never be used by non-expert programmers.  Memory pressure is a much bigger driver of overall performance than raw computations (at least for user-level computations, not low-level stuff), and this kind of remembering can rapidly fill up memory, thus causing the garbage collector to take up a huge amount of time.  I wonder how many years it will be before Wolfram decides that this was bad advice?
6. Parallelize. (and 6.5 Think about CUDALink and OpenCLLink.)
   This must be more corporate-speak.  It is not stupid advice, but it is not really 'top 10', is it?  The problem is that there aren't really that many computations that easily parallelize, and knowing which ones do isn't that easy either.  So this is really 'try it, it might help' kind of advice.  Especially as it really depends on whether the internal implementation of said routines have already been parallelized or not.  And so on.
7. Use and to accumulate large amounts of data (not ).
   We know this one too: don't add one-element-at-a-time to a list in a loop [or variants thereof].  Mathematica has a function for that, AppendTo.  Just like in Maple, you should only use it if you really really know what you're doing.  [And usually, you don't.]
   For both languages, it is hard not to wonder: but why do the designers make it so darned easy to write bad code?  A good question indeed.
8. Use or rather than .
   Basically: yes, we know we have 3 different things that do almost the same thing, and yes, we've never really said why they are so alike and yet subtly different.  Trust us, this is better.  But be careful, sometimes some are slow.
   Don't knock Mathematica here - Maple has its fair share of the same.  I'm just amused that this must confuse sufficiently many users that it showed up in a top 10.
9. Go easy on pattern matching.
   Ok, this one was the one that really caused me to write this.  This is basically saying "You know, that great feature that has been at the core of our corporate messaging for decades as something that makes Mathematica better than anything else?  Yes, well, it's slow, so don't use it too much". 
   [Back in the day, everything in Maple was implemented using hash tables, and they were touted as the greatest thing ever; no longer.  My prediction: one of these days, Maple will get a proper 'let .. in' statement, and thereafter mutable variables will become 'old style']
10. Try doing things differently.
    "We only really has 9 pieces of advice, but that is not a good number, so we made it 10" by telling you to experiment.  What they are really saying is that the system is so complicated that you really need to learn the quirks (and many clevernesses) of zillions of functions to be able to optimize your code.  Working with Mathematica is not a science, it is an art, because the behaviour of the pieces is not really documented properly, and they don't quite compose in expected ways.  [No, Mathematica is not alone in that]

By far the most amazing thing about this post is how honest it is, at least if you know enough about a CAS system to read what it is that is really being said.

And, at the end of the day, some of that advice may well turn out to be really useful to some Mathematica users.  Might even be useful enough to make them even more hardcore users.

What astounds me is how primitive the advice is.  If one were to scrape up similar advice as found on the pages of MaplePrimes, I am sure that a (equally honest, and devoid of corporate speak) 'top 20' could be cobbled together.  I would even bet that this top 20 would be 'deeper' than the stuff found in that overly-corporate [but honest!] blog post.