The most important thing you can do is write good clean simple easy to understand code that cleanly solves the problem.

Related you need to understand the problem you are solving, and write code that reflects that understanding.

Getting the last 2% out of the code is a very late in the game process, and often never happens.

The primary reason that efforts are made to optimize code are that the code is bad to begin with.

Further any actual need for optimization of well written code is increasingly non-existant. 40 years ago, it might be necescary to get another 5% out of something to actually be able to make it work on a 2mhz z80,

If you have code that is performance constrained on a quad core 3Ghz 64 bit processor - either you are trying to manage plasma containment in a fusion reactor, or you do not know how to code.

First off, MOST of the time in this day and age someone quotes that bit by Knuth, they are doing it out of context and as a lame excuse to cover up their laziness, their ignorance, or their unwillingness to change ingrained bad habits.

A great example of this comes from PHP -- the "single quotes vs. double quoted" strings argument where YES, single quotes ARE faster. The argument is the speed difference is so negligible it's not worth caring about -- but even if it is barely perceptible is it so horrible to just NOT hit "shift" on the same key? Or comma delimiting echo vs. string addition vs. double quote parsing. The latter two increase your memory footprint and are slower -- all of them are basically the same amount of typing so why do SO many use the "premature optimization" LAME EXCUSE to justify their shoddy coding practices?

Or even just something as simple as learning when to use SWITCH/CASE instead of IF/ELSE. You'll endlessly see people with massive bloated nested IF/ELSE again using the "premature optimization" LAME EXCUSE to cover up for their own ineptitude and/or ignorance!

Developing good programming habits and learning when and how to use the language properly IS NOT PREMATURE OPTIMIZATION.

YET you'll have people endlessly quoting Knuths:

Premature optimization is the root of all evil

But taken by itself that's OUT OF CONTEXT. It's a cute sound-byte sleazy dirtbags use to excuse their own laziness and stupidity. Let's look at the WHOLE text, shall we?

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small inefficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Oh gee, if I don't hit shift so I get ' instead of " making the 'effort' difference effectively meaningless falls squarely into good habits, have no negative impact when debugging or maintaining the codebase. Therefor his generalization DOES NOT APPLY!

This does NOT mean you obsess about it -- code clarity SHOULD be considered more important but honestly, more often than not over the past 40 years I've been writing software, clean optimized code is more often than not clearer and easier to work with! Again making the people who mindlessly parrot Knuth out of context look the fool.

But really, whenever ANYONE gives you a sound byte out of context, they're probably trying to lie right straight to your face. See the current trend of quoting one sub-clause from a letter of Lincoln's right now ignoring everything else said around it. Sound-bytes are classic for this, and one of the many reasons I think the twitter generation TLDR mouth-breathers are halfwit fools easily herded around that should REALLY pick up a book from time to time. See the illiterate derps who get their panties in a wad every time someone makes a post ANYWHERE longer than a paragraph.

Now, as to profiling -- that's ALWAYS important but you have to be careful not to let it LIE to you. I encounter this all the time in game development where time-slicing is a essential part of the process. Sometimes you ARE going to just have times where the computer HAS to sit there with it's thumb up it's arse waiting for the next frame update. A automated profiler will throw up a giant warning "hey you're doing nothing here" when that's INTENTIONAL to maintain smooth gameplay and framerate. Recognizing that is something a LOT of people obsessed with profiling tools often fail to grasp.

Profiling can also open your eyes to "Jeez, that part really didn't matter" as well as "wow, I NEVER thought that would be the bottleneck". See the classic BS we've heard from PHP developers that "well mysql is the real bottleneck, not the server side language" -- again, a LAME EXCUSE to cover up for shoddy coding practices. Had said statement that's been parroted for over a decade and a half ACTUALLY been true, then how in the blazes do systems like Laravel, Magento, and Wordpress see 80 to 90% speed boosts between PHP 5.6 and PHP 7?

Laughably, the engine under PHP seems to have been optimized to make shoddy coding practices run faster. THERE's some derp for you on the part of the development community. Almost as stupid as HTML's blindly plodding on as if nothing is wrong, wildly guessing at what the code should have been instead of stopping dead in it's tracks when it hits an error.

In reality, like everything else in development it's a balancing act where you HAVE to prioritize. How long can you take to code it? How important is its speed? How much improvement does this give me? Does using this 'faster' method ACTUALLY take any more or less effort than the "sloppy" way? How does the speed optimization impact code clarity.

There is no easy answer for this -- but you have to be EXTREMELY careful in making the determination that you do not bullshit yourself about it, or blindly accept someone else's lies and excuses.

You'll notice I use the word "excuse" a lot. MOST of the time, when people try to say why they aren't using the more efficient method -- especially when said method is no more or less effort -- that's ALL that it is. They've swallowed their own BS hook, line, sinker, and a bit of the rod.

I don’t think it’s ill-advised. I personally choose from 2 and 3.

I start with not optimising at all. Having a working feature is more important than having it working fast. Of course, I try to write optimal code at first, but unless I have plenty of time (which us, developers, rarely do) I’m more into keeping deadlines than writing perfect code.

Next, if I know about a piece of sub-optimal code, I fix that. It’s rare, but happens sometimes, and I usually mark it with a TODO comment, and/or open an issue for it.

Finally, I sometimes run my code through a profiler. This is a time consuming thing, as the profiler itself also adds some overhead to the measurement, so you always get a slightly skewed result. It’s a bit cumbersome to decide if the slow code is sub-optimal, or profiling made it slow.

My advise is to do it if you have time, but usually it’s easier (and more useful) to hunt bugs instead of optimising.

One of the biggest problems you have with premature optimization is that you will never be done. You write some code, see how you can optimize it, then write the optimization code. Then you find a way to optimize the optimization code, so you write some code optimization optimization code. But then you come up with some way to optimize that. However, while writing the code optimization optimization code optimization code, you find out, that you are de-optimizing something you optimized before, so you have to start compromising between optimizations.

After spending weeks on a task which could have been finished in a matter of hours, you finally deliver a product, which is over-engineered (as in "no one else can maintain it"), probably even less performant than without all the "optimizations", because you optimized the wrong thing at an expense of literally everything else, and very likely hard if not impossible to extend with new code and features.

Optimizations can be very useful, but only if they are needed. First create the product and check if you actually need to optimize something. If it works and there are no problems, why pour time into optimizations?

3.Profile before optimizing

Because you want to know what to optimize :-)

I would say that it is not quite right to say that code optimisation is ill advised. What is not advised is pre-optimisation!

It is an often recommended process to hit the white board (or brain storm, or put it on paper; different terms pointing to the same concept) before you begin the actual process of writing code. This will allow you to think through any potential bottlenecks that you would have to tackle, and help you sketch out a spec for the module of code you are about to write so that it's interoperable with other modules/parts of your codebase.

Anything on top of the above (including further optimisation, of course after a "profile" proof which would deem the optimisation sensible) should be, in my opinion, an after thought; after you have actual code that works as intended. This is usually done through a self/team code review process!

I've written a super short brief of the process in an earlier article (where we optimised some code involving JS arrays using Array#reduce)

As Addy Osmani had put it:

First do it, then do it right, then do it better!