I insist in good practices and pragmatic reasoning.
I’ve coded Android apps for ~8 years until today. My background is mostly product work and Open Source. I am very focused on:
Decoupled and testable architecture
MVP, MVVM, MVI and other unidirectional data flow approaches like Redux. My position on architecture is pragmatic and reasonable, based on the needs. Unidirectional Stream based ones are the ones I find more valuable lately.
Overall, any decoupled architecture with clear concern separation and a proper way to instantiate / pass dependencies can be a testable architecture.
I’m used to diverse testing strategies ranging from UI tests (espresso), black box end to end tests (feeding inputs on one side, asserting over state in the other), API Integration tests (MockWebServer or Hiroaki, wrote by myself), solitary and sociable unit tests, and more.
I try to avoid coupling tests to implementation details, so refactoring production code doesn’t imply refactoring tests, as possible. When that happens too often, I believe tests are not providing much value.
Testing strategies always depend on the needs for your business. I insist on being smart about which ones to pick.
Checkstyle (preferrably autoformatting on every commit), PMD, findbugs, Android Lint. Writing custom Lint rules is a game changer, in my opinion. I link to think of tooling as a mean to speed up and ease the work of the team.
Conscious git workflows based on team needs, automation and CI. Integration with tools like Danger for posting automatic issues for reporting linting and formatting issues. That leaves nitpicks to bots, and leaves room for more valuable feedback coming from your team mates.
Along with automation on CI, I consider CD (Continuous Delivery) key. I’ve used it both for releases and internal alphas / betas to test across the team. In my opinion, shipping fast and automating it unlocks earlier feedback and faster iteration.
UI / UX
I put really big effort on achieving state of the art UI / UX following Material guidelines. For some reason not many engineers value that side as much as the architecture side, but here is where I find real fun and motivation. It’s also the side end users experience. I’ve always been very interested on visuals, also having worked much on low level rendering in Android. Wrote this library when Android didn’t support SVGs yet.
Unlocker / Connector for the teams
I love working as unlocker / connector for all the teams involved in a feature. In my opinion, filling the gaps between product, design, mobile and backend engineers is drastically important. I like to sit with designers to understand their needs, so our communication can improve. I’ve learned a little bit of Sketch (very basic, but enough to draft things for shortcutting proposals coming from the engineers), and some backend development. I have built Resful APIs using Play Framework, Ktor, and Spring Boot for side project apps, when serverless is not enough (e.g: Firebase).
I’ve also worked on bringing to life a few design systems for different companies (for the Android side).
I’m pretty active in the Open Source world, having created many libraries as side projects for both Android and Kotlin, and being part of the Arrow maintainers team. Some libraries I’ve created can be found here.
I’ve got experience with imperative programming, OOP, Reactive Programming and Functional Programming. The later being the one we’re exploiting more in Kotlin since we started coding Arrow.
English and Remote
I have worked as a full time remote engineer from Spain for more than 4 years. I’ve got enough experience and advanced English skills, having worked for some international companies as a contractor. Some of them in the US. I’m also an active speaker in international events.
Please feel free to contact by any of the mentioned networks or by mail.