Why am I doing all these interviews that grill me on big O(n) if they’re not even using it?!
It is important to understand asymptotic complexity, but the places where it's useful in the real world are very different from textbook examples or Leetcode problems. You'll rarely have a triple loop in your code that makes you think, hmm, maybe I can reduce this to a double loop. That can happen, but these are more frequent problems I've seen: * Application code is issuing too many queries to the database. The clas…
I can give a personal piece of anecdata on this.
I was using a static application security testing tool on a huge repo (over 2M lines of code). It reported a couple thousand issues, nearly all of which were issues on code style rather than actual security issues.
Generating a report would take literally 2 DAYS and would grind the database server so hard that any other use of the SAST suite had a noticeable impact. I decided to run a profiler and see what queries were hitting it so hard. Turns out there was a SELECT that was being used a lot, but the columns being searched weren't indexed. I don't remember the exact query, but I'm guessing it was searching all the code in the repo that was stored in the database repeatedly.
I manually ran a CREATE INDEX. It took about a day for it to complete, and it added a couple gigabytes to the database. But now, those reports went from 2 days to about 20 minutes.
> If you’re writing Java code that has to make calls ten levels deep to get anything done, those levels of indirection aren’t free.
I'm of the opinion that any time you're performing type introspection, reflection, and ".invoke()", it's a code smell, but I suppose middleware in Java is impossible without them due to its draconian type system.