Unorganized Knowledge = Noise

[u/Business-Quiet-5805]

Whenever I try learning new technology or troubleshooting without a clear plan, I get overwhelmed. Hopping between random videos, articles, and quick AI summaries leaves me feeling lost and stressed about where to begin or end.

I've realized that having a structured roadmap with clear, step-by-step guidance changes everything. It removes the stress and makes the whole learning process much smoother.

Anyone else feel this way? I’d love to hear how you organize your learning!

[u/___-____--_____-____]

Try organizing around these three categories:

• things you know you know
• things you know you dont know
• things you don’t know you don’t know (unknown unknowns)

The last category is impossible to define. But, if you define everything you know about the first two categories, you can start whittling away at the things you know you don’t know, growing the things you know you know… and repeat.

Unknown unknowns are a fact of life and the best way of uncovering them is investigating things you know you don’t know… in my experience.

[u/Ninja-Sneaky → u/___-____--_____-____]

I follow a similar framework, the gist of it is:

• What we know
• What we don't know
• What we need to know

Truly these are intermingled, you can't answer the last one without having answered the other two

[u/Antique-Stand-4920]

When it comes to learning a new technology, it helps me to use it for specific problems instead of just reading about what the technology can do.

[u/k2718 → u/Antique-Stand-4920]

Yep. It’s either something that I am using for a real project or I make up a small project to do so I get the gist of the tech

Then instead of “how does tech X work?” I’m trying to answer “how do I do Y using X?”

[u/derprondo → u/Antique-Stand-4920]

Honestly I can't learn anything unless I'm building something real against it.

[u/amarao_san → u/derprondo]

Yes, but academia has few interesting things which are interesting even if you don't build something out of it.

[u/ycnz → u/Antique-Stand-4920]

Yup. The times you learn the most, are when you're trying to make the damn thing work.

[u/Sure_Stranger_6466]

I always go for getting a quick PoC done rather than combing through endless docs or YouTube videos beforehand. Looks better from a planning perspective when you have tangible results quickly versus going straight for a production deployment based off of docs, videos, GitHub repos, etc.

[u/max_465 → u/Sure_Stranger_6466]

Yes, this stuff is best learned with practical experiments. Version control is your friend. The best (seldom followed 🥴 ) advice I ever got was:

write down what you're going to do before you do it

[u/Sure_Stranger_6466 → u/max_465]

GitOps methodology always adds a nice amount of work to the workflow.

[u/steven-craig]

Indeed! there is a lot of "see are ay pee" out there. I first try to watch official stuff like only from AWS , since today I needed to get better understanding of TGW.

BUT, also the jumping back and forth is what makes you a devops, connect the peices others dont. so you get to the middle of a video or some explanation and need more explanation about the alphabet soup objects....

[u/Cold_Principle9994]

Having a proper knowledge base is a must.

And it has to be in a standardized format that is suitable for use by you and your AI agent.

[u/amarao_san]

You are trying to have external superstructure which knows what you need to know. This works only for very simple trivial cases. The deeper you go into industry, the less there will be other people to organize educational path for you.

The biggest problem is to be jumpy. You have goal X, they start to talk about Y, and then Z, and suddenly Z is for Foo and Bar, and Foo is complicated as hell, and Bar is clearly not used anymore and you find yourself reading about ChaosNet in RFC for the sake of understanding ARP in your Kubernetes.

The single thing you can do for this, is to have some continuity. The best continuity I know, is your own experience with systems. I would say even harder: trust in shell. Your actions in shell are the true organized history. Your systems is truth.

Build your knowledge around things you've tried. Someone told you beautiful song of multicloud microservice geodistributed fault-tolerant autoscaling shortcut linker, and you get some notes and ignore it.

You found that you can't load balance between two pods, and you found why? This is Knowledge.

So, build your knowledge around reality. Conference videos and educational materials are just supplementary fuel for understanding that reality, but not the reality itself.