When I joined Obvious, Simple—an open-source app for clinicians to track patients with high blood pressure—was in beta, and since then has been at the heart of my work. I’ve been working on the app for more than a year now, and it has been quite a journey! Our engineering pods usually have two to three engineers and one team lead, and our work has found a sort of daily rhythm that we’ve figured out along the way, with some trial and error.
A disclaimer before we dive in: thanks to the pandemic, this routine has undergone a few changes. But the crux remains quite the same: a great balance of deep work and collaboration.
9:41 AM
My usual workday starts while I am in the cab and on my way to the office. I live quite a while away and, with Bangalore traffic being what it is, this is an excellent opportunity to get some work done! I fire up the “Sandbox” app on my phone and update it. I quickly test a feature that was merged yesterday. The feature is for our target users who are nurses working in rural India, enabling them to follow up with patients quickly. Looks like it’s working well, which is my cue to post on the Slack #releases channel that the feature has landed on Sandbox so that the design team can test it out.
10:17 AM
Once I reach work, I grab a cup of coffee on my way to my desk, located in the “quiet zone” designed to help us get deep work
done. After going over my Slack messages and responding to a few, one
of my teammates’ asks me to discuss the code review feedback I left for
them. So we go into a meeting room and collaborate on refactoring a
piece of code that was increasing our code complexity. After a few
minutes, we figure out a way using Kotlin’s beautifully designed APIs.
LGTM!
I look at my open pull request from the day before, and it is still under review. Since we follow trunk-based development, I cut a new branch from the branch under review, and continue working on the feature. An iteration in this project is usually a week-long, spanning Monday to Friday. We cut stories for each feature and make sure that one story is never worth more than 3 points (points being a mark of effort and not complexity) because only so much can be estimated by an engineer!
11:55 AM
I start writing a test to verify a small feature using the given-when-then representation. Ever since a senior engineer helped me start on Test-Driven Development (TDD), I have been pushing myself to write tests before I even think of implementation. After adopting this approach, it has allowed me to follow a more user-driven approach to building software. I run the test and it fails — of course! — because the code is missing. So I go ahead and write a small piece of code to make it work. I commit once the test passes and then refactor the implementation a bit and run the tests again. Make another commit. And this goes on for about an hour till lunch.
12:30 PM
By now, most of us are eagerly waiting for the Slack notification that food has arrived. Lunch is often a chatty affair, with discussions ranging from public transport to culture to street food. Since Obvious houses both design and engineering teams, we also end up spending considerable amounts of time discussing one common critical aspect of our work: user experience.
2:10 PM
Lunch is over and one of the designers wants my opinion on something
new that’s being added to the flow. They are trying to figure out a way
to de-duplicate entries in the system by allowing users to identify and
delete the duplicates. This is where the real advantage of having both
designers and engineers working at Obvious comes to play. We are able to
minimise our feedback loops
immensely by collaborating more often. This helps designers translate
their user-centric design to a final product and helps engineers be
closer to the users, by doing more than just writing code.
One of our engineering philosophies is that “we review code before we
write code”, so after lunch, I dedicate some time to reviewing assigned
PRs. This also helps me contribute by doing work which does not require
deep focus right after a good lunch. I also go over other PRs which
gives me a sense of what’s happening around the project.
While we are on the topic of reviews, here's a cute habit I picked up recently from a teammate. We drop small positive comments or emojis in the open pull requests, especially on ones that are not assigned to us for review. It’s such a small thing in terms of effort but it goes a long way in building trust within our team.
3:49 PM
We don’t have our daily stand-up today so I continue on the feature
to introduce diabetes management into the app. It is a long-running epic so it will have multiple stories and PRs. All of this code is hidden behind a feature flag
while in development. Therefore, the feature may not actually work
right now, but our CI workflow ensures that code compiles correctly. We
can never break the master branch, and this enables continuous delivery.
I receive a Slack notification that my PR from yesterday has been reviewed and I need to address the feedback. So I pause working on the new feature and first close the requested review changes, keeping in mind that “Delivering code already written takes preference over writing new code”. I wrap up work until the end of the day and push today’s branch to raise another PR. And the cycle continues!
6:06 PM
At the end of the day, I go home proud of what we’ve achieved and even a terribly long commute doesn’t look that bad!
We have come a long way in a few years. Simple has now launched across India, Bangladesh and Ethiopia, and is heading into other countries. Lots of credit for a job well done goes to our team processes, developer habits and work ethic.
Oh P.S., we’re hiring!
If the Obvious Way makes sense to you, let us chat over virtual breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!
