Life At Heroshe: Behind The Scenes With Our Backend Lead, Faithfulness Alamu
Thousands of items are changing locations from busy stores in the US, UK and China to awesome people and businesses in Nigeria. That's the magic Heroshe makes happen every day! Are you curious about the incredible people behind this shipping superpower?
Welcome back to Life at Heroshe! In this episode, we step behind the scenes to meet yet another exceptional individual amongst the many who make Heroshe a remarkable workplace.
In this edition, we focus on Faithfulness Alamu, the backbone of our backend operations and, for those wondering, an eligible bachelor to boot. 😉 We will explore his pivotal role in building the infrastructure behind Heroshe’s efficient deliveries from the USA, UK, and China to Nigeria.
Let’s get started!
Can you tell us about your journey at Heroshe so far?
My journey at Heroshe started a few years ago when I stumbled upon a job ad in a community group I was part of at school. It was late at night when I first connected with my former manager, who has since moved on from the company. Some months before, I had to transition to Go from Python. Go as in Go language programming language. Although I had been building projects on the side, I had never worked full-time in Go. I applied for the job, sent in my resume and details, and the next day, I received a call from my manager. We chatted, he asked me some questions, and a few days later, I was chatting with JC, the CTO, over the phone.
Our conversation focused more on where my head was at rather than diving deep into technical details. Then, we moved on to the technical interview, which, funnily enough, was the best I had experienced at the time, the reason being that I prefer interviews to take-home tasks. I'm not a fan of take-home; I'd rather just go for the interview. I know it's an unpopular opinion, but that's just me. We discussed system designs at the interview, and I vaguely remember having a great time building something during the interview. The goal, as I’d later understand, wasn't necessarily to complete the software within the hour. I mean we had just an hour, we didn't have much time. The goal was to understand how I would approach the problem, gather requirements for it and try to solve the problem. It was really fun. I remember feeling good after the call about the interview. I really enjoyed it.
After that, we moved on to culture fit, where I met with Mr. Osi, the CEO. It was a relaxed conversation, and it felt like talking to a work friend, you know. So, that was great. The typical paperwork followed, and the next thing, I was in the thick of things, right? We were pushing changes that made some impact, writing code and stuff. The team at the time was a skeleton crew - great engineers that I learnt from. At the time, the CTO was actively involved, always writing code, which provided valuable learning opportunities. So there was a lot of good code to learn from, to read and understand. Because that was the first time I was doing Go professionally. The software moved and advanced a lot. The grind was actually beautiful. The product team has always been solid. Last year, I stepped in to lead the backend team - the ugly part - and it's been great so far.
Can you share a specific challenge you faced when you joined Heroshe and how you overcame it? What is your favorite project that you worked on? Why does this project stand out to you?
Okay, I'm going to merge these two questions together because they are talking about the same subject: Specific challenge and favorite project. So, at the time when I joined Heroshe the product was transitioning from a large monolithic codebase to microservices. That was a very interesting period. It was a period of intense change as we broke down the codebase into specific service sections based on the domains they covered. We had shipping, delivery, ordering and all that. It was a challenging time because I was jumping into a new code base that was actively transitioning. This transition lasted about four to five months, during which the codebase constantly evolved. That was a serious challenge. Anyway, after a while, the code base split completely, and we were running a fully distributed system.
The specific challenge then was watching the code base change under you while you were still trying to understand the product. However, my favorite thing about the old times and projects was that my opinions mattered. What stood out was the level of autonomy and the importance of our opinions. It wasn't a set template of “Do this, do that.” There were days when the CTO would call me, and we would have design conversations right on the call. There's always a new challenge you can approach, and everybody was carried along. We all pitched in, and we all shared our opinions. I think that's a great way to build a team.
How do you measure the success of your efforts? Are there any specific metrics or results you're particularly proud of?
For this one, the number one priority for my team and the product team in general is customer satisfaction. We want to ensure that whatever we're shipping out, whether it's a feature, a new product, or a bug fix, no matter how minute, satisfies the customer, and we get good feedback from it, right? We don't want to ship a feature and do a lot of work for weeks, and then when we release it, it's completely unusable. That's the number one priority. We stick to the requirements and ensure that the requirements we get from the stakeholders are met to the T, and at least it works fine.
Right. One other thing my team specifically cares about is how much technical debt we are taking on. Right. So, technical debt is the consequence of prioritizing speed over the most well-designed code. Sometimes, you just want to get it out there and must be aware that you come back to redo some work. So we try to find a balance, but sometimes you take on too much technical data and need to come back and fix it. So we watch for that. That is on par with our code quality metrics. We want to make sure that our review process is good. We spot bugs before we release, which comes back to customer satisfaction.
We also care about the security and uptime of our systems. How does this feature we are releasing affect our uptime? How does it affect our customers? If our customers can't log in after we release a feature or they can't pay us, we are losing money as that goes on. That's something we make sure we keep at bay.
Since it is mostly remote, describe how you collaborate with everyone so you are all aligned on deliverables.
I'll approach this question on levels, starting from the dev team, the product team, and everyone else in the organization. For the dev team, it is quite straightforward. We jump on Slack huddles spontaneously. If you have a burning question you need answered, or have something that needs some attention beyond text, because nobody likes meetings, right? But there are some times that they are really required. You can just drop the other person a message. “Hey, do you have some time? I'd like to huddle with you.” And they jump on the call, you get this thing resolved in five minutes, and you get back to what you were doing. It is really effective because you don’t have to wait until a later meeting time. They can respond to your idea at your earliest convenience, and you can have the problem resolved.
Also, in the dev team, when we are building really large or complex features, we communicate through documentation. So, when I'm about to deploy something, I write a design spec that details everything you need to know about what will change in the system so that you can know ahead of time what will happen. You don't have to look for random things where they are not. You can refer to one spec that leads you everywhere else. That has been really helpful.
Up one level to the product team, the Slack huddles carry as well, right? We do that a lot. But one thing that also helps us is that we have daily stand-ups where we come together to discuss what we are working on and what we have worked on. In these meetings, we also hash out some more high-level product team subjects that affect the organization.
For everyone outside the product team, this one is in two parts, right? The requirements is gathering that we usually do where you go hunt down someone, say in marketing or in operations, and you try to get them to clarify a few things. Then there are times when they have requests. For the most part, it's scheduled meetings, right? Of course, Slack chat is very useful here, too, but for meetings, they are scheduled, but the same thing: you drop a message with the person you need to meet with, find a time that works for all parties, schedule a meeting, and everybody's happy.
So that's the general overview.
What is life like at Heroshe?
Life at Heroshe is great. The engineering team is fully remote and split across two different time zones. That's actually a good thing because, around the clock, there's at least one person available to take on operational issues. Although Heroshe has some heroes on the ground making things happen, being remote allows me to tune my workspace. You know, add some personalization, and it genuinely offers immense flexibility.
So, in my work life, a typical day starts with good reviews. You know, getting anyone who depends on me unblocked and giving them feedback as early as possible.
For code reviews, communication is open. There is no restriction. You spot an issue, raise a question, or request a change that aligns with the level of quality we are gunning for. If you are comfortable enough, you can jump into another team's code base and make an impact there. It's all open. We don't silo. We make sure that we pass information around as often as possible. When building a feature, the team also encourages direct communication with whoever the stakeholder is for the feature. This helps us avoid misunderstandings due to loss during information transmission. So, you can ask direct questions impacting how you deliver the particular feature.
Regarding work-life balance, a running joke in the team is that the CTO will disable your Slack for the weekend if you are not getting some rest. It is a joke, but the general undertone is that you shouldn't burn out. Of course, sometimes you need to put in some overtime, but that is not frequent and is usually paid for.
Lastly, the work culture at Heroshe fosters a sense of pride due to the impacts you can have, even on day one. My team, for example, pushes to prod multiple times a day. We don't batch releases on Fridays or wait until 12 a.m. before running the release. In general, getting work done quickly and efficiently and collaborating with team members as easily as asking for a Slack huddle is just terrific.
How does Heroshe support your professional growth and development?
So first off, and this is something that helps me greatly, mentorship. Mentorship from a more senior engineer. When I joined, I often found myself on calls with the CTO, discussing designs, walking through issues, and striving to find solutions to specific problems. That kind of peer programming and hands-on mentorship is really important if you are an engineer, right? So that mentorship is great. It started well, and it is actually a tough lead to follow because I have seen it done well by someone. I am trying to catch up and clone what he did for me so that it exists as a core value in the team, but it is also difficult, right?
Upskilling through courses is also available. I know many of us on my team don’t take advantage of this, but the company offers courses. If you want to take a course, you can definitely reach out to your line manager, who will set it up for you.
What advice would you give to aspiring backend engineers looking to make an impact in their organizations as you have at Heroshe?
To make an impact, don’t be afraid to wear multiple hats and leave your comfort zone. We backend folks tend to get buried in our terminals, but there’s a great benefit to taking on new experiences. If you see a gap that you can fill, step right in and take it head-on.
What are your future goals and aspirations within Heroshe, and how do you see the company evolving in the coming years?
I know Heroshe will be the go-to place in a few years. Our culture has started well, and we are intentional about hiring the best people. I see Heroshe becoming a household name and gaining a broader and expanded reach in this space. In the near future, I see myself helping to solidify the engineering discipline and processes.
One sentence for your fans out there!
Always remember, 6 Hours Of Debugging Can Save You 5 Minutes Of Reading Documentation.
Conclusion
Get ready for more interesting stories in our "Life at Heroshe" series, where people like Faithfulness contribute to shaping the company's journey. Stay tuned to discover the heartfelt stories behind the scenes and the commitment to love and swift delivery that makes working at Heroshe special.
