Darwin — Inteligência em Saúde

About

Darwin is a Brazilian health platform: Patients get their medical history, appointments, prescriptions, and treatment tracking in one place; doctors and clinics work on the other side of the same system.

I joined as a freelance engineer and consultant, mainly to lead junior and mid-level developers, guiding them with code reviews, best practices, or even with the complete React Native project revamp needed after this project was built with a complex architecture by one single developer and no one else on the team knew how to touch it.

The project

Health software has a particular weight to it. The data is medical, the scheduling is somebody's real appointment, and telemedicine means a consultation either connects or it doesn't. That raises the cost of the usual shortcuts considerably.

My work split three ways.

1. Structure and patterns across three codebases

I worked through the front end, back end, and mobile application, organizing code structure and establishing patterns that were consistent between them. Most of the time I didn't touch the code itself, but had meetings with the developers to solve problems, answering questions and guiding the best practices when manipulating the database, when creating new components on the client or dealing with video.

2. Raising the bar through code review

In order to make the team grow, I also invested time in code reviews, which was the main source of knowledge sharing with the team, since it was there documented in the PR rather than something we talked about during the meetings we had to tweak specific problems.

It is interesting that I also learned a lot on this project, since sharing ideas, best practices or reviewing code always needs the skill of communicating important parts, but also understanding what makes a difference or not, and what really needs to be done or is just my personal opinion, which is not a valid argument to request a change and perhaps slow down a feature release.

3. Owning the release process and restructuring the mobile app

The main project I touched was the mobile app built with React Native. The scenario was: A developer built this project for some time, without communicating with the rest of the team and applying specific code structures, like atomic design, as well as a very spaghetti code, that touching one place could break the other, which means that the pattern decisions taken were not really helping with the code maintainability. I took this project, talked with other devs that confirmed no one really understood what was going on there, then I focused on updating the parts of the code that make it simpler, not more complex. Since it was a quite simple application at that time, I decided to move from the atomic structure to a more common "components, pages, services and utils" folder structure along with making the code more specific, just making small components reusable across the codebase for UI/UX consistency, leveraging the atomic approach, but making it simpler for newer developers.

The team was VERY happy with the results, which also led other developers that were excited about working with React Native to finally start to contribute to the project, which was the main validation to me that the code structure now makes sense.

Along with that, I also handled the Google Play publishing process, enabling that to go live. At that time, the Android platform was the only one needed, but I know they have the iOS version published as well today, since I'm a user of the app I helped to build :)

Conclusion

This consultant experience was great and fun to work on, mainly to help structure the code across projects for such an important startup at an early stage, setting the ground for all the great work they've been doing over the years. Learning how to communicate with other developers, helping them, talking about best practices and learning from them is something I bring with me.