- eg: consumer thread dequeue() method. When empty, it “should” be waiting for a notification, according to Jun of Wells Fargo, but a simpler design returns a special value to indicate empty. The thread can then do other things or return to the thread pool or just die. I think the wait model is not ideal. It can waste a thread resource. We could end up with lots of waiting threads.
- Eg: https://bintanvictor.wordpress.com/2017/09/10/lru-cache-concise-c-implementation/ requirement is daunting, so it’s important and completely legitimate to
simplify lookup() so it doesn’t insertany data. API is simpler, not incomplete
- Eg: find every combination adding up to a given target #Ashish permutation within each combination is a separate issue and not the main issue
- recursive solution is often a quicker route to working code. Once we cross that milestone, we could optimize away the recursion.
- eg: extract isPrime() as a unimplemented function and simply assume it is easy to implement when I get around to do it.
- Eg: show free slots between meetings #bbg I solved a similar and more familiar problem.
- eg: violation check for Sudoku is a tedious but simple utility function. We could assume it’s available
- eg: violation check for n-queens is likewise slightly harder