| > Big-O is to software engineers what Ohm's Law is to electricians. Really? Most of the work that exists is CRUD, and I've seen people who grinded leetcode algorithms, do 1+N SQL queries which is way, way worse, than forgetting what kind of time complexity a sorting algorithm has that you never implement yourself anyway. At the same time these leetcode grinders will over engineer a UI solution to make sure they use the correct data structures to avoid looping 300 times in the browser at the cost of readability writing 30 lines of code instead of 4. I don't remember a single time where I've used Big O in practice. I ask myself - what will happen with performance if there's N amount of traffic or data, but I don't think of it in terms of Big O. I consider perhaps a time it takes or load it takes at upper limit numerically. N might in some cases be terrible, and N times N performance in other cases totally fine. I think actually thinking in terms of Big O might make you worse engineer as you start to obsess over the wrong things. I prefer someone who's spending all that time on building things instead. This time of leetcode grinding and memorising data structures, algorithms could be used on coding side projects. You learn way more and more practical things when you build something. |