When do you think of efficiency? Before/During/After actually coding?

Optimize for readability whenever you can.

Unreadable code is what costs you a lot of time, energy and money later on. Therefore, make sure the code is as readable as possible.

Optimize for performance when absolutely necessary.

Often, optimizing for performance means producing less readable code. This is acceptable if absolutely required, e.g. because you can't fulfill a non-functional requirement without it. If this is the case, it also means that you have a very clear goal: You know exactly how much faster it needs to be, and when you can stop optimizing. That way, you won't spend more time than necessary on the fix and you won't change more of the running system than absolutely necessary.

That being said, I didn't follow my own advice often enough, only to later find out that my performance optimization was completely unnecessary (or worse: broke something) :(

EDIT: There's an exception to this rule: When it's obvious from the very start that you will need to squeeze out every last drop of performance, don't bother waiting until you run into them. This may be the case for OS design, system-critical realtime applications or (far more important in the eyes of the end-user) mobile applications.

All of the above.

I want to know what I'm going to code before I code it, as much as possible anyways. This is usually also where I do the "get it to work" stuff.

While coding the solution I have my IDE set to our coding standards and I try to implement best practices/visual awesomeness/optimizations as best as possible.

After I'm done I always go back and see where improvements can be made.

In general, write your code to work first. Once you've proven it can work, then you make it work faster - if necessary.

Sometimes through experience you learn little tricks that can make small improvements to performance that are little to no extra cost to code up front, so you may implement those in the initial iteration (and if my brain were fully awake I'd give you some recent examples of mine).

As soon as possible.

The primary goal is to get something working. In some cases it may be anything.

Then once you've got it working worry about making it fast.

However, you may need to think about efficiency in your initial coding or design if you know enough about your requirements.

For example, you're writing a social networking site. Initially it's only going to be rolled out to your class/work mates. You've no idea whether it will take off or not, so you don't have to worry about handling 100s or 1000s of concurrent users. However, if you're writing a stock control system and you know that your customers have millions of items in the their database then you need to be looking at how to handle this volume of data from the very beginning.

I tend to write a block of code, ... then worry about modifying it to be more efficient (if possible).

This is generally doomed to failure.

A really bad algorithm cannot be tweaked into efficiency. You cannot put lipstick on a pig.

If, through lack of planning, you chose a dreadful algorithm, what you have written may not ever work acceptably fast.

You must choose the correct algorithm first.

Once you've chosen the correct algorithm, you still have to write tests, write code and make the code look good.

But, if you've chosen the right algorithm, you rarely (1% of the time) need to make it "as efficient as possible". It's already as efficient as possible. The only thing left to do is fix any clumsy coding mistakes that defeat the optimizer.

I take an iterative approach where I get the bare minimum working, test it, then add the next increment and test it, rewriting for readability and maintainability as I go.

As far as efficiency goes, I almost always optimize for the large efficiency gains up front, and almost never worry about the small efficiency gains. That means choosing the best asymptotic complexity for the algorithms and using data structures that work well with those algorithms from the beginning, but not worrying about squeezing out a extra cycle or byte here or there.

However, I also don't sacrifice efficiency for readability or development speed unless it is absolutely necessary. There are times when I know an O(log n) or even O(1) way to do something, but I know I'll never have more than 100 or so elements, and the O(n) way will take me a tenth the time to develop and test, and be very straightforward to maintain.

I always start by writing the most expressive code I can. I worry about efficiency by choosing the correct algorithm for the problem. If the input is known to be small, then a simple brute-force algorithm is better than complex but theoretically faster code. Even O(2^n) may be ok if n will never exceed 20.

I never worry about low-level optimization until I have a demonstrated problem. For example: I don't try to limit Java object creation; if that is a concern then Java is probably the wrong language for the job. Similarly, I rarely save computed properties of mutable classes; doing this by hand is ugly and error-prone.

I've had this up on my wall for awhile. I think it is good advice.

Make it correct.
Make it clear.
Make it concise.
Make it fast.

In that order.

(I stole it from somewhere but I don't remember where. If you could tell me in the comments where I stole it from I would love to know.)

What's the input and output?

Who provides the input, and when/how often do they provide it? That determines whether the input should be stored in some data which is then pawed over by some interpreter-like program, or translated into compilable code to do what the interpreter would do (but much faster).

If you elect the data-structure route, what's the time span between the time information is acquired, and the time it is needed? That determines the minimum data structure you need.

Is it reading a file and processing it? Then ideally it should be I/O bound, reading no more than necessary. Similarly, it should write no more than necessary.

When you've framed the program that way and you've decided you need a data structure, keep it as simple as possible. That means normalized. It means no notification-style consistency maintenance if you can possibly help it. If you must have denormalization, be willing to tolerate temporary inconsistency that you clean up with a periodic sweep.

When you've got it working, then don't optimize anything without letting the program itself tell you where it is needed. Some people say "profile". That's the right idea, but I find random-pausing much more direct and effective. If you start optimizing anything, without having had the program tell you what to optimize, you're walking into the guesswork trap, which is almost always a big disappointment.

I always ask myself, starting out, where the majority of the waiting is going to occur:

1. Waiting for the program to exist so it can be run
2. Waiting for the program to be fixed so it can run properly
3. Waiting for the program to finish executing so you can see the result

If the answer is 1. or 2., then I only worry about efficiency in the sense that I avoid doing incredibly inefficient things (e.g. use a linked list when I should use a hash map). If the answer is 3., then at the outset I consider which algorithms will allow computational efficiency.

Keep in mind that there may be external constraints that alter the decision. For example, if the code is mission-critical, then proper execution wins over rapid execution (so, for example, one would choose to write code in a more immutable/functional style even in those cases where there was an extremely efficient mutable alternative). If the code needs to ship soon, then getting the program working at a tolerable level may be necessary to the exclusion of good performance. If the code is going to be used by hundreds of thousands of people, then tiny improvements in performance--if the program ever takes long enough to be perceptibly slow--save a huge amount of time overall, even if it takes you an hour to shave a second off of a wait time.

If you know in advance that you want code that performs well, you'd better design it that way from the start. Achieving good performance is not just a matter of getting something that works and then applying successive rounds of optimization; you need to have algorithms and a design that are compatible with efficiency. For example, if you have a computationally intensive process that you decide to solve by rearranging a complicated data structure over and over, and then you decide you need to parallelize your code for additional speed, you're going to have a problem.

It really depends on what I'm writing. At times, I glue together code for prototyping purposes to ensure feasibility, then go back to the drawing board and think (usually when reusing/integrating well established software bocks). At other times, I want to make sure things will work as efficiently as possible, so it's pen and paper until I'm confident I can write whatever it is I'm building efficiently, with possible additional optimizations down the road.

For database code, I have learned what are the most likely constructs for efficient querying and I use those first. It doesn't take any longer to write efficient SQL code if you are well aware of what is more efficent and what is less efficient before you start. SInce efficiency is critical to database oriented applications, you must practice codeing for efficiency in my opion. This is not "premature optimization", it is doing the job correctly the first time. Many of the more efficient structures are hugely more efficient than something like a cursor for instance and there is noexcuse for not using tehm from the start. I believe it is different when writing application code, but efficiency is critical when writing database code. Good design should consider what is likeliest to work most efficiently when there are two or more choices in my opinion.