1–10 of 44 posts
Binary search I use a few times for an ecommerce cart. I remember to avoid putting loops inside loops.
I use Don't Repeat Yourself (DRY) and SOLID principles for code design.
Besides that, I haven't used them all that much. Which do you find most useful?
That said, the Single Responsibility Principle and Separation of Concerns (the "S" in SOLID) are things that I find important to adhere to. The trick with many CS ideas is to apply from them from first principles.
Example: Instead of some rule like "Your functions should never be more than N lines long." you should instead, ask yourself if the function is trying to do too many things i.e. deviating from the Single Responsibility principle.
I find performance / architecture stuff in general to be useful to know, along with having an intuition for orders of magnitude. Too much needless complexity exists in enterprise CRUD web apps for a 1.01x speedup.
My last project involved making calculations, clustering and specific spatial queries over a set of 4D points ( GPS + time ) there is no way to make competitive complex applications if no one in your team understands O-notation, Dynamic Programming, Euristics, Graphs Theory, etcetera.
https://en.m.wikipedia.org/wiki/De_Morgan's_laws are incredibly useful when trying to analyze or simplify conditionals.
https://en.m.wikipedia.org/wiki/De_Morgan's_laws are incredibly useful when trying to analyze or simplify conditionals.
Mind explaining how exactly de Morgan’s law comes up in your day to day?
For really tricky cases, I'll use a Karnaugh map, but those don't come up very often.
Hard CS is rarely needed in my projects but there are times that it's unfeasible to make things work without it. My last project involved making calculations, clustering and specific spatial queries over a set of 4D points ( GPS + time ) there is no way to make competitive complex applications if no one in your team understands O-notation, Dynamic Programming, Euristics, Graphs Theory, etcetera.
Building services as utilities with generalized input/output interfaces that know as little about your application almost always results in better code. If I can write something that could easily be pulled out into a generic package and used on projects with totally different data models and business logic, then I've built something right.