4 ms·

That's something that I ask myself everyday. Is it worth it to push the big O notation to the limit, saving couple of megabytes RAM or I can simply deliver and

That's something that I ask myself everyday. Is it worth it to push the big O notation to the limit, saving couple of megabytes RAM or I can simply deliver and have a happy boss. I've always been fond of "premature optimisation is the root of all evil" [1], but still... wasting resources makes me feel bad. I feel like the guy that buys 10 plastic bottles of 0.5l water instead of 2x2.5 litres. The guys building ( owning ) Slack, cryptocurrencies, e-commerce websites are on the other end though. I hardly can count a day when my MacBook's fan doesn't spin like crazy, because I'm just visiting an HTML page to read the text. In other words. Yeah ... you can save some precious time to optimise that, because you don't want to be the person that starts the fans of colleagues' Macs ( having a docker image with your app running on my Mac ). Energy is what you are saving and that's priceless in today's polluted world. 1: http://wiki.c2.com/?PrematureOptimization http://wiki.c2.com/?PrematureOptimization

hinkley 8y ago
Make it Work, Make it Right, Make it Fast. On several projects the management and sales team were at odds with the dev team about app performance. They wanted it faster and the dev team was full of premature optimization cargo cult members. By cult member, I mean people who say that phrase to get out of thinking. The line between right and fast is blurry. There’s a big chunk of refactorings that improve readability and performance and if you work with those you get better at your job, avoid the cult members and please the business. Now that I’ve typed that last paragraph I want to go through Refactoring and categorize the ones that fall under “right and fast”...
- jay-anderson 8y ago
  Very much agreed. Like all things balance is needed. Often it's worth thinking about performance during initial design. There's the idea that fixing bugs earlier in development is cheaper. This also applies to performance issues. That's not to say you spend an inordinate amount of time focusing on just that, but it needs to be given its due.
cyphar 8y ago
The thing is, Docker Golf is possibly the worst way to optimise the real costs of container images -- because it comes at the cost of maintenance (distributions exist for a reason). A much better solution is to fix the image format to better handle the usecases that it needs to handle. (This is what I'm working on at the moment.)

hinkley 8y ago

Make it Work, Make it Right, Make it Fast. On several projects the management and sales team were at odds with the dev team about app performance. They wanted it faster and the dev team was full of premature optimization cargo cult members. By cult member, I mean people who say that phrase to get out of thinking. The line between right and fast is blurry. There’s a big chunk of refactorings that improve readability and performance and if you work with those you get better at your job, avoid the cult members and please the business. Now that I’ve typed that last paragraph I want to go through Refactoring and categorize the ones that fall under “right and fast”...

jay-anderson 8y ago
Very much agreed. Like all things balance is needed. Often it's worth thinking about performance during initial design. There's the idea that fixing bugs earlier in development is cheaper. This also applies to performance issues. That's not to say you spend an inordinate amount of time focusing on just that, but it needs to be given its due.

cyphar 8y ago

The thing is, Docker Golf is possibly the worst way to optimise the real costs of container images -- because it comes at the cost of maintenance (distributions exist for a reason). A much better solution is to fix the image format to better handle the usecases that it needs to handle. (This is what I'm working on at the moment.)