Reduce build times
Reduce our build times by migrating away from KAPT and adopting Anvil
Feature parity
Reaching feature parity with our iOS counterparts. We’re over halfway there!
Test automation
Invest in test automation so that we can verify the behaviour of entire sections or customer flows
Convert Java to Kotlin
Converting the last of our Java files to Kotlin - we’re at 92% Kotlin but there’s more to do
Migrating networking stack
Migrating away from our legacy networking stack and onto our coroutine + result monad-based architecture
Open-sourcing
Open-sourcing our MVI View architecture in Q4
Investing in templating
Investing further into code generation and templating to reduce the amount of boilerplate that building a new feature requires - this includes modules, REST APIs and more
We write code that never decreases our velocity
- We think about the long-term impact of our decisions
- It’s worth investing time now for return on investment later
- We write small, focused, reusable components
- We automate the creation of boilerplate and other tedious tasks
- We write code that’s easy to maintain by avoiding over-engineering
- We write code that is provably correct by taking advantage of the type system and writing thorough tests
- We avoid creating technical debt and tackle it when we find it
We make APIs that are hard to misuse
- We take advantage of type safety to avoid invalid states
- We value composition over inheritance
- We write APIs with minimal surfaces
- We write code without side effects where possible
- We avoid acronyms and aim for self-explanatory naming instead
We deviate with purpose
- The best way to break the rules is with a full understanding of those rules
- We don’t try to reinvent the wheel, but not every wheel works for us
- We have a way of building things, but it’s okay to iterate on this when we need something new
- We don’t do things that we don’t understand just because someone else does them
- We don’t chase new stacks arbitrarily
We fail fast
- We’re happy to run experiments to see if something works for us
- We’re not afraid to discard code that doesn’t solve new challenges - we’re not precious about existing code
- We’re not afraid to talk about what has failed and we learn from it as a group
We write code that we’re proud of
- The Android team will not write code that comprises any of our other principles
- We strive for the best that we can do
- We aim to be able to open source modules in the future
Pablo A
Android Engineer
Superpower
Superhuman ability to break stuff and put it back to normal.
One liner
Can we use codegen for that?
What has been the biggest technical challenge for you at Cuvva?
Working with early stage tools. It’s very rewarding to be on the bleeding edge, but can backfire sometimes.
🤝
Adam
Lead Android Engineer
Superpower
I can say "it depends" in many different ways.
One liner
Scoping out upcoming work, investigating new technologies, tweaking CI and tweeting too often.
What has been the biggest technical challenge for you at Cuvva?
The team was given a blank slate to start again and think hard about what we wanted the team to achieve, how to do it, what our values were - there’s very few times in your career where you get to help shape a team like that, and it was too good an opportunity to turn down. I’m hugely proud of what we’ve achieved in that time and where the team is now.
Shubs
Android Engineer
Superpower
Take a problem, over-engineer the solution, get bored in the process, hack it and move on to the next problem.
One liner
Guys we need to refactor the legacy code and I don’t think this should go into production.
How did you get into Android development?
Started mobile development in 2010 and picked up Android after a brief stint with Symbian. I have worked in Phonegap/Cordova, Xamarin and iOS, however Android has always been my first love and I returned to it in 2019 when I joined Cuvva.
Want to join the team?
Check out some of our open roles
All teams
1