So, I had a friendly debate with my senior dev today working over this feature.

What do you say is the best approach?

1. Optimize at the time of building the feature.
2. Do the feature work, optimize all at once. (let's say on a time cycle).

Bit of both,

Optimise the piece of work while you build, cut the obvious bloat but only to the degree it needs to run as expected, afterwards revisit and cut it down further as you'll know what it's designed to do and you'll understand the feature better to be able to improve it.

I'd say to write the cleanest code first, but also avoid making stupid structures that are obviously inefficient if it's not much effort to make them better. Then you can start optimising from the code that wastes the most time so you don't have to make optimisations that don't make a difference.

There is no need to optimise while you're still trying out different potential solutions to see which one works best. No need to optimise some utility function you've just added until you're sure you're keeping it. No need to optimise code until you're confident other developers will approve your implementation approach.

On the other hand, if you need to write a function with well-defined requirements and use cases (i.e. functionality you know is necessary and won't go anywhere), better optimise at the time while you still know exactly how it works and what to pay attention to.

And what does it even mean to optimise? Remove some leftover code and rewrite some inefficient accessors, or change intuitive O(n^3) algorithm for a much more complex O(n log(n))? If it takes you an extra minute or so to optimise code using an efficient data structure, do it now. If it takes you an extra day or so to come up with a more efficient algorithm, do it when necessary.

3. Optimize only when it's required.

optimization isn't something you need to force unless there's a need for it. Sometimes it's better to have unoptimized code that anyone can easily edit and change, than super optimized code that is so baked-in that changing it will require rewriting it in a major way.

it's only useful to optimize when it's a requirement, say your SLA requires fast responses, the client has noticed a huge slowdown, you're working with limited hardware resources...

I'm not saying write bad code. I'm saying write good code, but don't force every 5ms or 20kb improvement if it doesn't benefit the product in a major, even critical way

Rinse and repeat.

When you write software,you'll always notice things that you can improve or that might be better.

If you can incorporate it in a short time, talk about it with another team mate to have another perspective and do it.

If it takes a longer time or you're unsure, discuss it in team / plan it as a future change.

Always discuss things with other people.

Over optimization / engineering is just shit. Maybe the bright idea you had had been unsuccessful before / doesn't work like you think it does /...