Engineering at mPharma: Looking Back at My First Week

Before starting at mPharma, I hadn’t heard much about the company’s culture so I didn’t know what to expect. My decision to accept the offer was influenced by the conversations I had during the interviews. Being asked questions about my submission and making suggestions on what I could have done better provided a learning opportunity for me.

Photo by Matt Ragland on Unsplash

I’ve heard of 2 vastly different scenarios that speak about the frightening situation of starting at a new company. At some software companies, due to problems like poor documentation practices or improperly maintained projects, a new developer could stay for some months without making any significant contribution to the existing codebase — the time is sometimes spent trying to decipher cryptic codebases. On the other side of the spectrum, some developers grapple with a steep learning curve; they are thrown headfirst into a monstrous legacy codebase. These stories can give any programmer nightmares when they sense that their current situation might be close to that.[1][2][3]. I had thoughts of these on my mind as I received an onboarding schedule for the week.

Meetings are organized for all new hires to interface with the various business units. The knowledge gained from these meetings has benefited my understanding of how the company operates as a whole. Through this, I learned that accountability, customer focus, and teamwork are core pillars of the engineering team. New and existing team members are treated with a level of warmth that gives a glimpse into how teamwork is valued here.

Teams are grouped around business units at mPharma known as squads and I am part of the health services squad. Working as a Backend Engineer on the health services squad has proven to be an awesome experience for me. The unique combination of starting at an established company but on a newly created team provided a balance between working with a level of responsibility required to operate effectively on the team, as well as having the freedom to learn and make mistakes. With regards to the rest of the engineering team, I understood that everyone is in a constant state of learning and improving themselves. This is not only true for the engineering team but the company as a whole.

To foster collaboration among team members, the team use Jira for product management, Trello for long-term product roadmap planning, Confluence for technical documentation and meeting notes, Google Meet for demos and meetings, and Slack for communication.

In Software Engineering, the little things matter and I was thrilled to see that mPharma cares about little things like how to write commits and name branches. There’s a standard way of naming branches across mPharma engineering in a bid to foster team collaboration.

Across Gitlab repositories, you’ll see branch names like:

feat/<JIRA-ID>-register-mutti-members 

which implies a new feature branch. Others such as:

impr/<JIRA-ID>-add-sms-to-reminders 

which implies an improvement to an existing feature and

fix/<JIRA-ID>-email-notification-sending-multiple-times 

which implies a bug fix.

mPharma is a growing company and as such some processes are put in place to yield a transparent and productive Software Development Lifecycle (SDLC) — tasks are completed in a 2-weeks sprint and follow the steps below:

1. When engineers are done working on a task, peer code reviews are done for every merge request to ensure that engineers write good code.
2. As part of our workflow, there’s a Continuous Integration/Continuous Delivery (CI/CD) integration managed by the Development and Operations (DevOps) team which makes deploying microservices to staging and production environments a breeze.
3. There’s a Quality Assurance (QA) team to test and audit new features and bug fixes to ensure that quality software is shipped.

Conclusion

There are several reasons many people join a company — in search of career growth, a higher salary, and also a chance to learn and improve as a developer while solving problems. It is easy to believe that being a Software Engineer means writing code all the time. But I can say without a sliver of doubt that within my short period at mPharma, my software engineering skills have benefitted from the quality software implementations that surround me. I particularly enjoy being here because I get to learn new things each day. Though having been here for a while, I could still ask questions like a new hire and get an appropriate response.

Every day seems like day one!!!

¹ First programming job, feeling overwhelmed
² The pros and cons of being a software engineer at a BIG tech company
³ I got fired after 2 months in my first software development job