My journey into frontend engineering and what I wish I knew earlier
Introduction
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 building for actual users.
Lessons from the Trenches
– The JavaScript Rabbit Hole
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. But over time, through practice and experimentation, it all started to click. Looking back now, understanding asynchronous behavior 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. But I've always been drawn to difficult challenges, so I sat down one day and made a decision 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/JavaScript without a component-based structure is always a struggle. I experienced this firsthand when building early web interfaces, repetitive designs across pages weren't easily reusable, forcing me to copy and duplicate pieces of HTML/CSS code everywhere, leading 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 building separate, monolithic pages for loan requests, approvals, and agreements, I developed reusable components like loan status indicators, approval timelines, composable layouts and detail viewers that 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. This development pattern made it easier for other loan products like Overdrafts to quickly prototype and go live in a shorter time.
– Knowing your crafts
Becoming a software engineer goes beyond just typing functions and building beautiful landing pages or web applications. It meant going in depth into how the tools work, how the browser worked, how the JavaScript engines work, software engineering principles and its application to what I’m building, how browsers compile my code, how the DOM works, and how all the frameworks I use actually work and detect state changes. I read a couple of books and blogs, like crafting interpreters, computer algorithms, V8 engine, etc. This significantly improved how I thought about implementing features and fixes.
– Testing: From Painful to Powerful
Over the years, I’ve learnt that even the task you spent a lot of time working on could have defects, and a way to quickly catch defects is through testing, which could be unit tests, regression tests, integration, end-to-end or visual regression testing.
As a frontend engineer, I learnt that the brain builds a sense of familiarity between a Figma design and your implementation. This greatly affects my sense of noticing some tiny details, because the brain fills in for it. I combat this by practising visual regression tests; I put designs right beside implementation as much as possible. I also take the design implementation component by component from the smallest up. By doing this, I’m building my attention to detail, soaking in more as I do more complex implementations, and once I bring all the components together, it all looks 100% like the Figma design.
I’ve also preferred test-driven development. It provides and lays the foundation for a better implementation of features, ensuring that I write proper test cases and not that tests will be an afterthought or written to pass. When implementing features, if you write a test first, you’re writing it when you’ve not been bothered with implementation, or tired from the grueling work of implementation, it ensures you have the right frame of mind to write good test cases for the features.
– 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 just how the webpage was built.
But here is the thing. You cannot optimize what you cannot measure. If you do not know how long your page takes to load or how big your bundle sizes are, then you are basically flying blind. You need proper tools to guide your performance decisions.
I use a combination of tools to track and measure performance. Lighthouse is great for quick audits. Web Vitals helps with real-world metrics. The Webpack Bundle Analyzer gives insights into what is bloating your build. I also use extensions like import cost to check the size of libraries I am adding, and I rely on the Performance API to dive deeper into how the browser is actually handling everything.
There was a time when performance became a real challenge for me. I built a web app that made a lot of 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 what was wrong or doing endless back-and-forth testing on specific devices.
I took a step back and ran some performance profiling. I realized 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 engineer 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 engineering sessions, deep dives, 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 realize 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, engineering meetings, and deep-dive sessions. I also volunteered to join the engineering meeting committee at Moniepoint. These meetings are a platform for exploring new technologies, reviewing research papers, and learning about products other teams are building. I took 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. An important highlight of the journey was hosting our CTO, Felix Ike, as a guest speaker. It was a surreal moment. Just two years prior, I could barely speak in meetings of ten people, and now I was facilitating a session with over 250+ engineers in attendance.
Feedback at Moniepoint is clear and constructive. Over the past year, I’ve received encouraging notes from my manager, recognizing how much more vocal and engaged I’ve become. I’ve been commended for simplifying complex topics and helping keep the team aligned.
Now, I see communication as an integral part of engineering. 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. I’ve grown into a more collaborative, confident engineer, and that has made all the difference.
– Mentorship and Reviews
Over the past years, I’ve grown significantly in both giving and receiving code reviews. My approach to writing code has evolved. I now focus on clarity, scalability, and elegance. This shift didn’t happen overnight. It came through countless peer reviews, self-reflection, and thoughtful feedback from the Web Architect on my team.
One habit I’ve developed is revisiting my older code, sometimes from months or even years back and refactoring it with fresh eyes. It’s a practice that helps me measure my growth and challenge myself to find cleaner, more efficient solutions.
Giving reviews is something I used to shy away from. I often doubted whether I had anything valuable to contribute. But I’ve come to realize that reviewing code is a good way to deepen your understanding. When I look at someone else’s implementation, I try to understand not just what they wrote, but why they wrote it that way. This mindset has sharpened my own thought process and taught me to be more intentional in my suggestions.
Providing clear, constructive feedback has become part of my everyday workflow. It has improved my communication skills, my confidence as an engineer, and my ability to advocate for quality standards across the team. Reviewing code isn't just about finding bugs; it's about building a shared understanding of what good engineering looks like.