Some algorithms and data structures really are better than others, but not in every situation. The difference shows up when the data gets bigger. A simple list with linear search works fine for a dozen items, but when you’re dealing with thousands or millions then checking everything one by one becomes painfully slow. That’s when a hash table or a balanced binary tree saves the day because they keep the most common operations (lookup, insert, delete) fast no matter how much data you throw at them. O(N) versus O(1) or O(log N) is the difference between a program that finishes instantly and one that makes you wait minutes.
Through this process I've tried to make my own process pretty straightforward. Before I write a single line of code, I figure out which operation will happen the most often. Is it looking something up by a key, then hash table. Do I need the data to stay sorted automatically, then tree-based structure. Am I mostly adding to the end and reading everything once in a while, then a regular list or array works and keeps things simple. Then I glance at the expected Big-O for those key operations. If the main one grows linearly or worse when the input size doubles, I know I’m starting with the wrong structure and I change it early.
That single habit (asking “what do I do the most?” and then picking the structure designed for that) has made my programs faster, cleaner, and a lot less stressful to debug. It’s one of the biggest takeaway from this process. Choose the right tool for the job you actually have, not the job you wish you had, and everything else falls into place.