Ask the main part of your question in the title. This should be concise but informative.
Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.
Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.
Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
Experience is the best teacher. Keep writing code, revisit old code and rewrite it.
Also, is worth knowing when not to optimise. Code you can read is code you can maintain, and some optimisations are not as readable.
Learn how to use a profiler. Its a bit of an artform, but learning to interpret the results will help you find slow code sections. It'll also help you determine if your optimisations are actually worthwhile. Measure first, optimise second.
Also, is worth knowing when not to optimise. Code you can read is code you can maintain, and some optimisations are not as readable.
This is one of my biggest pet peeves. So many people want to equate the number of lines as a sign of how well it's programmed. But all they really do is chain a bunch of stuff together that makes it harder to debug.
When I started learning programming, I was like "tf is a map function?" and I always forgot about it. Then I tried the functional programming language Erlang and understood all these functions very well. But there is a downside, now most for-loops in C++ look terrible to me :)
The functions you've called out are higher order functions regularly associated with the functional programming paradigm. "In the first place" for a lot of people would be a functional programming course at a university.
For your specific case, rust (like a few other languages) implements these through iterator programming. There's a section in the rust book that might help.
Apart from academia you learn from experience, including a healthy amount of reading other people's code, just like you did to find out about these functions in the first place!
I learned that type of stuff in college, so I can't personally recommend any online sources. However, I can tell you that what you're looking for falls under "Data Structures and Algorithms". IIRC my degree required 3 classes with that name. Lots of sorting algorithms in that field since they make great case studies.
You learn the various data structures and algorithms available, their strengths and weaknesses, how they work, when to use them, etc...
You also learn how to measure performance, like Big-O notation, the bane of many a CS student's existence.
What you're asking about (how to learn clever techniques to e.g. turn your naive O(n^2^) algorithm into an O(n log n) one) is the kind of stuff taught in an algorithms / theory course as part of a CS degree. Here are some of the first search results for open content courses I found that look like they cover the right topics:
https://ocw.mit.edu/courses/18-404j-theory-of-computation-fall-2020/pages/syllabus/
http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=IntroToAlgorithms
You also might want to consider a combinatorics / discrete math course.
In case others want to get into 18.404j, but don't have the prerequisite knowledge, I made a pretty complete graph of all available MIT courses (at least until 2023) and linked them as a left-to-right dependency graph:
https://thaumatorium.com/articles/mit-courses/mit.drawio.svg
Just search for 18.404j - it's an SVG, so search works.
Map, Filter, Reduce Those are the big three for data. More important than those however is mindset and patience with oneself. Writing code that works is the first and most impressive step. Optimizations are fun to think about but unless your computations are sluggish and repeat a lot of unnecessary steps they are rarely a priority.
Build something and shelf it. Trust me, in but a few months you will look back in bewilderment and realize how much you've grown.
but unless your computations are sluggish and repeat a lot of unnecessary steps
In other words, the kind of optimizing that's worth it is choosing a better algorithm to reduce its big-O complexity class.
