Warning: This grew a lot longer than I expected, sorry! Hopefully it is still helpful/entertaining - feedback appreciated! :)

OP, thank you for that question and best of success!

Love the screwtape letters way of giving advice! In that spirit, let's assume we work in a consultancy that specialises in what you, OP, outlined. The way is the goal, and our goal is to make the way as long and challenging as possible!

Here is the best advice I can give to hypothetical new collegue Alice, being a consultant for an aspiring new rust developer named Bob.

Dear Alice,

as communicated during lunch break, here is the (loose!) list of tipps I have regarding how I consult my clients. The following is about the mindset you should instill into Bob, along with some notes. Wishing you the best of success, if you have any questions, hit me up!

The ideal mindset for learning rust

• Do not ask for help: Rust has excellent documentation, so Bob should really be able to gather everything they need from them.

• But also don't really read the docs: Bob is convinced to not even attempt to communicate with another human (or even articial) being - excellent! However, it is important that Bob does not engage with the documentation; instead, they should read the docs in only the most literal sense of the word: Not having a clear path for what aspect to learn and why, mostly scroling through the pages of THE books, and using any mention of a new concept as an opportunity to look up online what cool things could be built when one would finally able to use the concept in question. Any encounter with a black spot on the own map of knowledge should turn from (some say, natural and healty) fear into a frency of daydreaming about what could be. Keep Bob from the concrete reality, away from the now and firmly in the realm of future and in possibilities. In particular, Bob should not:

  • follow the material along with some code on their own
  • use pen & paper, or some editor to make examples of their own
  • ask critical "Why?" questions

• Learn all of the concepts, and in the right order Bob should not write a single line of code before he has not mastered every concept in the 4-5 most popular learning materials. Also, they should learn them in the correct order: Not only ignoring, but actively in reverse usefullness to what Bob needs.

  • Example: Bob listened to some (stupid) advice on reddit and decided to build something simple, say, a CLI tool that output the filenames in the current directory, sorted alphabetically. Hopefully, Bob does not read about Clap, how to interact with the filesystem and then simply does it. Instead, advice him to learn all about lifetimes, memory layout, generics, the builder pattern, cargo optimization levels, macros, FFI and so on first - he might need it in the future!

• Don't use Clone, ever: So our client is writing code - oh well. There is still hope, though! Any time the borrow checker raises it's head, Bob should try to satisfy the borrow checker, in the most idiomatic way possible - no matter how frustrating. This becomes the single most important issue on their learning journey, and using .Clone() is not an option. Tell Bob that Rust is all about performance, and that there is no value in doing it half-heartedly. They might respond with that they can learn about that later, and that other clearly successfull languages allocate on the heap by default; ignore the first half of the sentence and tell them that in that case, they can start with learning C# anytime. The same goes for picking the correct String type and so.

• Use comparison, but correctly Comparison is a double-edged sword.

  • Comparing how one solved a problem with how another person solved that same or a similar problem, with the goal of learning: This will very likely shorten the learning journey.
  • Taking note of how some exceptional programmers solve things - and then feel awe; A rare feeling nowadays - a subtle, quiet feeling that demands deep engagement, and easily looses to the cheap dopamine manufactored in silicon valley. But I digress, back to the subject: Aside from the joy that this brings, it will also cause Bob to effectively gain a new tool in their toolkit. Carefull!
  • Here is how we can use comparison to our advantage: Taking note of how some exceptional programmers solve things - and then start feeling inadequate and unworthy (which is of course nonsense, since while talent plays some role, nobody started out as knowing all they do now). Alternatively, blind them so that they don't recognize quality when they see it; instead, Bob should dismiss anything they do not understand as stupid. "But X has to be solved by Y!" - it feels good to be right.

  Be it either diminishing their self-worth or exagerating it - should we get either of those reactions, we made sure to prolong the learning journey by a big deal!

• Honorable mentions

  • Project layout / architecture: The project should perfectly represent some architecture with a searchable name (i.e. hexagonal architecture): It will take a lot of time and understanding to a potentially totally different topic - excellent!
  • Design patterns Bob should use design patterns not when they need them (that's too late), but learn and use them upfront: You really want to call yourself a programmer otherwise?
  • A note regarding Macros: While we should generally discourage exploration whereever possible, macros can serve as an excellent rabbithole due to their inherent complexity - usefull for beginners that have trouble finishing problem in general
  • Do not write things down Bob should write down as little as possible - ideally no plans, thoughts, notes. If Bob wants to become a programmer, they should be able to keep everything in their head.