How did you learn something (programming topics) in depth? How did you practice to explain something confidently?
If a young professor had to teach an introductory course (say Physics, Calculus, Chemistry, CS) the first time and didn't have a curriculum, notes, problem sets, tests and stuff available they'd have to work very hard.
If you inherited all that stuff and then spent 30 years teaching the class you find it very easy.
I have an online antagonist that I really want to screw into the ground. I have been studying a subject that person talks about for a little more than six months. I think I am at the 25% mark of being an "expert" on that subject.
Already I can write a few sentences that destroy one of those person's blog post maybe 20% of the time. If I get to the point where I am 80% successful at that I'm going to feel like I've won at "debating" if not actually practicing the subject... And those are entirely different things.
Discussing a subject like that pedagogically is a lot like developing a comedy routine or other performance, it takes getting your emotions and motivations in the right place, practicing over and over to not get hung up (or have your listener get hung up) over details, etc.
It's certainly ironic that I am pursuing an antagonism relative to this subject but the antagonism started after I started studying it!
(It's more contradictory than you think... Whether you transmit emotions by osmosis or physical synchronization, plant your feelings like seeds, or pack them into balls and throw them at people to hit them like lightning bolts you find it doesn't matter if your feelings are 30% hostile, 10% hostile, 1% hostile, or 0.01% hostile... you drive somebody out and the only consolation you have is that they can never quite articulate what you did. I'd like to think that I use that antagonism as a "probe" or a "lightning rod" to keep ahead of those feelings.)
I've got no interest in being a trainer on this subject so I certainly don't need to teach it, but being able to "talk a good game" helps me use discursive reasoning to align myself morally (as a practitioner I really can make the world a better place.) Also like it or not I am always having to explain why I am doing something that seems incomprehensible... Myself "talking a good game" has sometimes convinced me completely of things I didn't really believe also so it helps me as a practitioner.
I'd first build yourself time to interview those who are there, and understand why they are there. Trust them and save their words for later, make sure you can describe their progress in terms of the words they themselves used.
Ask them if they learn best in narrative style (ground-up, first principles, etc.) or if they prefer the outcome-first style (opportunism + fast break-fix cycle = speed of outcome, also connecting back to integrate first principles opportunistically/periodically).
Confidence is a high-risk, comparatively low-reward terminology/mental model that can be replaced by lots of other helpful things. For example, what if instead of being confident, you focused on them and made them present, teach, or demonstrate to you? An extreme example (it's usually some mix), but confidence almost always has the risk of placing too much importance on the speaker/teacher's subjective role. This can torpedo any teaching gig. Keep in mind students are there with lots of self-expectations, those need to be discussed and leveraged. Good luck.
In the last few years I have learned about construction/building codes, cars/engines, continued expanding my programming knowledge and also smaller things that come up as I exist, including investing/personal finance. The depth of the knowledge in those areas depends on the problem.
My key to learning is: quickly applying what I learn or learn to solve a problem I have. The solving a problem I already have supercharges my learning capabilities and puts my brain into overdrive. I often get fixated on a problem and my life start revolving around figuring it out. Obviously, some things are just not reasonable. I gave up on learning some things and just paid to have it done, but usually like to at least make an attempt.
A direct example to your question, when I was younger I enjoyed wrenching on cars. I bought a car and at some point after the warranty was over I realized the engine was toast. I did not have the means to pay someone to just build a complete engine for me. I ended up doing research and seeking advice. In the end I was able to tear the whole engine apart, contract out the machining of the engine block and was able to assemble everything mostly by myself. This took hours of just learning everything. What parts to use, which type of metal is best for pistons in my application. I learned so much that I did a presentation on a turbo combustion engine in school.
Programming example, I heard and I even read what dependency injection is. However, I would not be able to really explain it to someone else at that point. Then, I started to do more testing on my code, and it became clear some things were extremely hard to test without DI.
CI/CD, same thing I knew about it but I was working as a solo dev and on non-business-critical software. Then, as I started working on bigger projects which ran a business I quickly realized I needed a CI/CD pipeline to track releases and changes. I kept running into headaches without it. Now, I could explain in depth, provide examples of how it really can benefit a business especially when application breaking bugs are discovered.
For me confidence comes from REALLY knowing things and understanding the "WHY" I am doing this thing. Plus, sometimes someone may ask you a question you don't know an answer to, it is okay to say you are unfamiliar with something. Then, go look up after. This is how you find gaps in your knowledge.
In the end you can't know everything. To have a good life one must learn until they die as things change.
I was much the same, until I realized just how many people make broad claims like they are objectively right, especially on HN. It's not an insult, but more of presenting opinions as fact ("microservices are bad", "java sucks", "the best way to do x is y").
So, it made me feel better to just speak to what I know as if it's the truth, just like other folks do. I don't wonder if I'm giving a good answer, I speak as if I'm giving the only answer. Not to be a knowitall, but it helps with confidence when speaking if I can maintain that mindset.
I open...
- ...a text editor (VS Code)
- ...with Dendron (Outfitted with custom kb schemas and snippets, etc)
- ...a browser (Chrome, Firefox, etc.)
- ...a new diagram (Drawio only)
1. Open VS Code (Dendron extension starts)
2. CTRL+l and type `crypto.x.509`. This creates a `.md` file in my knowledge base
a. Because I have a "Crypto" schema setup in Dendron, upon creating the new document under `crypto.`, a markdown template is applied with the following headings:
i. ### Acronyms / Definitions
ii. ### Questions
iii.### Resources
iv. ### Footnotes
a. Points to the [ITU-T website](https://www.itu.int/t/aap/recdetails/8529)
5. In a new `crypto.x.509.drawio` file, draw box "ITU-T" on the diagram
6. Copy the spec URL to my `crypto.x.509.md` file under the `### Resources` heading (add some alt text)
7. Read the PDF spec VERY CAREFULLY; creating a box on the diagram _for each noun_ I come across.
a. Once boxes appear to either work together in a process or are part of the same concept, I contain them in a larger "parent" box
b. This is good for determining hierarchy and peer relationships
- Its fairly quit to get "a sheet of music" in front of all concerned parties (if you're working on a team)
- I like seeing the diagram and *easily* manipulate thoughts (boxes) and move them into combinations
- Writing everything in Markdown basically creates a website of your notes
- Using Dendron centralizes your knowledge base
Even for areas that I have a high degree of knowledge in, I find that practicing how I am going to explain it to someone else makes things go much smoother. The only reason I can explain things 'offhand' and have it go well, is if I have done it so many times before that I don't need to practice it.
to be good at teaching/explaining, take a communication course, practice, record yourself.
sometimes part of explanation is preparation, when you sometimes see people give good speech, it's all about the prep work you never saw.