This! Premature optimization is the mother of all evil.

Pro tip: Do not optimize before launch.

Pro tip: Do not optimize before lunch.

I heard this many times and it is stupid. Certainly profiling is useful but you can still make educated guesses. Eg do you create a database index on your tables? Well if you don't then some support dev has to clean you mess later.

@spacem maybe this can be more of a guess with your database example, but when dealing with any compiled language this is definitely true. Compilers do a lot of magic to optimize for you so things that seem like they might be the problem the compiler might treat completely differently (it might have already solved your problem) a lot of times slow code comes from a aplce where you think you are doing something clever for speed but the compiler doesn't think it's so clever and when it's converted into assembly it actually takes longer than a simple solution

I get the point. This guy needs that kind of advice lol
https://devrant.io/rants/1288278/...

I just don't like the never optimise opinion since there are exceptions..

@Condor optimizing the code and keeping the features to the minimum are two totally different things. This post is about premature code optimization @Axis described it well above. Personally, at least in the past, the more I have optimized the more feature ideas have come to my head and I have implemented them to only realize later that their ROI wasn't worth it, as a very small portion of the users would use it.

I think the idea is to code while keeping in mind the basics...

Such as no doing a dB query in a loop when you can get it all at once before and things like that.

Than, later on, run profiling on your code to identify the bottlenecks, than act on those...

That way you can prioritise what to deal with first, and perhaps more importantly, measure the effects of your changes