Over the summer of 2025, I worked with Imago on the MelonTech project. It was my first experience working with Imago and holding a formal tech role. In this article, I would like to share some of the most significant things that I learned from the technical aspects of secure integrations to teamwork processes that enabled our team to succeed.
MelonTech was designed as a system for clinicians to upload patient blood glucose readings which generates a heat map and allows the clinician to add comments along with some auto generated advice. The heatmap is visualisation of repeated high and low glucose incidents at certain times. Our team ensured the data was validated, securely transmitted, and kept compliant with healthcare standards. My own work focused on secure communications networks, medical device API integrations, data validation, and security compliance along with the development of new features.
Technical Work
The technical challenges were complex and engaging; dealing with healthcare data involves handling security requirements strictly, making complicated integrations, and having everything tested and documented thoroughly. I became familiar with how to implement security headers, handle SSL certificates, work with API authentication, and create systems capable of scaling reliably.
I performed a wide variety of engineering tasks from establishing secure communication lines, to testing medical device data integrations, configuring security enhancements after penetration testing, and debugging faults across several services. Each task reinforced how crucial it was to design resilient systems while meeting strict healthcare regulations.
The bulk of the work is understanding the task and how to approach it. I found some key organisational skills, described below, helped me complete my technical work more easily.
Getting Over the Fear of Breaking Things
One thing which did much for my confidence was pull requests and code reviews. When I first arrived, I was nervous about making changes to the codebase myself – what if I broke an essential part? What if my code was terrible?
The workflow of a pull request completely changed that. Knowing that any change was going to be reviewed by someone else before going into the main branch helped me develop without fear of making disasters. Through code reviews and pull requests, I learned new patterns, improved coding structures, avoided duplication, and ensured consistency and maintainability across the codebase.
This may feel like a safety blanket at times, but code review without real-time collaboration can easily become a checkbox activity. It doesn’t add intrinsic value and can lead to comments added simply for the sake of contributing, making it harder to understand the pull request’s actual purpose. What made working at Imago and on Melontech unique was the close collaboration and dedicated time we spent working together.
Pair Programming
One of the best decisions was the early use of pair programming.
Pair programming completely revolutionised the way I approached problem-solving. Before this experience, my only expectation of pair programming was that it was something done for the sake of doing it and added no real value. I expected someone to watch everything I wrote and require me to explain every tiny detail without providing helpful input, which would surely slow everything down. I’m glad to say I was very wrong. It helped with the most crucial part of programming: understanding what the task is and what approach to take. These are the things you need to understand before you start coding.
Instead of plunging into coding, I was now discussing my reasoning, arguing different strategies, and weighing pros and cons before coding any of it. For example, when working on the dashboard and CSV upload section, I had to explain which new routes would have to be written. This made me clarify my own reasoning and goals before coding.
At the end of the nine weeks, my partner and I were so comfortable with the process that we’d even remain in pairs even though we were programming on completely different parts of the system. We’d brainstorm together in a way, catch one another’s mistakes, and share knowledge without even realizing it. It was less and less about formal pair programming and more about collaborative thought. I also picked up practical debugging techniques like print_exc that were especially valuable when working across multiple repositories and a large unfamiliar codebase.
This experience could have easily been boring and monotonous if we had followed a pull request and code review only culture, as it strips away the opportunity to learn and grow. Had my partner been working remotely and asynchronously, with my only interaction being comments on pull requests, it would have added no real value and they could have easily been replaced with AI.
I’d like to stress the point that AI simply cannot take over the role of a software engineer. While it can program and solve leetcode-level problems, it would be useless on large-scale software with multiple moving parts because it lacks true understanding. Coding is not the only purpose of a software engineer – it is finding the best approach to a problem and understanding all aspects of the task and the codebase to hand.
Learning Agile
The agile workflow included daily scrums, sprint planning sessions, retrospectives, and regular client meetings. One valuable practice introduced by Sam (our tech lead) was that each of us should take turns running every type of meeting at least once during the placement.
It may be hard to understand why there are so many meetings and what purpose they serve for a programmer. They all boil down to answering one key question: what are we doing?
Client meetings let us know what the desired end product is, and sprint planning creates acceptance criteria to really help guide you through the task and know when something is truly completed. It’s all the work necessary to understand the task at hand so you can actually approach it and program a solution.
At first, I assumed this rotation was just about giving us exposure to project management. Over time, I realised it also helped me internalise agile practices more deeply. The meetings were all useful, and we managed the Trello board effectively through them. They also gave me the feeling of achieving something as our progress through the phase was clear.
We were prepared with set agenda points and clear Trello board progress reports for client meetings. Each one of us had a way of managing retrospectives and sprint planning. The sprint planning meetings were particularly useful in knowing what the priorities for us were and in what stage the sprint was in terms of concluding the phase. They allowed us to share our own opinions about different approaches and what we thought about the progress and key things to fix were on the project.
When it was my turn to lead a client meeting, I was nervous. It felt like a big step to take charge of the entire discussion instead of just contributing. The nervousness went beyond the fact that some of the people in the meeting were clients – it had more to do with wanting to demonstrate a working version and being able to deliver on the task at hand. Looking past the fact that they’re funding the project and there are certain expectations to meet, it’s always good to care about and understand the importance of the task.
The meeting went smoothly: I addressed all key points and responded to the client’s questions. It also showed me that I was capable of handling that level of responsibility.
Looking back
The placement gave me much more than just technical skills: it built my confidence in teamwork, communication, and leadership when needed. Most of all, I saw how rewarding it is to build technology that has a direct impact on healthcare. These are lessons that I will carry to my future work.