How we work at Mokriya

We can only expect to get better at what we do if we open it up to criticism. And in that spirit of openness I thought I would share a bit about Mokriya’s software development process. Maybe I can inspire some of you to try this at your workplace.

What’s Mokriya? #

Mokriya is a software development company based in Cupertino, but we have more than 30 employees around the world. The large majority of us work 100% remote.

I’ve been part of Mokriya for 8 months now, as an iOS Developer.

How do we synchronize #

Each product has a dedicated team, so usually I only have to sync with three to six people. Finding time for a quick half an hour call every day is easy.

But syncing with the internal team is as important as syncing with the client and for the past months that’s also a daily call for me.

So I have at least two calls every day, 30 minutes each. That single hour saves us multiple ones reading and answering email threads.

In a remote environment good communication is absolutely necessary to keep speed and quality high.

How do we distribute work #

At our daily syncs with the client we discuss new tasks, ideas and changes in the nightly build. That allows for more context on the why of some tasks, as well as technical problems being identified early. It keeps the client in the loop and the team gets time to ask questions.

The other daily sync is with the internal team. That’s when tasks are discussed and assigned.

The rest is Slack and some quick calls for rubber ducking.

Git-flow is perfect for the distributed workplace #

By using git-flow we are able to keep conflicts to a minimum and spend days working on one feature without slowing others down.

Another non-negligible benefit is the separation that comes with git-flow. We can focus on one feature at a time and it’s easier to trace a regression.

Code Review makes us feel more confident and learn fast #

We actually use git-flow with a twist. Instead of finishing features, pull requests are created and wait for Code Review before being merged.

Since we’re currently using Swift, Code Review is also a fast way for all of us to learn it at the same pace and keep standards in our code.

Iterating our process feels natural #

When we started working on this project we were committing directly to the master branch, then we moved to git-flow as the team and project grew. Code Review was later added to maintain code clarity.

In that time we already figured what’s the next step. We’re taking advantage of our Code Reviews and writing Mokriya’s Swift Coding Style Guide, which is itself being composed using pull requests and reviews.

Thoughts on my experience #

I believe iteration is really the key here. But that wouldn’t be possible without good communication.

All this started at one of the daily syncs. Each of those improvements was suggested and we tried it.

I was actually one of the more conservative ones. I thought Code Review would just suck up time. I was wrong. It just doesn’t.

I have no idea where we’ll go from here, maybe unit testing, maybe tweaking Code Review. But I am sure we’ll keep improving and if it ends up not working we’ll step back and try another thing.

If you questions or comments about this you can always reach me on Twitter.