From Curious to Confident

Author

Affiliation

Mbiarrambang Alain

PavveWay Group

Learning Loud: A Practical Playbook to Build a Cloud Career

Speaker: Mbiarrambang Alain (Founder, PaveWay Group)
Event: BuildHers Women’s Month Picnic — From Curious to Confident: Learning Loud, Building Proud
Length: ~35–40 minutes (including short Q&A)

[Slide 1 — Title slide: “From Curious to Confident — Learning Loud”]

Hello everyone — good afternoon! Merci beaucoup for that warm welcome. I’m Mbiarrambang, founder of PaveWay Group and a DevOps & Cloud Engineer based in Buea. First — big thanks to the BuildHers team for inviting me. I’m really excited to be here with so many brilliant women and allies who are ready to learn out loud and build proud.

Today I want to share something very practical: how to turn curiosity into confidence using one simple, high-return habit — learning in public. I’ll give you a playbook you can start using tonight: specific micro-actions, templates, a 30-day plan, and a few real stories from my work building fintech systems, teaching students, and organizing hackathons.

My aim is simple: after this talk you should have a clear set of steps to start showing your work in public, get useful feedback, and build a portfolio that opens real opportunities in the cloud.

[Slide 2 — Quick opening story: “The Small Project That Changed Everything”]

I want to open with a short story.

A few years ago, when PaveWay was only an idea and I was still shipping side projects, I built a tiny proof-of-concept: a simple mobile demo that showed how a user could top up a mobile wallet from another country. It took me one weekend. I wrote a short README, posted a 3-minute video of the app flow, and shared it in on Google Play Store.

Within a week I got three messages: one from a student asking for mentorship, another from a developer asking if they could contribute, and — unexpectedly — a product manager from a US company who wanted to talk collaboration. That one conversation turned into the pilot that helped us iterate the early product.

Why did that one tiny project matter? Not because it was perfect — it wasn’t. It mattered because it was visible, it invited feedback, and it gave strangers a way to assess my skills quickly.

That’s the power of learning loud.

[Slide 3 — What “Learning in Public” Actually Means]

When I say “learning in public,” I don’t mean oversharing your every thought or pretending to be an expert. I mean:

Publishing small, complete artifacts — a short post, a README, a demo video.
Making progress visible and repeatable so others can try, test, and give focused feedback.
Creating signals of work: code, docs, walkthroughs, small projects.
Doing this consistently, not occasionally.

This habit flips the usual private study loop into a public feedback loop — and feedback is what builds confidence.

[Slide 4 — The Learning-Loud Toolbox (live demo cues)]

Let’s talk about tools and tactics you can use starting right now. I’ll go through each and say exactly what to publish and why.

1) The 10–20 minute write-up (public journal):

What to post: A short thread or LinkedIn post describing one problem you solved or one thing you tried.
Why: It’s low friction and shows reasoning. Example opening: “Today I tried provisioning a VPC with Infrastructure-as-Code. I hit X; here’s how I fixed it…”
Action: Do this twice a week. Keep it short and factual.

2) Mini project + README-as-portfolio:

What to post: A small cloud project (deploy a static site to S3 + CloudFront, or a simple Lambda function). Include a clear README with: What it does, why it matters, how to run it.
Why: Recruiters, mentors, and collaborators read READMEs. A good README beats a long resume line.

3) Short demo video (2–5 minutes):

What to post: Record your screen and voice walking through the feature or infra you built. Host on YouTube as “unlisted” or share the link.
Why: Videos communicate context quickly — you show trade-offs, not just code.

4) Reproducible lab or notebook:

What to post: A step-by-step guide that someone else can follow (CloudFormation/Terraform sample, or a step-by-step tutorial).
Why: It positions you as someone who can teach — teaching is community currency.

5) Micro-contributions to open source:

What to post: Small PRs that fix typos, add tests, or improve docs. Document the PR in a public thread: “I contributed X to Y — here’s what I learned.”
Why: Contributions show collaboration and avoid the ‘portfolio gap’ problem.

6) Mini talks / lightning demos:

What to post: 5–10 minute talks recorded on your phone. Post as clips or build a playlist.
Why: Speaking ability multiplies visibility quickly.

[Slide 5 — Building Confidence via Feedback Loops]

Visibility alone isn’t enough. You need feedback — and you need to structure it so it grows your confidence.

Here’s a simple loop I use:

Scope small experiments: choose one small deliverable (README + demo).
Publish early: don’t wait for perfection. Use a draft label if needed.
Ask one clear question: e.g., “Does this README explain how to run the demo in 3 steps?”
Collect feedback from 3 sources: one peer, one online community, one mentor.
Iterate quickly and post the update with a short note: “Update: I changed X based on the feedback — here’s why.”

This loop reduces fear — you remove the all-or-nothing pressure. Tiny wins stack into visible progress and confidence.

[Slide 6 — Practical Roadmap: 30-Day “Learn-in-Public” Plan]

Okay — here’s an exact 30-day plan you can copy and paste. I give this to students and junior engineers; it moves them from private tinkering to a visible portfolio.

Goal: Build and publish a cloud mini-project and a public learning thread.

Week 0 (Preparation, 1–2 days):

Pick a small project scope (example: “deploy a serverless function that resizes images on upload using AWS Lambda”).
Create a new GitHub repo and an initial README with project goals.

Week 1 (Build & document — 7 days):

Day 1–3: Build the core feature. Keep commits small.
Day 4: Write a short README draft (3 sections: What, How to run, TODO).
Day 5: Record a 2–3 minute demo video showing the feature.
Day 6–7: Publish the repo, the README, and the demo link. Share a 3-tweet thread or LinkedIn post describing the problem, your approach, and a link.

Week 2 (Collect feedback & iterate — 7 days):

Share the project in one targeted Slack/Discord (Dev.to, Hashnode, local group). Ask one question in the post.
Make one small improvement based on feedback and push a new commit with a short changelog. Post an update.

Week 3 (Add a reproducible lab & outreach — 7 days):

Convert one part of your README into a step-by-step tutorial or a short blog post.
Reach out to one mentor or peer and ask for a 15-minute review call. Record notes and publish a short “What I learned” post.

Week 4 (Amplify + reflect — 7 days):

Make a short clip highlighting the project and publish it.
Bundle the project into a “case study” README: Problem → Approach → Results → Next Steps.
Write a final 500-word reflection: what worked, what you’d do differently, and next steps. Share it publicly.

If you repeat this plan for three months, you’ll have 3–5 polished portfolio pieces and many micro-posts showing growth.

[Slide 7 — Readme Template (spoken reading of template)]

When I say README matters, I mean it. Here’s a template — read it aloud when you create a new repo:

Project title Short one-line description.

Why I built this Problem statement and who benefits.

What it does Bullet list of features.

How to run (3 steps)

Clone the repo
Set up credentials / run npm install / terraform init
Run make demo (or whatever the simplest command is)

Architecture (2–3 lines) High level infra pattern (e.g., “S3 upload → Lambda resize → S3 public”).

What I learned Three short lessons.

Next steps What you would add or improve.

Contact / where to find me LinkedIn / Twitter / email

If your README can be read and run in five minutes by someone else, you’ve already won.

[Slide 8 — Handling Imposter Feelings & Mental Health]

We can’t talk about learning loud without touching on mental health and imposter feelings — especially for women in tech.

Quick practical tips:

Set small goals — small deliverables that you can finish. Celebrate them publicly.
Schedule recovery time — learning is a marathon. Make sure to rest after big pushes.
Use “draft” language — it’s okay to signal “work in progress.” This invites collaboration rather than perfection.
Find a safe feedback buddy — someone who will be honest and constructive. Rotate feedback buddies so you get different perspectives.

Remember: confidence grows when you have repeated, safe opportunities to try, fail, and recover.

[Slide 9 — How to Use Community (mentors, meetups, hackathons)]

Community is powerful. Here’s how to leverage it:

Mentor ask: when you reach out, ask for something small — a 15-minute walkthrough is better than “Can you mentor me?”
Meetups: show up with a one-line description of your project. People remember simple hooks.
Hackathons: treat them as product discovery sessions, not competitions — you’re there to ship a demo and learn public feedback.
Volunteer to speak or demo locally: a 5-minute lightning talk is an attention multiplier.

Community is not just about getting jobs — it’s also about building a feedback loop that accelerates learning.

[Slide 10 — Sample Social Post Templates (read two examples)]

Here are two short templates you can use:

Template A — Launch post (Twitter / LinkedIn) “Just built a small demo that [what it does]. Took me 2 days. I learned X, Y, Z. Repo: [link]. If you have 2 mins, could you try it and tell me if the README is clear?”

Template B — Reflection post “Update: After feedback I changed X → now it does Y. Biggest lesson: [one-sentence]. If you’re building something similar, DM me — I’d love to swap notes.”

Use these as copy-paste starters so you don’t overthink the words.

[Slide 11 — Practical Examples from My Work]

I promised concrete examples — here are two quick ones from my work at PaveWay and in teaching.

Example 1 — Small fintech demo: We had to show an investor how cross-border mobile top-ups might work. Instead of a long slide deck, I built a tiny demo and a 4-minute walkthrough video. That demo started conversations with two potential partners because it made the concept tangible.

Example 2 — Teaching OOP with C++: When I teach, I ask students to publish a README + small repo for each assignment, and then present their code in a 3-minute demo. Students who did this consistently found internships faster — because employers could quickly validate ability through small, public artifacts.

[Slide 12 — Common Objections & Short Responses]

I hear a few common objections. Quick responses:

“But I’m not ready.” — Nobody starts ready. Start with a draft label. Perfectionism stalls progress.

“People will copy my idea.” — If an idea is easily copied, it’s not your long-term advantage. Your advantage is execution and iteration.

“I don’t have time.” — You can do 20 minutes, 3 times a week. Small, consistent beats big and rare.

“I’m afraid of negative feedback.” — Structure feedback requests. Ask for specific things: clarity, security, performance. That focuses replies and reduces noise.

[Slide 13 — Quick Checklist to Start Tonight]

If you remember only one thing, let it be this checklist:

Pick one tiny project (scope < 7 days).
Create a GitHub repo with a one-paragraph README.
Record a 2-minute demo or write a 200-word post.
Share it in one community and ask one specific question.
Repeat.

That’s it. Small, visible steps win.

[Slide 14 — Call to Action & Resources]

If you want to take this further, here’s what you can do after this talk:

Join a local or online study group and commit to one demo a month.
Take a small cloud certification path (e.g., cloud practitioner) but pair study with public artifacts.
Volunteer to give a 5-minute lightning talk at your next meetup — even if it’s only a demo of a README.

I’ll also share templates and the 30-day checklist after the session — look out for a follow-up link.

[Slide 15 — Closing story + thank you]

I’ll close with a short story. One of my students was terrified to post anything online — she thought her projects were too small. I encouraged her to publish one README and a 90-second demo. Two weeks later she got a message from a recruiter who had seen the demo and wanted to schedule a call. Small visibility created a big opportunity.

You don’t need permission to publish. You just need a problem you care about, a small deliverable, and the courage to be visible.

Thank you — that’s the practical playbook. I hope you feel ready to be loud and proud about your learning.

[Slide 16 — Q&A]

I have a few minutes for questions. If you have a question about the roadmap, templates, or a specific cloud scenario, please ask.

Question 1 (audience): “I’m a student — which small project would you recommend to get started in cloud?” Answer: Start with something concrete and useful: deploy a personal website to S3 + CloudFront, or build a serverless function that emails you when a form is submitted. Both are small, teach infra and deployment, and let you show results in a demo.

Question 2 (audience): “How do I get feedback without feeling judged?” Answer: Ask for targeted feedback. Example: “Can you try the setup steps and tell me if any step fails?” That directs people to give helpful, actionable feedback instead of vague critiques. Also start with trusted peers for the first round.

Question 3 (audience): “I want to move from dev to cloud engineer — what content shows that transition?” Answer: Build one project that demonstrates cloud-native thinking — use infra-as-code, show observability (logs/metrics), and document trade-offs in the README. Mention specific cloud services you used and why in the “What I learned” section.

Question 4 (audience): “How do I balance learning public with security concerns?” Answer: Don’t post secrets, keys, or proprietary code. Use sample data, anonymize anything sensitive, and when in doubt, publish architecture and README rather than raw credentials. Teach with sanitized examples.

[Slide 17 — Final invitation & contact]

If you’d like templates or the 30-day plan as a downloadable checklist, or to review a README or demo, please come find me after the session or DM me on LinkedIn/Twitter. I’m happy to review one repo or one README for free — quick feedback in 15 minutes.

Thank you so much for your time. Keep learning loud, keep building proud, and I can’t wait to see what you publish next.