Nectar is my personal engineering knowledge base.
It was born from confusion, struggle, and pain.
I built it because I didn’t have the luxury of assumed knowledge.
Coming from a non-traditional background, I couldn’t rely on intuition, shortcuts, or “you’ll understand later.” If something worked, I needed to know why. If something failed, I needed to know where and how.
So I wrote things down:
- Sometimes a full architecture.
- Sometimes a single command.
- Sometimes a mistake I didn’t want to repeat.
Over time, those notes became Nectar.
This repository reflects how I actually learn and think as an engineer.
When I encounter a new tool, system, or concept, I don’t approach it academically. I try to understand how it behaves when deployed, operated, misconfigured, stressed, or broken.
Everything here was confusing to me once — and I wrote it in a way that removed that confusion.
If I learn even one small thing that improves my understanding, I document it.
- Not to teach.
- Not to impress.
- But to retain clarity.
That habit, repeated over years, is what you see here.
- This is not a tutorial site.
- This is not copied documentation.
- This is not a certification dump.
- This is not optimized for beginners.
There is no fixed reading order and no guaranteed starting point — because real engineering work doesn’t happen in sequence.
I actively study from this repository.
I use it to compress large amounts of information into forms I can quickly revisit — sometimes reducing hundreds of pages of material into a few dense pages that only need to make sense to me.
I return to it when:
- I forget something I once understood
- I need to reconnect scattered concepts
- I want to reason through a system again
- I want to avoid repeating an old mistake
Some documents are intentionally dense and non-explanatory — built as personal “master keys” rather than teaching material (for example: Kubernetes Master Key).
I couldn’t understand tools until I understood the problems they were created to solve.
That principle sits at the core of how I think as an engineer.
I don’t treat failures as disasters. I treat them as engineering signals.
When something breaks, I slow down instead of rushing. I observe instead of guessing. I try to understand what actually failed, not just what stopped working.
I don’t depend on tools. I depend on understanding.
Tools change. Principles don’t.
Nectar represents distilled understanding, not accumulation.
It reflects extracting essence after confusion, repetition, mistakes, and time — not collecting everything indiscriminately.
This repository is alive.
It grows when I learn. It stays silent when I don’t. It will never be finished.
And that’s the point.
If you are reading this as an engineer, explore freely. If you are reading this as a reviewer or interviewer, this is how I think.