Learning note / Reflections on my studies
Data Structures & Algorithms
This topic changes the question I ask about working code: how much work will it do as the input grows? A correct answer on a small example is only the beginning.
Following the work, not just the result
I find it useful to count the operations an approach repeats. A loop inside another loop can look harmless until the number of records increases. Complexity gives me a way to discuss that growth without relying on one machine's timing.
It also helps me compare approaches before committing to an implementation.
The structure changes the solution
Stacks and queues make ordering rules explicit. Trees organize relationships. Arrays and lookup structures fit different patterns of access. Thinking about those differences helps me avoid treating every collection as an interchangeable container.
The question I come back to is what the program needs to do most often: search, insert, remove, traverse, or preserve order.
A useful habit for application work
I do not need to invent a new algorithm to use this reasoning. It is relevant when processing records or deciding whether to repeatedly scan a collection. I want the choice to fit both the data size and the clarity of the code.
What I take forward
- Consider growth as well as correctness.
- Match the structure to frequent operations.
- Balance efficiency with code that can be explained.