Reflections on my Stats4SD Internship as a Remote Developer
It was December 2019 when I received an Internship offer from Stats4SD. I remember it well as I was in a taxi heading home from Makerere University. I would become a Programming Intern, working remotely! So many things have changed since this point, as I have grown as both a person and Developer. Working remotely is hugely different from working in an office. For someone like me who had never worked in a remote-based environment, the start wasn’t especially smooth and it came with various challenges. Eventually, it got better but it’s worth looking back now and reflecting on my early days. So, though I was excited at the offer, I had plenty of questions about what the Internship would look like. I knew I was in for a unique experience; one that is different from my past Internship experience of working 9am-5pm in a physical office. This article is a story where I openly share the lessons experienced through my journey of working remotely as a Developer.
The great thing about Stats4SD is that it’s globally distributed, meaning that some of its staff can work from any part of the world, at any time of the day. On my first day, I had an introductory meeting with Carlos, the Managing Director, along with Dave and Chris, my Internship Mentors. I can clearly remember that day. After my Zoom call, I remember asking myself: “So what next, what should I do?” It was a valid question really. There wasn’t any office I had to go to, yet I used to associate the start of my working day with arriving at the office. I felt perplexed at the time.
Initial challenges working remotely
Being new to working remotely, my biggest challenge was confusion over how the work was done and structured. At the start, I was mostly working from home to manage my time more efficiently. I had to ensure my Internet speed was fast, therefore I bookmarked FAST (a network speed measuring tool) on my browser. Working from home really worked out for me in the beginning, because I got a lot of things done with zero distractions, until it dawned on me that I was starting to feel isolated. I quickly found a solution to this in the name of co-working space.
2 weeks after joining Stats4SD, I decided to find a co-working space where I could commute to every day. The first place that came to mind was the Infectious Disease Institute (IDI) at Makerere University. I was welcomed with open arms at the African Center of Excellence in Bioinformatics & Data-Intensive Sciences (ACE), within the institute. This was like home to me - I had previously volunteered at ACE as an IT Specialist where I was in charge of providing IT support services. At ACE, I was glad to find a friend and a co-worker Hannah, who also worked remotely and had enough experience of working in such an environment to understand my challenges. My arrival at IDI made things more interesting. My typical workday became longer as I engaged with numerous staff and participated in the day-to-day activities at the centre, which I found exciting. Finding people you can work with is a great way to stay social. I met like-minded people with whom I had lots of things to connect with.
“Managing time is key when working remotely. The people you report to are not always around and even when you do hear from them, the communication is asynchronous. You need to be self-disciplined to accomplish many of the tasks.” Those were Shiphar’s, Stats4SD’s Research Methods Assistant, based in Uganda, words of advice. Every meeting I attended, we made action points, prioritised them, and then made sure that they were the week’s specific goals that had to be completed. Prioritisation really helped me with time management, and it also made me more focused on the things that mattered.
Of course, distractions happened from time to time, and I kept finding new ways of being focused and improving my productivity. I have to agree that with programming, things don't always go according to plan. Occasionally you’ll start a day with an objective to finish, only to realise later that you have failed the task after spending nearly 8 hours on it. This never demotivated me: in fact, most of the time when I failed at something, I would take a break, and then after a few hours, a solution would magically present itself to me while thinking about other things. This could even be at 1am or 2am! I would gladly open my computer at any time to solve the problem – and nothing made me happier
Image 1: A
picture of a week’s action points
Upping the communication game
Having differing time zones with the UK and Uganda, communication initially felt like a challenge. It was not always possible to jump on a call or get an immediate response to direct messages. A lot of my learning was done through shared screen tutorials and stack-overflow during my own time. However, it was reassuring to know that if I got stuck on something, I was able to confidently WhatsApp Dave and Chris who were always a ping away. To me, that was the equivalent of walking over to someone’s desk and asking for help. Every Friday, I met with Dave or Chris on a weekly review meeting via Zoom, as we reviewed the week’s tasks and discussed the coming week.
Living my best remote life: lessons learned
With the help and advice from my mentors and the lessons from my experience over time, I have become better at working remotely and become more productive. After a couple of weeks, I started to enjoy my remote work style, and realised how it opened up so many possibilities for me.
My time at Stats4SD was mostly dedicated to three things:
1) the Stats4SD Resources Report System (RRS), a lightweight application that queries backend endpoints, and Google Analytics endpoints to generate a usage report of the Stats4SD website and resources section. I built this in VueJS, used the Google Analytics Service, learned about querying its API endpoints, and how to use Service accounts. As someone whose experience was in ReactJs (an alternative to VueJS), it was fun jumping on to another technology. This was something that seemed impossible at first, but with both being component-based frameworks, I always found myself inferring most of the approaches from the knowledge I had in ReactJs.
Image 2: Screenshot from the Stats4SD’s Resources Report System (RRS)
2) The Research Management System (RMS); an
external project for one Stats4SD’s partners in the region, this was a result
of productive meetings conducted by myself and Shiphar with the Cereals FRN and
the Sorghum project. My interpersonal skills as a Developer drastically
improved here. One of the challenges that they faced was data inconsistency
across various devices, media, and project personnel. They expressed difficulty
in managing different survey forms, results, and other data sources. We
proposed to come up with a RMS to make it easier to centrally store, work with,
and share work resources. I used Laravel as the development stack, together
Image 3: Screenshot from the Research Management System (RMS)
3) A Google
Cloud Associate Engineer preparatory course, under
the personal development track, - here things got interesting as I had to
choose and learn a skillset of my choice. I decided to take on cloud computing
- having had some experience in Linux system administration, this was a
skillset that I always wanted to develop. I registered for the Google Cloud
Platform(GCP) course that was running on Udemy.
the end, it all paid off well, it was exciting to utilise my skills in
containerisation and deploy RMS & RRP systems into
a docker container on the Google Computer Engine.
The past three months at Stats4SD have been incredible for me; lessons were learned and new skills were attained. I successfully worked and completed two projects, the Stats4SD resources report system (RRS) and the Research Management system (RMS). I have learned and used the Google Cloud Platform. Stats4SD gave me a chance to develop and improve my technical skills. My journey has just started, but over the past couple of weeks, Stats4SD has made it feel like it started five years ago. There’s certainly more to learn, more problems to solve, and yet more to build upon - and for this, I am very grateful. As I continue my journey as a Developer, I hope to use the knowledge I have learned to solve even more problems in the wider world.
by Mike Nsubuga