One of his articles helped me in a debate about a codebase once. There were two camps at the company. One camp believed that we should be looking to optimise th

One of his articles helped me in a debate about a codebase once. There were two camps at the company. One camp believed that we should be looking to optimise the code we wrote by choosing faster options such as for loops over slower chain functions such as forEach (application was written in Typescript, I don't know if this is the case for all languages). The other camp classified these kinds of changes as micro optimisations. I belonged to the former. The code base was huge and the application was slow bordering on unusable. I used the Dave Brailsford British Cycling analogy from Atomic Habits that the aggregation of marginal gains can result in big changes on the macro level. Or put in other words, one non-optimised function might not make much of a difference but lots of them in a massive code base with millions of lines most certainly does. My co-worker's response was that he was not sure that the analogy from cycling transferred over to coding but I could tell that it was at least giving him pause for thought. In reality, there were many reasons for how slow that codebase was. There were most certainly bigger fish, but I still believe that choosing more optimal language options where possible would have helped.