Edited by Oluwaseun Bose Rufus
Table of Contents
I’m a software engineer who builds systems that solve real problems. At Moniepoint, I’ve contributed to platforms serving millions of users, shipping business loan flows, event tracking services, and workflow automation that simplifies back-office operations.
My focus is on Angular, React, and component architecture that scales across teams. What sets my approach apart is pairing technical depth with user-centred thinking, so every feature genuinely improves the experience for business owners, field officers, or internal teams.
I’ve also grown from someone who rarely spoke up into someone who leads cross-team collaboration, writes documentation other teams adapt, and takes ownership of complex challenges that span multiple products.
Into Frontend Engineering
My path into frontend engineering began in 2017 with a simple discovery: HTML Code Play, an app that allowed me to write HTML and see it render instantly on my phone. That magical moment of code becoming visual sparked the curiosity that drives my work today.
I started with the sample template, then gradually explored more HTML tags, fascinated by how a few lines of code could create something tangible on the screen. It felt like having a superpower, the ability to transform ideas into interactive experiences with nothing but text and logic. Eventually, I wanted to build something real with these new skills, so I created a simple Computer-Based Test (CBT) app for students to take mock exams. I shared it with a few friends and, for the first time, felt the thrill of creating for actual users.
Lessons from the Trenches
The JavaScript Rabbit Hole
One of the earliest challenges I faced was understanding why JavaScript was necessary in the first place. I couldn’t wrap my head around why people used libraries like jQuery, or why abstraction was even important. It felt easier to write everything in a single function and reuse it everywhere. I also questioned the need for frontend frameworks like React or Angular. If I could manipulate the DOM directly with plain JavaScript, why bother learning something else?
Another area I struggled with was asynchronous programming. Concepts like callbacks, promises, and the event loop were confusing at first. However, through practice and experimentation, it all started to click. Looking back now, understanding asynchronous behaviour is an important milestone in my frontend journey.
CSS Struggles
CSS was another major hurdle for me. Flexbox and Grid layouts felt especially overwhelming, and at some point, I found myself avoiding layout-related tasks entirely. However, I’ve always been drawn to difficult challenges, so I sat down one day and decided to figure it out. I watched tutorials, read documentation, and built small layouts until the concepts became second nature. Since then, working with CSS has become a joy, and I now approach every layout in terms of flex containers, grid systems, columns, and rows.
Levelling Up: From Developer to Engineer
Thinking in Components
Using HTML, CSS, and JavaScript without a component-based structure is always a struggle. I experienced this firsthand when creating early web interfaces. Repetitive designs across pages weren’t easily reusable, forcing me to copy and duplicate pieces of code everywhere, which led to codebases that became bloated, heavy, and slow.
Learning React and getting introduced to components made me rethink my entire design approach. At Moniepoint, this shift became crucial when working on our loan product interfaces. Instead of constructing separate, monolithic pages for loan requests, approvals, and agreements, I developed reusable components:
-
Loan status indicators
-
Approval timelines
-
Composable layouts
-
Detail viewers
These could be composed across different flows. This component-first approach not only reduced development time but ensured consistency across our financial products, making it easier for users to navigate between different loan features with familiar interface patterns. As a result, other loan products like Overdrafts could quickly prototype and go live in a shorter time.
Knowing Your Craft
Becoming a software engineer goes beyond typing functions and creating beautiful landing pages or web applications. It meant going into how the tools actually work. I studied the browser, JavaScript engines, and the DOM. I also explored how browsers compile code and how frameworks detect state changes. Alongside this, I learned core software engineering principles and how to apply them to what I build.
To deepen my understanding, I read books and blogs on topics like crafting interpreters, computer algorithms, and the V8 engine. As a result, this significantly improved how I think about shipping features and fixes.
Testing: From Painful to Powerful
Over the years, I’ve learnt that even the task you spent a lot of time on can still have defects. A reliable way to catch them is through testing. This includes:
-
Unit tests
-
Integration tests
-
Regression tests
-
End-to-end tests
-
Visual regression tests
As a frontend engineer, I’ve noticed that the brain creates a sense of familiarity between a Figma design and your implementation. This greatly affects my sense of noticing tiny details, because the brain fills in for it. To combat this, I practice visual regression tests and put designs right beside the implementation as much as possible. I also tackle the design component by component, from the smallest up. By doing this, I’m training my attention to detail, absorbing more as I take on more complex work. Once I bring all the components together, the final result matches the Figma design.
I’ve also come to prefer test-driven development. It lays the foundation for cleaner features and ensures tests aren’t an afterthought or written just to pass. Writing tests first, before you’re deep in implementation or worn out by it, puts you in the right frame of mind to cover the feature properly.
Performance Matters
Practice really does make perfect. As I learned more about browsers and JavaScript engines, I came to understand a painful but important truth. Browsers can be very memory-intensive, and web pages can get really slow. Sometimes the issue is with the Chrome engine, sometimes it’s the browser itself, and other times it’s simply how the webpage was constructed.
However, here’s the thing: you cannot optimise what you cannot measure. If you don’t know how long your page takes to load or how big your bundle sizes are, then you’re basically flying blind. You need proper tools to guide your performance decisions.
I use a combination of tools to track and measure performance:
-
Lighthouse for quick audits
-
Web Vitals for real-world metrics
-
Webpack Bundle Analyser for insights into what’s bloating your build
-
ImportCost extension to check the size of libraries I’m adding
-
Performance API to examine how the browser actually handles everything
There was a time when performance became a real challenge for me. I shipped a web app that made many fetch requests and cached the results in the user’s browser. On the surface, it looked fine, but once people started using it more, the problems became clear. It was slow, it lagged on some devices, and it suffered from concurrency issues. Without proper tooling, I would have kept guessing or doing endless back-and-forth testing on specific devices.
Therefore, I took a step back and ran some performance profiling. I realised the bottleneck was how and when I was caching the data. So I redesigned the flow. I introduced a locking mechanism to prevent multiple fetches from running at once, used asynchronous fetch patterns to improve responsiveness, implemented queues to better manage load, and added a periodic caching strategy instead of caching everything immediately.
That single experience taught me the value of measuring first, diagnosing properly, and then fixing with intention. Performance is not about tweaking random things until something works. It is about understanding how your code behaves, how the browser reacts, and how your choices affect real users.
Beyond Code: The Soft Side of Engineering
Communicating with Designers and PMs
I grew up as an introvert. I was the kind of person who quietly got tasks done, unblocked teammates when needed, and kept to myself. While I communicated well within my immediate team, I rarely engaged beyond that. Even though I had ideas and insights, I often struggled to speak up during sessions, technical reviews, or sprint planning meetings.
That changed dramatically.
A turning point for me was during my first quarterly review at Moniepoint. My manager at the time wrote a simple but powerful comment: “Feranmi should speak more. He has a lot to contribute.” I took that feedback seriously. It made me realise that doing good work wasn’t enough on its own. If I wanted to grow and truly make an impact, I needed to start contributing more vocally and visibly.
So I began to challenge myself. I started speaking at conferences, developer events, team meetings, and technical reviews. I also volunteered to join the engineering meeting committee at Moniepoint. These sessions are a platform for exploring new technologies, reviewing research papers, and learning about products other teams are constructing. Since joining, I’ve taken on the responsibility of coordinating the sessions, working with teams and speakers, and hosting the events.
When I first joined, these sessions had about 70 attendees. Today, we’ve seen over 200 attendees on some occasions. One highlight of the journey was hosting our CTO, Felix Ike, as a guest speaker. It was a surreal moment. Just two years earlier, I could barely speak in meetings of ten people, and now I was facilitating a session with over 200 engineers in attendance.
Feedback at Moniepoint is clear and constructive. Over the past year, I’ve received encouraging notes from my manager, recognising how much more vocal and engaged I’ve become. I’ve also been commended for simplifying complex topics and helping keep the team aligned.
Now, I see communication as an integral part of my craft. Sharing ideas, asking questions, unmuting your mic, or even turning on your camera during meetings are small but meaningful ways to show up and be present for your team. As a result, I’ve grown into a more collaborative, confident engineer, and that has made all the difference.
