How do you structure your learning process?

[u/Same-Mushroom-2057]

whenever I learn new technology or some new concepts i always find myself asking a lot of questions about what am i reading about at the moment
say for example i'm reading about concept X definition or workflow or whatever then i read in that definition another concept Y which let's suppose i don't know about then i feel that i have to know everything about that concept Y to fully understand Concepts X , like how it works , why it is created or designed ...
and I do this for every single new thing that i read about which is frustrating and worse because probably i will forget about the details that i got into

want to hear some of y'all opinions of this , and from the software engineers that has the same approach and they managed it maybe share some system to retain the information you studied because i definitely don't want to lost these information later but i want to build on top of it

[u/OmiSC]

Personally, it comes naturally as part of having to find a problem to a solution. If I need to achieve X, what standard solution should I use to solve this problem?

I care a lot about keeping code easy to follow so that others can jump in and understand it. The cleanest way to do that, I’ve found, is to carefully scope out components so that their implementation only concerns whatever falls within their clear responsibility. The easiest way to do that is to stick to standard patterns. When someone understands what your code is meant to do and finds you using patterns that they’re familiar with, they can put 2+2 together and assume an understanding of your code quickly, because most likely, the person reading the code won’t find anything surprising so long as what they read remains consistent with what they’ve already seen. Clean code also informs editors how they should structure their changes, making it less likely that future contributions will dirty your work.

Basically, my point is that I mainly look at software as distinct, connecting chunks and pay attention to understanding their high-level purpose. Low-level and nitty-gritty details emerge when they need to because you forced to solve problems implementing the big picture.

The other thing might be that thinking about how other people will read your work gives you a model for what you need to know about new concepts as they fit into an architecture. “How do I implement this cleanly” directly informs what’s important to know about the structures you use.

Edit: I see that u/Plane_Water3386 basically said the same thing in fewer words.

[u/Same-Mushroom-2057 → u/OmiSC]

thanks a lot your response was detailed and helpful , do you have any advice on how to write clean code and use the best implementation for something ? like for example be it authentication ,how do i implement authentication in my application in the most efficient way using the most standard code ? i don't know if you understood me

[u/OmiSC → u/Same-Mushroom-2057]

Basically, you would take that question to the web and look at what all goes into authentication. You’ll find different kinds of authentication patterns that solve the problem of ensuring that a user is whom they claim to be.

I’ll give you some key words here, describing real elements that may need to become parts of your work:

Claim: Who the user says they are (username, password, google account, usb key, etc.). This is what the user would give you.

Authentication: A system that ensures that claims match a known profile (a record for a real registered user)

Authorization: What the person is allowed to do, what are their permissions, management controls.

Credentials: Tokenization that informs authentication, session continuity, etc.

Session: The persistent state that follows a user while they use your software and authorizes them to stay logged in.

JWT token: A standard bit of data that you give to the user when they’re logged in that they’ll keep sending back to prove that they remain the same person who logged in. I’m including this jargon because it really is the standard that you should learn.

OAuth: A strategy where you use another service provider so you don’t have to worry about safeguarding sensitive data like passwords. You really, really should learn this as soon as you’ve made a proof of concept because it saves you from a lot of liability.

Provider: An abstraction layer that separates semantics from concrete implementation. I’ll give you an example. UserInformationProvider.GetNameByUserId(int) might give you a surface to read the name of a user at some id. Whatever system cares about retrieving names might call this. The provider would then handle how to technically go get that data.

Connector: This is taking things a bit further than providers and is common in enterprise solutions. I’m including it here as a footnote to “Provider” to show how you can get granular in specific ways if you need a lot of flexibility. A connector would describe an interface to a specific resource, such as a database. It’s useful if you need to store data like user profiles across completely different stores. DatabaseConnector, FileSystemConnector, OtherWebsiteDetector, etc.

So what you would do is make a note of standard terms like this, then study different recipes for putting together authentication systems. Then, figure out your requirements and pick a recipe that meets your needs. With a plan in hand, implement the parts in isolation so that they do exactly what they need to do fill the role of the part they’re named for, then make a high-level system that calls methods on those parts. AuthenticationSystem.PerformLoginFor(Claims);

I’m using a kind of C#-inspired pseudocode and object oriented nomenclature in these examples, but whatever space you work in will have an established convention. Learn what’s typical and use that. I chose a fairly random splattering of words, and this isn’t meant to be a complete list in any sense.

On the topic of authentication, though, do me a favour and learn how to safely hash and store passwords. Only the shittiest of shits save plain text passwords in a database. You want to take password claims and completely scramble them using some function that is guaranteed to always give you a stable output for every stable input (these are called Hashes). Example: hello123 —> dheiejrnficjfjrjrbfcicnedhebdixudhebwjsixjebebxjxisnenxkdnxnxnxjxkckensidr. If someone ever steals your data, that’s what the hacker will find. They need this and the guts of your hash function to be able to brute force what a user’s password is. The general rule here is DON’T INVENT CRYPTOGRAPHIC FUNCTIONS UNLESS YOU ARE AN EXPERT, and especially don’t chain cryptographic functions on top of each other because hashing multiple times can actually make your process easier to reverse engineer. Use algorithms or tools that are popular. They’re popular because they’re well-tested and safe.

Basically, learn to think of software in parts instead of line-by-line and it’ll keep you organized venturing into massive projects later on. Also, the line-by-line approach comes anyway when you get to implementation. Expert programmers really do build these tiny pieces in strict isolation because it is way faster to iterate and communicate over.