[beeboobaa3]

That's just a rude thing to say. If you all coded like him you wouldn't be having the discussion.

The issue is when you have people who do not code with efficiency in mind, and someone who does think about those things reviews the code.

Most efficiency gains are probably marginal and not that impactful. So you're probably OK ignoring it. And it's true that bringing such things up during code review and then going back and changing it will take more time.

But if people wrote the code with efficiency in mind to begin with they likely wouldn't be spending much more (if any) time while writing the code. Just have to use their brains a lil.

[tracker1]

And then you get an in-memory SQL database that is used for cached settings with a text-based SQL query to retrieve every configuration setting (thousands of times during a login) and have a login that takes many seconds to run.

Literal example... replaced with a lock-free hashmap, and reduced the blink of an eye in terms of time.

[xandrius]

I don't see the problem here: the original dev delivers quickly, the next dev gets to solve an interesting problems and gets to show off how much time they saved.

[tracker1]

They could have used any hashmap or dictionary in the first place... The DB solution was far more complicated.

[gcarvalho]

Delivering the over-complicated feature and improving the performance of the over-complicated feature both seem to get more praise than shipping the simple version to begin with.

[beeboobaa3]

Who cares? Do you do your job for head pats or to actually get shit done?

[gcarvalho]

To make a living. Being acknowledged is good to keep at it, or so I heard.

[trgn]

This is it. People could write the code with a lean footprint the first time around.