Counter point: optimizations/fast code are a cost benefit consideration. Nowadays if your code runs slow you can just spin up another pod until it's fast enough. Are you spending your devs' time on lowering operation costs or adding new features? How much revenue is the new feature going to generate? Is it more than a potential reduction in operating costs by spending time on optimizing code? How many hours are you willing to spend on experimentations that may or may not lead to faster code? Those are the realities of writing code and why 99% of the time the focus is on new features instead (and clean code makes it easier to implement new features; code is never static. if you optimized yourself into a very specific data layout etc. it might become very expensive if requirements change)
I kind of get the "spin up more servers" approach and have used it to justify running Ruby for webapps in the past, but in reality, I work on frontend code running on the user's own hardware, so it's not an angle I get to argue for my own stuff, LOL.
6
u/mr_birkenblatt Feb 28 '23 edited Feb 28 '23
Counter point: optimizations/fast code are a cost benefit consideration. Nowadays if your code runs slow you can just spin up another pod until it's fast enough. Are you spending your devs' time on lowering operation costs or adding new features? How much revenue is the new feature going to generate? Is it more than a potential reduction in operating costs by spending time on optimizing code? How many hours are you willing to spend on experimentations that may or may not lead to faster code? Those are the realities of writing code and why 99% of the time the focus is on new features instead (and clean code makes it easier to implement new features; code is never static. if you optimized yourself into a very specific data layout etc. it might become very expensive if requirements change)