4 ms·
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 effici
by beeboobaa3 2y ago
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.
- deleted 2y ago[deleted]
- trgn 2y agoThis is it. People could write the code with a lean footprint the first time around.
- tracker1 2y agoAnd 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 2y agoI 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 2y agoThey could have used any hashmap or dictionary in the first place... The DB solution was far more complicated.
- gcarvalho 2y agoDelivering 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 2y agoWho cares? Do you do your job for head pats or to actually get shit done?
- gcarvalho 2y agoTo make a living. Being acknowledged is good to keep at it, or so I heard.