DEV Community: Akum Blaise Acha

THE CAREER-READY ENGINEER MOVEMENT BEGINS

Akum Blaise Acha — Sun, 05 Oct 2025 15:57:52 +0000

A few years ago, I met a young developer who had learned Python, JavaScript, AND React.

Yet every time someone asked, “What can you build?” — he froze.
Not because he lacked knowledge.

But because he lacked proof.
That’s when I realized something:

Most developers in Cameroon (and Africa as a whole) don’t have a skills problem — they have a project problem.

They’ve watched tutorials, collected certificates, even finished courses…
But when it's time to show what they’ve actually built, everything disappears into thin air.

Not because they’re lazy — but because nobody ever showed them what real engineering projects look like.

Projects that solve actual African problems.

Not Todo lists.
Not calculator clones.
Not static dashboards with fake data.

I’m talking about:

✅ A system that helps shop owners auto-restock inventory
✅ A Njangi savings tracker
✅ A customer feedback & sentiment tool for SMEs
✅ A delivery ETA estimator for riders navigating Douala traffic

These are the kinds of builds that change how you see yourself.

Not as “someone learning to code,”
but as “an engineer who solves problems.”

I’ve turned that realization into a structured journey.

It’s called The Career-Ready Engineer Challenge — a 90-day framework to help you build 15 real engineering systems, one at a time — with guidance, clarity and accountability.

If this message hit you, then maybe this challenge is yours.

👉 Learn more or join here: https://excelintech.com/b/4rwHN

The One Skill Every Engineer Needs That Isn’t Taught in Bootcamps

Akum Blaise Acha — Sun, 17 Aug 2025 14:33:22 +0000

When I was starting out, I thought being “good” meant writing the cleanest code.

I spent hours perfecting syntax, naming variables, and refactoring functions — convinced that’s what would get me promoted.

Then one day, in a code review, my senior looked at me and said:

“The code looks fine. But walk me through why you did it this way.”

I froze.

I could talk about what I did. But not why. And in that silence, I realized something:
The real skill isn’t just building. It’s explaining your thinking.

Bootcamps Teach Code. Real Life Teaches Communication.

In bootcamps, you ship projects that “work.”
In jobs, you ship projects that must be understood, maintained, and defended.

That’s where communication makes the difference.

Can you explain to a product manager why you chose approach A instead of B?

Can you describe to a teammate how your code flows — without them opening the editor?

Can you justify your design decisions in simple, non-technical language?

If the answer is no, you’ll always feel “junior,” no matter how many languages you know.

The Interview Wake-Up Call

In one DevOps interview, I was asked a simple question:

“Explain how your last CI/CD pipeline worked.”

I thought showing them YAML would be enough. It wasn’t. They wanted me to tell a story.

What problem the pipeline solved

The steps it took

Why I chose that tool

How it reduced errors or saved time

That’s when I understood: the best engineers don’t just build solutions — they translate them into stories everyone else can understand.

Why This Matters

Influence: Senior engineers get promoted because they can explain decisions to stakeholders, not just peers.

Collaboration: Teams move faster when ideas are clear and decisions aren’t hidden in one person’s head.

Trust: Interviewers and managers trust you more when you can break down complex work simply.

How to Build This Skill

You don’t need a communication class. You need practice.

This week, try this:

Take one piece of work you’ve done (a project, script, or pipeline).

Write a short “explainer” for it.

Problem it solved

Tools you used

Why you chose them

One lesson you learned

Share it with a friend, colleague, or even on LinkedIn.

You’ll be shocked how much clearer your own thinking becomes once you write it down.

Final Thoughts

Code gets you hired.
Communication gets you promoted.

Master both — and you stop being “just another developer.”

The #1 Skill That Separates Average Engineers from Top Engineers

Akum Blaise Acha — Sun, 20 Jul 2025 19:57:02 +0000

Most software engineers obsess over tools, languages, and frameworks.

But the ones who grow the fastest?
They master one thing that changes everything:

Thinking in systems.

→ Anyone can write code that works.
→ Top engineers write code that fits.
Fits into the business.
Fits into the architecture.
Fits into the team.

They ask:
• How does this change affect upstream and downstream services?
• How will this scale with more users or data?
• Where can failure occur, and how will we handle it?

It’s no longer about being the "smartest coder".
It’s about being the most strategic.

If you want to move from “good engineer” to “impactful engineer”, stop thinking in features.
Start thinking in systems.

Understanding Two-Factor Authentication: What Every Software Engineer Should Know

Akum Blaise Acha — Sun, 27 Apr 2025 10:48:18 +0000

We've all used 2FA. But as a software engineer, do you know how it works under the hood?

Like we all know, two-factor authentication is a security method that requires two forms of identity before giving someone access to an account.

The first factor is what you know. That’s your password.

The second factor is either what you have or what you are. What you have can be your phone or a security key. What you are can be your fingerprint or your face.

Here’s the flow:

You enter your email or username and password, if the details are correct, the second layer kicks in. That could be an OTP sent to your phone, a code from an authenticator app, or a biometric check.

Once you complete the second step, access is granted. If not, you’re blocked.

As a dev, this is how you can implement 2FA:

Start by storing a shared secret between your app and the user’s authenticator app. You can use libraries.
When the user logs in successfully, generate a time-based one-time password using the shared secret and the current time.
Send a prompt to the user to enter the 2FA code.
Once they enter the code, verify it by comparing it with the one your server generates in real-time using the same secret and time.
If it matches, proceed. If not, reject access.

Avoid using SMS-based 2FA. It’s weak and vulnerable to SIM swap attacks. Go with TOTP or physical keys.

Knowing how 2FA works helps you build more secure products.

And if you're shipping anything that handles sensitive data, you shouldn't treat 2FA like an optional feature.

How I Would Learn Software Engineering If I Had to Start All Over Again in 2025

Akum Blaise Acha — Sun, 27 Apr 2025 09:08:12 +0000

Most people think learning software engineering is all about cramming programming languages and rushing through tutorials.
I used to think the same when I started.

But after several years working professionally, mentoring over 10+ engineers, and publishing 40+ articles on building real tech careers, I see things very differently now.

If I had to start all over again in 2025 — from absolute zero — here’s exactly how I would approach learning software engineering.

And no, it wouldn't begin with "Learn HTML and CSS."

It would begin with something deeper: understanding how everything actually works.

Step 1: Understand How the Internet Works (Before Writing Code)

Before touching any programming language, I would take time to really understand:

What happens when you open a website

How data moves between your browser, servers, and databases

What APIs are, and why they're important

Basics of client-server architecture

Knowing these concepts would give me a mental map to place all the coding skills I’ll eventually learn.

It’s like building a house — you don't start by painting walls. You start by understanding the foundation.

(And honestly, this kind of understanding would have saved me months of confusion early on.)

Step 2: Choose ONE Language and Stick With It

In 2025, it’s very tempting to jump between languages: JavaScript, Python, Rust, Go, PHP, TypeScript...

If I was starting again, I would pick one versatile language (like Python or JavaScript) and stick with it for at least 6–12 months.

Why?
Because mastery beats curiosity at the early stages.

Languages are just tools. The real value is in mastering problem-solving using that tool.

Step 3: Build Real Projects Early (Not Endless Tutorials)

This was a huge mistake I made early on: staying stuck in tutorial loops.

If I started again, I would build my own small projects as early as possible — even if they’re messy.

Simple ideas like:

A to-do list app
A blog API
A simple portfolio website
A weather app using a public API

Every project teaches lessons you can't learn from tutorials: debugging, designing, asking better questions, reading documentation.

Projects build confidence.
Tutorials build dependency.

Step 4: Learn Basic System Design Early

I used to think "system design" was something only senior engineers worried about.
Big mistake.

Even at the beginner level, understanding:

How databases connect to apps
How APIs are structured
How scaling affects apps
How load balancers or caching work ...can help you make smarter choices while coding.

You don’t need to become a system architect overnight.
But you should start seeing your projects like small systems, not isolated pieces of code.

Step 5: Join a Learning Community

Learning software engineering alone is one of the hardest ways to do it.

If I was starting over, I would join a community of learners and engineers immediately.

Not just for help — but for:

Accountability
Motivation when stuck
Exposure to how others think
Opportunities for real-world collaborations

(That’s part of why I created MentorAura — to make this easier for others.)

In tech, community isn’t a "nice to have."
It’s a career accelerator.

Software engineering isn’t about collecting languages.
It’s about solving real-world problems — making something useful, scalable, secure, and reliable.

If you’re just starting out (or even restarting), remember:

Build understanding before building code
Master one thing before chasing everything
Projects over tutorials
Systems over scripts
Community over isolation Every expert you admire today was once a beginner — they just didn't quit.

Stay consistent. Stay curious. Stay building.