I decided to learn how to surf several months ago, I watched YouTube tutorials and have practiced weekly since then. Yet, I’m still pretty bad at that. So bad that this weekend I finally took the first professional lesson and that lesson taught me not just how to surf but also how to answer the question “Why do we need to learn all these basics like algorithms and data-structures?”
With my surfing activity, I was trying to overcompensate the lack of stability and speed with different timing and more intense paddling, effectively wasting a lot of time and energy doing so. Turns out the root cause was completely different and I simply didn’t place my feet the right way…
The same idea applies to the basic ideas of computer science: the hardware architecture defines which data structures and algorithms are more efficient, and the limitations and advantages of particular algorithms shape high-level design approaches (think about pointers, lists, hashmaps, mutexes, immutability, functional programming, reactive programming, map-reduce, etc.)
I wasn’t able to improve my ride by solving symptoms like low speed and poor balance with wrong and time-consuming measures like harder paddling, similarly, someone not familiar with the basic limitations of an algorithm or a library can waste months in attempts to improve the app performance tweaking inputs of this library based on suggestions from Stack Overflow and YouTube.
That doesn’t mean everyone should be able to write a sorting algorithm on a whiteboard (unless we a talking about passing an interview in Silicon Valley) but it definitely helps to know the typical efficiency and potential bottlenecks.
Data structures and sorting algorithms are low-level details, the higher-level design is vaguer and there is rarely a single indisputable best solution, but I’d say that the rule of basics still works. Say it’s unclear whether to apply relatively simple and well-known principles such as SOLID to an OOP system. One can argue that printing and formatting a string are two different responsibilities while someone else can say that formatting is essential for printing. To resolve such contradiction we can again turn to basics and ask a simple question: “What is the fundamental problem the solution I’m applying was designed to solve?” The answer may be a bit more verbose than a distilled form of SRP but it will be more precise as well. Bob Martin coined the term SRP to address the problem of the requirements that change for different reasons and cause the code changes which in turn often leads to regressions. In fact, the original definition of SRP is not complex
“Software module should have one and only one reason to change”
what we have here is the definition of a broader basic problem that can answer not only the questions which libraries, classes, function to split but also which ones to join. So a better understanding of the underlying principle can lead to a better design.
Like almost anything in this world, education isn’t free and learning basic stuff is a long, tedious process that never pays off immediately, but the fast “give me the single answer” approach may not pay off at all. A surf coach told me that I need to repeat feet positioning exercise twice a day, every day, at home, on the floor. I don’t need a beautiful blue ocean and golden beach for that, it’s not much fun, just a solid tangible result.
