In my opinion - data structures. Implementing LinkedList, Trees, and even a Stack and a Queue can open your mind when solving problems. Understanding data structures help to understand why there are so many database types. Why there are tabular, key/val, graph and even message queues. That leads to strong architectural choices.
What stuck most with me from studying CS (and isn't even a very abstract topic) are Design Patterns.
Learn to recognize and apply patterns and take the time to learn patterns from people who've already dealt with many failures so you can avoid solving them yourself.
Big O seems like a sensible first step. For a wider scope, I truly recommend Rob Conery's The Imposter's Handbook. It's a great intro to a variety of topics that will help you in your career. bigmachine.io/products/the-imposte...
Depending on what kind of dev you are focused on, I really appreciated some courses on computer architecture - circuit design, machine language. Helped give a better conception of how computers actually work, and iron out misconceptions. Also OS design. Maybe not a first priority tough.
However I do believe learning algorithms is a great tool to have a a developer or a software engineer in many cases. Because you would need to solve a problem in a very efficient amount of time or not in a coastly time. It's also henaces you probelm solving abilities and how you approach problems in a very efficient way. What I mean by efficient is how you determine weather the algorithm or process is not efficient or is the the fast way of doing it.
I hear a lot of people shouting big O notation and I understand is relevance, however you can also explain the price you pay for certain algorithms and it's "expensive" without referring to big O, or log n, and etc. for example you could say this algorithm is efficient but if the length of a array Is n is a costly matter meaning this takes O(n) or in lamen terms a long process because of the length of the array and how long the process might take
Latest comments (64)
Design pattern
In my opinion - data structures. Implementing LinkedList, Trees, and even a Stack and a Queue can open your mind when solving problems. Understanding data structures help to understand why there are so many database types. Why there are tabular, key/val, graph and even message queues. That leads to strong architectural choices.
What stuck most with me from studying CS (and isn't even a very abstract topic) are Design Patterns.
Learn to recognize and apply patterns and take the time to learn patterns from people who've already dealt with many failures so you can avoid solving them yourself.
Design patterns
Watch Crash Course Computer Science on youtube. It gives a good overview of almost every subject a CS student is going to encounter.
Big O seems like a sensible first step. For a wider scope, I truly recommend Rob Conery's The Imposter's Handbook. It's a great intro to a variety of topics that will help you in your career.
bigmachine.io/products/the-imposte...
ricardogeek.com/docs/clean_code.html
Depending on what kind of dev you are focused on, I really appreciated some courses on computer architecture - circuit design, machine language. Helped give a better conception of how computers actually work, and iron out misconceptions. Also OS design. Maybe not a first priority tough.
Computer architecture is great because it's fundamental but also not too abstract
However I do believe learning algorithms is a great tool to have a a developer or a software engineer in many cases. Because you would need to solve a problem in a very efficient amount of time or not in a coastly time. It's also henaces you probelm solving abilities and how you approach problems in a very efficient way. What I mean by efficient is how you determine weather the algorithm or process is not efficient or is the the fast way of doing it.
I hear a lot of people shouting big O notation and I understand is relevance, however you can also explain the price you pay for certain algorithms and it's "expensive" without referring to big O, or log n, and etc. for example you could say this algorithm is efficient but if the length of a array Is
nis a costly matter meaning this takes O(n) or in lamen terms a long process because of the length of the array and how long the process might take