1) Don’t optimize.
The impulse to optimise is usually premature. Clever solutions to squeeze performance increase complexity and undermine the end goal. Get the code working. Optimise just that code that needs it, at the end.
2) Do optimize for simplicity
You can optimise for execution speed. You can optimise for space. But the most precious thing you should optimise for is your own time. Optimise for readability, and understandability. If you have to stop and ask yourself, “how does this work?” or “why isn’t this doing what it should do?” – you have just wasted your time.
3) Much fancy academic CS is bogus
Some college based computer science methods should be used with care. Many papers describe methods which are super optimised around one case. Not all are bogus, but the benefits in many papers are often over-stated. And if you adopt the solution, you may find the benefits do not justify the costs.
4) The simplest abstractions are usually best
The real enemy in being productive is the mind of the programmer. The more “cognitive load” you place in your head, the less productive you become. So complexity is the enemy. Whenever possible, adopt simple dumb solutions. He talks a lot about iterating through arrays, rather than smarter data structures. If you can keep it all in your head, you will be faster. You can’t keep it all in your head if there is this ton of complexity.
With each new class/method added to your code, the complexity can increase not linearly but exponentially. Deleting code is therefore always better than adding code. Don’t put stuff into functions when it could be inline.
5) Don’t write generalised code
Over generalised super flexible code is often a waste of time. It’s usually harder to maintain and a source of potential bugs. Hard coding isn’t bad if your code is doing one thing.