23. An Interview with Iñaki Villar

Written by Enrique López-Mañas

_Born in the beautiful island of Majorca, Iñaki is an Android Developer since 2011. He has worked in different industries such as banking, airline companies and tourism. He is a Google Developer Expert in the areas of Kotlin and Android and an open-source contributor with projects like Kakao or Talaiot. He has participated as a speaker in more than 50 conferences in 20 countries. He currently resides in Los Angeles and is a Build Engineer for Tinder.

Connect with Iñaki

Twitter: @inyaki_mwc

GitHub: github.com/cdsap/

Medium: medium.com/@inyaki_mwc

Interview

You have been focusing recently on testing, being a net contributor to the Kakao library. What is a common misunderstanding about testing?

I meet developers arguing that they don’t have time to write tests or their managers don’t give them time to write tests. This is wrong. Testing is an intrinsic part of software engineering and you must test your code.

Another misunderstanding is the abusing of mocks in your tests. The first rule is “don’t mock classes you don’t own” but I want to rise to the impact on a large suite of tests using mocks. Mocking is an expensive task, and you can face OOM easily in your build tests.

How is testing properly done? Are there any aspects we overlook?

It is vital to keep a good architecture in your project. The separation of responsibilities in different layers will allow you to write more specific tests. Having a pure Kotlin module will help you in writing host tests. When you want to use more advanced Testing like E2E tests, your architecture will play an important role because you want to hook easily into different scenarios.

Then it is essential to understand the difference between unit, integration and E2E tests. Testing is not only a technique to write tests under the JUnit runner. You have to follow different strategies to write the code when you want to apply more UI testing patterns like Page Objects.

Regarding overlooking, I would say code coverage. Coverage is a great tool that measures the degree to which the source code of a program is executed when a particular test suite runs. For instance, since the adoption of Kotlin, some of the fixed rules of having a specific percentage of coverage on your project don’t make sense. Kotlin compiler generates the bytecode and you don’t have to spend time covering code that you haven’t generated. As an example, you can create a simple class with a lateinit variable, write a simple test and apply for the coverage to check why it doesn’t make sense having a fixed coverage.

You are well-known as a speaker in the community, giving insights such as this. Is there any procedure you follow to prepare your sessions? Is there any trick you have before presenting at a conference?

In the preparation of the session, I like to back the presentation with a story, such as a plot of a book or movie. My procedure is splitting the presentation into three to four essential sections. After that, and before working in the slides, I write a script with the content and the references for the presentation. With different iterations, I try to fix and update everything in the following weeks.

“It’s important to review the state of tooling and testing of new technology. When you are working in medium-to-big teams, the adoption should be escalated and measured.”

Android is a key topic for you in some of your talks. You have been an early adopter of Kotlin, which came to revolutionize the Android world. How does one decide on adopting new technologies? How do you deal with the risks of jumping too early, too late, or jumping in a technology that ends up falling short?

Always, the adoption should be a trade-off of measuring the risk and impact in your product and team. It’s important to review the state of tooling and testing of new technology.

When you are working in medium-to-big teams, the adoption should be escalated and measured. You can choose and experiment with a feature or a team in the organization. Once it is validated, you can escalate to other teams or features. In negative cases, you won’t expose the other members of the team.

Tell us about the cheapest professional investment you have made in your life.

Regarding professional investment, the subscription of SafariBooks. It gives you access to thousands of books and videos of different technologies. Monthly, I choose one topic far from my current tasks and try to learn new things.

What would you recommend to a fellow software developer that is starting their career?

Software engineering is one of the most in-demand careers nowadays—you have positions like machine learning, mobile development, devops, backend or frontend, but the fundamentals are the same for all of them. I recommend having the Swiss Army knife of skills: data structures. I know it sounds boring, but they are present everywhere. Then you should know networking and containerization technologies. And, finally, invest time to learn one typed language and one dynamic language.

We have more resources than ever today to improve in our career, GitHub and StackOverflow, newsletters, even Slack groups are perfect sources to learn more. I would suggest to pick up a repository on GitHub and start learning the internals of the project. Also, you should join communities, events or meetups. The social part of your job will help you meet other exciting engineers and projects. And who knows? Maybe you will give a talk at these events.

You also have a unique track of working with different cultures in the same company. How do you bridge these cultural differences? Is there any tip you could give to people working or aiming to work in a multicultural environment?

I remember counting 24 different nationalities in the Mobile Team in the last company. I enjoy these kinds of environments. Of course, you have to be open-minded, but sometimes it is inevitable to fall victim to some cultural shock. The important thing is always communication and aiming to learn from others.

As a fun fact, a very good friend, Leonid Olevksy, organized a monthly event to know more about the cultures of the team. We learned about Nigeria, Indonesia, Israel, Russia and other countries, and I enjoyed helping us to understand each other better.

Tell us three technical tools not widely known that you use frequently.

First, SdkMan, which is a tool for managing parallel versions of multiple Software Development Kits. It provides a convenient CLI and API for installing. Next, Gephi, which I’ve used lately when I’m working on projects with data structures like graphs, and I need to analyze data. It helps you with visualization, and you can also provide different graph algorithms to better understand the composition of the graphs. And, finally, Koshry, which is associated with Kotlin projects. It gives your team the ability to monitor pull requests and take automatic actions, depending on your rules result. It helped me to define a better process in the team and is easy to extend. It’s similar to Dagger but Kotlin oriented. You can extend the fu switching, remove and list candidates.

What are the three additional resources—such as books—that have had a lasting impact on how you do your work?

First, Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. This is an essential book for designing software applications. The book talks about using model-driven design to create a domain model and ubiquitous language that everyone in the company can leverage.

Another is Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill. With a funny story behind the main topic, it provides powerful tools and techniques to successfully maintain your software.

And, finally, Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann. The book gives a comprehensive overview of design aspects for systems working with data, systems, databases, tools and techniques.

**In working with these tools or others, how do you keep yourself productive through the day? **

I like the Pomodoro Technique applied in 60 minutes. I also plan personal sprints of two weeks of things I want to learn and continue improving in the skills. Exercise is also essential. It doesn’t matter if you can run 10 km or 2 km, the important thing is to clear your body and mind to be more productive every day. And to make things more fun. I try to explore new sports in which I have to learn and listen from the professionals.

Iñaki’s Recommendations

• GDG communities | developers.google.com/community/gdg/

• O’Reilly books | oreilly.com/online-learning/individuals.html

• Uber Engineering blog | eng.uber.com