”Learning is part of your job description”
On double-speed execution with Kite’s Mobile Team
This week, I got to sit down with the Mobile Team at Kite. A team of just three developers, Gurpreet Singh (Android), Dinesh Raja (iOS), and Ashish Krishnan (Android) have learned to develop at double speed through engaged Android-iOS coordination. In this interview, they dig in to working at Kite, how they stay in sync, and what they look for in teammates.
Adam Willems: Thanks for having this interview, it’s an exciting opportunity for me, and something I hope to do with other teams as well! First, I’d like to know how you guys got here, and what your experience has been like so far at Kite. What’s that history been up to now?
Dinesh Raja: I was brought in as contractor for six months, but Kite liked my work and I also got very excited about the product we were making, because the idea was really great, so I thought “let’s give it a try” and then joined as a full-time employee. We are solving problems in a cool way, and I’m excited about new products like Kite Tab.
Ashish Krishnan: I was having a tough time finding the right work to do, work I loved, when I graduated. I was crazy about Android, and I wanted to just continue working on that. I was doing the Android Open Source Program (AOSP), and there was this picture I had uploaded on a social community about building Android from source. That’s how Kite’s founder, Priyanka, found me, and looked into my GitHub account — that’s the start of an incredible journey, where my learning curve grew exponentially. I kind of transformed from a lone developer working on freelance projects or self-driven projects into a developer who could work with different teams across platforms. This has involved learning tech stacks I had never used. The level of engineering skills involved here are huge, and I’ve had a great learning experience up to now.
Gurpreet Singh: I’m actually the latest addition to this team, having joined six months ago. I actually came through GitHub — then I went through the Kite website, saw our mission and products, and came across the AngelList profiles of some other people. I found the work they do very interesting — a fintech startup that is working with real-life problems. I was also looking for a job since I was fresh out of college, and was lucky enough to be selected. The learning curve — as Ashish and Dinesh said — has been way steeper and more experiential than even in college. I’ve been doing Android for two and a half years and the Android that I did in college was way different than what we do now. It’s been an awesome journey.
AK: Even if we’re a very small team, the kind of expertise all of us have at Kite is pooled into a single thing for the greater good of the product.
AW: That’s really exciting to hear. Ashish, you just mentioned that you pool resources, and so on, but you are a cross-functional team in some ways, as a team that deals with both iOS and Android. How do you maintain product excellence with that kind of structure? That is, how do you work with one another, while staying up to date and keeping each other going?
AK: We have an established process in place. The way we dive into solving problems is commonly decided upon — all problems are put first on paper, and then we ideate upon it, brainstorm it, and then figure out how things can go wrong. Everyone on the team is part of one of two factions: the Android faction and the iOS faction. Since both the platforms are so independent and so different, we first ideate on the business logic and stuff like that, the things that are common to both factions, and then talk about the subtle differences we might have in the platform. We solve it on paper first before we go and solve it ourselves. So this is the first step. The second step is basically our tech stacks, and the engineering tech stack is very similar; we follow something called reactive extensions for our individual programming languages, and the contract of that language is so similar that if one of us implements a business logic it’s almost the same just with subtle syntax differences. The iOS team can pick up something the Android team built, and find issues with our way of implementation. It’s like all of us are on the same page, even if we are talking two different languages. All of this comes from the process we have established over the period of six months, before we started working on this particular product.
It’s like all of us are on the same page, even if we are talking two different languages.
AW: Right. So you guys use reactive programming, that’s one thing. What are other ways that you make sure that you work well together?
DR: I’d add that we all use the same kind of IDE, the same keyboards and the same kind of physical environments. That way, if we need to work on someone else’s machine, it’s way easier for all of us. We do pair programming regularly and follow strong engineering practices, including considering future feature requests in the product. These all improve our daily work in major ways.
AK: We work as a system. A system has a lot of moving parts, and each of the moving parts should work in parallel for the same thing. When we have such a large number of moving parts, our process establishes that there is no front and back, and that it’s all a seamless integration of different parts.
GS: I can turn on Ashish’s machine and use it properly, because the keymaps are the same for both of us. The tools do not create a barrier, but remove the problems that might cause friction between teams of different kinds.
DR: Even though our work is different, everything is so similar that both factions can accommodate the same solution and benefit from that. If we work on certain features — like if the iOS team works on a certain feature — and if the Android team wants to build the same feature, then there’s no need for explanations. They can simply see our code and develop the same feature without any problems, because the code, the language, the IDE that we use from both teams are completely similar, so that picks up the development speed.
The tools do not create a barrier, but remove the problems that might cause friction between teams of different kinds.
GS: The things that we do — the code portability, the reuse of code — mean we find bugs more easily, and what we develop is well-tested and test-driven. If the iOS team is working on a feature the Android team does not need to start from scratch and rebuild the entire thing. We can essentially port their code into our code, and they can take our code for other features. It’s well-tested, meaning both of us can move with essentially twice the speed we otherwise would have.
AW: Awesome. In general, I think people would also be interested in hearing what libraries you guys use.
DR: We use libraries for different use cases. For networking, we use the Alamofire library along with default JSON Codable protocol. For databases, we use GRDB and its reactive extension. We are using RxSwift, RxCocoa, RxTest and few more reactive extensions like RxAlamofire, and RxBlocking. For background jobs, we use SwiftQueue. We also use Swinject for dependency injection and Cuckoo for mock objects.
GS: For Android, Ashish mentioned that we follow the reactive manifesto, and we have a reactive codebase. For networking, we use retrofit and okHttp, which work beautifully with our tech stack, and then of course we have RxKotlin. We use Kotlin for Android, not Java. We also have RxAndroid, and for logging we use Timber. Also, we use the Evernote job dispatcher for dispatching background jobs.
AK: To sum this up, our architecture is MVI (Model View Intent) which is an architecture launched in 2014. Since our architecture is fully reactive, all the libraries we choose are preferably fully-reactive libraries. We’re big fanboys of Square Open Source libraries, and so we use a lot of them. So our database layer is also reactive, we use Google’s Room architecture component; our view interactions are also reactive, meaning we use Jake Wharton’s RxBinding, so everything that we include tailors to the architecture we have in place right now. It is easily integrable and works for every team. We try to find something similar and reactive for every platform so that we have the same set of ideologies and libraries.
AW: Makes sense! My last two questions: what are you most excited for in the next few months on the Mobile Team? Also, if this team is going to grow in the next few months, what kind of people are you looking to join the team?
AK: We are very interested in the way our architecture is shaping up, the way our architecture is solving every day, every minute. We’re encountering new challenges and we’re trying to solve things as pragmatically as possible, keeping our core principles in mind. We are excited about solving the product’s business requirements, and we see them as challenging in a good way, meaning we’ll solve the issues in test-driven ways. Testing is fun, testing should always be kept in mind.
Everyone makes mistakes, but the real question is how we come out of them — how we take the constructive criticism given to us, and how we solve them for ourselves and the team.
GS: Whenever we expand our team, we would definitely look for someone who embraces this style of programming, who can think reactively, who can easily port themselves into the way we’re headed. Most importantly, this person needs to be open to feedback, who can take criticism positively, and move for the betterment of the team and the organization.
AK: I want to quote something that I saw on Dinesh’s Slack, which is Learning is a part of your job —
DR: Learning is a part of your job description. If it is not—
AK: —then you’re being cheated. One of the things we’d look into for the next people who’d join us is an eagerness to learn, and a passion for what they’re going to build with us. Feedback on our team is also always welcome. Everyone makes mistakes, but the real question is how we come out of them — how we take the constructive criticism given to us, and how we solve them for ourselves and the team. Passion is something that is very important, and that comes down to part of our culture at Kite as well.
