From Classroom to Cloud: My Journey from Learning Facilitator to Full-Stack Engineer | Timothy Nlenjibi
CareerFeatured
From Classroom to Cloud: My Journey from Learning Facilitator to Full-Stack Engineer
August 13, 20267 min read
Share:
How I went from teaching children to read in Ghana to building Spring Boot APIs and deploying on AWS — and what every non-traditional tech career teaches you about engineering.
From Classroom to Cloud: An Unlikely Journey into Software Engineering
If you told me five years ago that I would be building Spring Boot APIs and deploying microservices on AWS ECS, I would have laughed. My path into software engineering did not start with a computer science degree or a coding bootcamp. It started in a classroom in northern Ghana, teaching children how to read.
The Early Chapters: Learning Facilitator at Plan International Ghana
My first professional role was as a Learning Facilitator at Plan International Ghana, one of the world's largest child-centred humanitarian organizations. My job was to teach reading and writing to children in underserved communities — breaking complex ideas into simple, digestible pieces, maintaining patience when a concept didn't land, and celebrating small wins that meant the world to a child.
I didn't know it at the time, but I was developing skills that would become invaluable in software engineering:
Explaining complexity simply — the same skill that makes a great code reviewer or technical writer
Adapting to different learning styles — the same empathy that makes a great API designer who thinks about the developer experience
Keeping a group focused on a goal — the same discipline that makes a great engineering lead
Teaching reading is harder than it looks. You are not just delivering information — you are building mental models from scratch. That experience shaped how I write documentation, design APIs, and mentor junior developers today.
Running a Business: Cafe Manager at Alfa King Richards
From the classroom, I moved into cafe management at Alfa King Richards Ent., where I discovered what it truly means to juggle competing priorities. Managing inventory, scheduling staff, handling customer complaints, tracking daily revenue — every day was a mini product sprint: identify problems, implement solutions, measure results, and iterate.
The business analysis instincts I developed here now shape how I approach software architecture. Before I write a single line of code, I ask the same questions I asked as a cafe manager:
When I eventually studied software design patterns, concepts like the Command Pattern and the Observer Pattern felt familiar — I had been implementing human versions of them in a coffee shop.
Systems Thinking: School Administrator at Richard Excellence Academy
Next came a role as School Administrator at Richard Excellence Academy, where I managed student records, staff schedules, examinations timetables, and parent communications. I was essentially maintaining a relational data management system — except it ran on spreadsheets and paper instead of a database.
When I eventually learned about relational databases, I understood foreign keys and joins immediately because I had lived the problem they solve. Student records linked to class records linked to teacher records — I had been managing those relationships manually for years, resolving the same consistency problems that database transactions exist to prevent.
That experience is why I take database schema design seriously. A bad schema in production is the same as a messy student records filing system — you pay the cost of that decision every single day.
Remote Work and Digital Workflows: Virtual Assistant
Working as a Virtual Assistant sharpened my remote communication and digital workflow skills. Managing email threads, coordinating calendars across time zones, preparing legal documents, organizing cloud storage — this taught me the value of clear documentation, version control, and asynchronous communication.
These are the exact skills that make a great software developer on a distributed team. When I joined AmaliTech and started working in a professional engineering environment, remote collaboration felt natural because I had been doing it for years — just without the code.
Discovering Code: CK Tedam University and Freelance Work
My formal entry into technology was through CK Tedam University of Technology and Applied Sciences, where I studied Information Technology. I started with Visual Basic and C++, learned Management Information Systems, and eventually picked up PHP for web projects.
The fundamentals clicked fast — probably because I already understood the business problems that software was meant to solve. When my lecturer explained CRUD operations, I thought: this is just what I did with student records, but automated.
During my freelance years as a Web Developer, I built websites for small businesses using PHP, then progressively moved toward React.js and Django as I discovered how much more productive modern frameworks made me. Each client project taught me something about requirements gathering, scope management, and delivering software that real people would actually use.
AmaliTech: Where Everything Converged
Everything converged when I joined AmaliTech as an NSP Backend Engineer. Suddenly I was working with Spring Boot, JDBC, and JavaFX in a professional engineering environment alongside talented engineers.
Code reviews, architecture discussions, sprint planning, deployment pipelines — all of it felt familiar because I had been operating in complex systems my entire career. I just had not been writing code while doing it.
At AmaliTech, I also dove deep into Next.js, MongoDB, AWS, Docker, and DevOps practices. The blend of business awareness and technical depth led me to build projects like Work Log Pro (a SaaS time tracker), an ECS CI/CD pipeline with 9 CloudFormation stacks, and a serverless task manager on AWS Lambda.
The software industry often fetishizes the straight line: CS degree, internship, FAANG. But the engineers I most respect are the ones who bring something extra — a perspective shaped by real problems, real people, and real constraints that exist outside a terminal window.
My background gives me:
Empathy for users — because I have been a frustrated user of badly designed systems (paper-based school admin is a masterclass in UX failure).
Business context — because I understand that software exists to serve a business goal, not to demonstrate technical cleverness.
Communication skills — because I spent years translating complex ideas for children, parents, clients, and customers before I ever had to translate them for stakeholders.
Resilience — because building a career across five very different domains before landing in engineering teaches you that learning is learnable.
For Anyone on a Non-Traditional Path
If you are reading this from a non-traditional background — a teacher, a nurse, a small business owner, a virtual assistant — know this: your experience is not a detour. It is your competitive advantage.
The code is learnable. The perspective you bring from outside tech? That is rare. Cultivate it.
Every system I design today is better because I once managed a classroom, ran a cafe, and organized a school. The cloud is just another complex system that needs to work for real people. I have been preparing for this my whole life.