9. An Interview with Juhani Lehtimäki

Written by Enrique López-Mañas

Juhani is an Android Lead, Founder, and Partner at Snapp Mobile, based in Germany. He is an Android developer, design fanboy and Android GDE. He blogs, talks and raves about the need for engineers to appreciate, design and preach about a way multi-discipline teams can to work together to create great real-world products. He had 10 years backend developer experience in Java before jumping on Android, which he’s been doing for almost 10 years. His true passion is to build amazing and helpful, easy-to-use user interfaces for Android apps. He believes that the core of all this is to create a fluent and tight integration between the designer and developer disciplines. He self-identifies as a nerd.

Connect with Juhani

Twitter: @lehtimaeki

Email: juhani@snappmobile.io

Interview

Tell us a little about how your career in development started. How has it evolved since then?

I got into my first programming job after completing my first year of university studies. That was around 2000, and getting a programming job was very easy. I fairly quickly moved into working full time and studying part-time. The first 10 years, I mostly worked as a Java backend developer with some notable exceptions as an Eclipse plugin writer for a couple of years. I’ve had three big milestones in my career.

In 2008, I moved from my home country, Finland, to Germany. While my job stayed pretty much the same, working in an international environment with the English language was something new. To this day, I think the best thing I ever did was the move. Not because I dislike Finland but because the international and new environment of Munich provided a lot of new things to learn. I’d recommend everyone to move into a foreign country for at least a couple of years.

Around 2010, I moved into Android development. This happened by accident by being in the right place at the right time. My company, at that time, was looking for Android developers; while I was already dabbling into Android, I hadn’t gotten off the ground with it. So I offered myself for the role, explaining that I already knew Java—how hard could it be? Over the next couple of years, I spent pretty much all my available time learning the new system. This is an example of taking control of your future. When an opportunity presents itself, jump on it! You can always change your mind later, but you might never get that opportunity again.

Then, a couple of years later, I joined forces with my previous colleagues to run our own company. Initially, I was external but, in later incarnations of our company, I was a founding partner. I’m currently running our company, Snapp Mobile, together with four other partners. Running your own company is a challenge, but worth it if you’re that kind of a person. I don’t think it’s very likely that I’d join a multinational corporation as an employee in the future.

Throughout my career, I’ve worked in many, many different types of companies—large to small, design lead to tech-only, and local companies to multinational. I sometimes wish I would have started my company earlier. However, I believe that the experiences I gathered on the way were needed to establish the success of our current company. In any company, you can learn lessons of what to do and what not to do. In every workplace, you create connections either with friends or future colleagues and partners. In the end, I’m very happy that I took the time to explore my options before settling in.

“If you’re shy like me, talking at conferences is a great way to meet people. As a speaker, people want to come talk to you instead of you having to approach them.”

What did you wish someone had told you back when you started software development that you had to learn the hard way instead?

Software engineering is people business. We might be staring at our screens and talking more to computers than we are to people during a normal work day, but in the end becoming successful is all about your connections to people. Expand your circles and create connections. Learn to know people who think differently, have different ambitions and skillsets. These connections are what will later bring you opportunities in forms of customers, possibilities, and even potential business partners. I regret not actively putting effort in creating people connections outside my immediate circle for the first 10 years of my career.

I’ve always been shy and hated the so-called “networking.” I believed that if I just sit down and write the best code possible, I will be fine throughout my career. Unfortunately, that’s not the case. You need other people. I shifted my approach to work around 10 years ago—but I wish I had done it earlier—and forced myself in front of crowds and started organizing local meetups. It resulted in talking at conferences. This shifted my career to a new gear. If you’re shy like me, talking at conferences is a great way to meet people. As a speaker, people want to come talk to you instead of you having to approach them.

You are a senior developer who managed to stick with coding, despite founding a company and executing all of the management that comes along with that. Even though many developers seem to move into management or CTO positions as they advance in their careers, how can developers stay hands-on as they take on more management responsibilities?

I’m in a lucky position where I get to influence and choose my own role as long as I’m willing to put in the time and investment to make sure that I carry my weight in our company. I don’t like this de facto idea that if you’re a developer with a lot of experience, the way forward is to become a manager or a CTO of a company.

For a small company, like ours, the multiplication factor is important financially. Each one of the senior partners must bring in more than just their own salary to the company. The easy path seems to be to take over management of a team and increase your contribution that way. While for some people that can be a valid option, for me, that is not what I want to do.

I’m an Android expert, meaning that I’ve chosen to go deep in a single tech instead of learning a bit about everything, though I’m not saying that the other approach is wrong. My belief has long been that deep expertise can help with a company’s marketing and, in some cases, like ours, completely replace the need for marketing. When customers see what we can do, they want more. The people we have worked with contact us again after they change companies. Being good, technically, creates tons and tons of business opportunities.

Naturally, I have to sit on many seats including many management tasks. However, our company runs everything decentralized and nearly all communication is done asynchronously via our Slack channels. This means that I can participate in the company leadership discussions even when working in customer projects or other coding tasks whenever I have time.

You have written a book for Android UI: Smashing Android UI: Responsive User Interfaces and Design Patterns for Android Phones and Tablets. Can you tell us a little about your opinion on mobile UI? Do people take UI design seriously enough?

This is an area where we have seen a lot of improvement in the past years. Nearly 10 years ago when I first started blogging about UI and Android, there was very little guidance on what constituted a good UI on Android. iOS has been way ahead for years. The situation has greatly improved since Google introduced the Material Design guidelines.

The role of the guidelines was initially, and sometimes still, misunderstood. Especially technically minded people often took the guidelines as requirements, and apps not following some parts were seen as automatically bad. On the other hand, the long iOS dominance made the Google guidelines slow to be adopted by designers. Still, today, there are some designers willing to shoehorn iOS design into an Android platform causing damages to project development and UX.

The biggest issue plaguing the industry, now that Material Design guidelines are available, is understanding the processes for creating great software. There are still companies who fail to understand the importance of different disciplines collaborating in creating new products and apps. I’ve seen both sides of the failure from tech companies not understanding what designers can bring to the table to complete design-first companies promising impossible solutions based on Powerpoint presentations. We still see attempts in some companies to ignore design or drift towards old waterfall-style processes in which design is seen as a specification for development. This approach simply doesn’t work.

What are the biggest gaps or challenges between the UX design team and the implementation or programming team? How do you close those gaps?

We have already failed if we separate design team from development team. The only way to succeed is to unify the disciplines under one team, a product development team. Communication is key here as in many other places. It doesn’t matter how amazing the design is if it doesn’t get implemented correctly.

To ensure great communication between the disciplines there are a few key points. First: respect. Respect needs to be earned but both sides have to leave room for that to happen. Designers and developers have often been seen as opposite contributors. One side is artistic and utilizes more soft skills, driven by opinions; the other side is seen as very detail-oriented with work based on hard rules. This can cause disagreements. However, when both sides are open to discussion and open to understanding that each discipline contributes towards the same goal—a great product—the cooperation is greatly rewarding and provides great results. Bidirectional communication of possibilities, opportunities and effort guarantees the right work prioritization.

Next, handover tooling is important. Design-developer tooling has been improving greatly, and tools like Zeplin are creating remote-ready environments wherein handover can be done painlessly and in a format where both sides have exactly the information they need. Any team still using tools like Photoshop for design need to update their working toolchain to support modern methods.

And, finally, iterations. Initial design is an initial guess. Implemented design is not a series of screens but a functional system with user flow throughout the app. All combinations of states, transitions, micro animations, unexpected situations, etc. are not something that designers should spend time specifying ahead of time. These are things that are built into the system during design iterations and experimentation. Android is a hugely powerful prototyping environment in the hands of capable developers. That capability should be used. Developers must support their designer counterparts in experimentation. When deciding transitions, animations and user delight the designer especially must have room to try out different things. The developer’s role is to bring these experiments to life so they can be evaluated on real devices, and in some cases with real users. The designer-developer pair can, in good circumstances, put together 10–15 iterations of the same feature during a single working day, ending up with something that is not just good but great. The iteration workflow is based on the solid communication and respect discussed above.

What is another current industry trend that you think is just plain wrong?

For some reason, in many cases, software engineers tend to gravitate towards overly complex solutions to problems that don’t need that complex approach. It might come from the way we think about issues in general, but I feel that we’re setting ourselves up, and the ones we work with having to maintain our code, for failure. Whether the excuse for the overly complex approach is testability, maintainability or abstraction, developers often do not think if the particular aspect is needed.

We, as developers, also tend to worship vocal figures in our community—especially those who write a lot or present in many conferences. The community is rarely critical enough about the provided solutions from blogs and talks, and they skip the part in which they think for themselves if the provided solution is needed. This has lately become an issue in the Android community when selecting architecture models or frameworks—especially when discussing asynchronous code—where de facto popular frameworks like Rx crept into many projects without there being a need for such heavy tools. We also tend to believe that systems that took a long time to learn are good.

With this kind of complexity worshiping, we cause negative side effects. An example is when a more senior developer who subscribes to this way of thinking talks to a new developer. New developers and others who have not chosen to invest their time to dig into these overly complex approaches are talked down to and might even get ignored in job interviews or slammed in code reviews, causing toxicity and negative atmosphere for learning.

What would you suggest is a better alternative to this trend?

I want the industry to be more pragmatic in our approach to technology. We should place usability requirements to our tools and frameworks the same way we must as our user-facing work. We should demand easy-to-learn and easy-to-use framework documentation and tools and reject systems with complexity for complexity’s sake. I want people to be more critical and more open to ideas. Specifically, people who are part of software projects but not directly involved in the engineering phase should not dictate architectural solutions that they have read from a blog post but have never tried. And I want to see friendlier code review practices to welcome new developers. Nitpicking or strange and meaningless demands need to be moved aside when bringing new people on board. Systems with high learning curves should be prioritized because of their learning curve and alternatives proposed.

One trend you have advocated against is predatory practices in mobile game development. How can gaming companies find a balance between profit and “fair” gameplay for all?

I’m no longer really a gamer; however, I follow a lot of e-sports and other gaming content on YouTube. I love gaming, but I just don’t have time to sit down and play games anymore. Mobile gaming is something I would love to do. A few minutes at the time doing something fun and potentially light is something I’d be more than happy to pay for.

Unfortunately, mobile gaming started well, but ended up in the gutter. It turns out that traditional pay-up-front business models didn’t work well in the mobile app stores where apps averaged around 2–5 EUR each. In-app purchases (IAP) seemed to work well, however. I remember being in multiple Google I/O talks wherein Google pushed IAPs as the recommended way to monetize games. The idea initially seemed good: give a part of your game for free and ask for money from people to get more content.

But, again, publishers soon found out that, if the crowd was big enough, there was a better way to make money: make the game addictive by using gambling mechanisms, abusing the sunk cost fallacy, and so on. They created ways to get only a very small portion of customers to pay for the game, but to get these few customers to pay huge amounts—so-called “whales.” Gaming on mobile was no longer about gaming but about finding out how to make the game last as long as possible and adding as many paid shortcuts or time blockers as possible. This way, most people didn’t have to pay, and the masses cannot vote with their wallets as the few are still hooked and provide enough income.

As a developer, I see this doubly as sad as just a gamer. I see huge amounts of talent in gaming developers. Many games include amazing graphics and run really well on a large variety of mobile devices—this is not easy to code. But then the games are not actually games, but clicking simulators with cash stores for pixel money. I feel bad for these talented developers in the rotten industry.

I want to see gaming companies create games we want to pay to play more and not to pay to skip. I’m happy to pay to get more of something I like and enjoy, and I believe others are as well. I feel that Google is in a place to lift up games with fair business practices in their storefront, but I’m concerned that it might not be in their business interest not to do so. Google is, after all, making 30% of the ill-earned money themselves from these bad game publishers.

In keeping up with industry trends, which do you prefer: podcasts or books?

I prefer podcasts but end up reading more books than listening to podcasts for some reason. I suspect it is mostly due to my relatively short commute. In general, I try to keep my eyes open for both.

What are the three books or podcasts that have had a lasting impact on how you do your work?

First, About Face: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin and Christopher Noessel. This book was part of a university course about usability. The course and the instructors probably shaped my career more than any other book. It’s a book about a way of thinking about user interfaces and how users see them. It describes user goals, personae and mental models, all of which are very central tools for me when creating products or talking about usability. I wish everyone in the industry would read this book.

Second, the Java Posse Podcast, made up of Tor Norbye, Carl Quinn and Dick Wall. The podcast is now, sadly, already dead, but it shaped my thinking about engineering the most. I listened to these guys all the way from the very first episodes for about 10 years they kept making the podcast. I learned a lot about new technologies, new platforms, etc. But the most important lessons were about the attitude towards software engineering in general and the passion for learning new things.

Finally, The Design of Everyday Things by Don Norman. This is another book that pushed me towards championing the importance of design to my engineering colleagues and community. It’s an entertaining read about design failures and importance of design thinking.

In terms of starting your own work, how do you start your day off with a bang? Do you have any secret morning routines that set you up for success?

Coffee and Twitter.

I’m a stereotypical developer: I love coffee. I usually don’t drink coffee at home but wait to drink my first cup at work. Drinking coffee is a great way to relax after a commute and get your bearings. Even when working onsite with customers, it’s perfectly fine to sit and relax if you have a coffee cup in your hands.

I use Twitter as my primary source of tech news—I miss Google+. I use my commute for reading Twitter most of my days. This helps me to keep in the know for new developments and new ideas. I also gather a list of blog posts, mostly written by one of the amazing Android GDEs, to read later. During my commute Twitter sessions I usually try to find posts and comments that relate to the current customer or project work I’m engaged with. This helps me to get motivated and excited about the coming day. There are so many cool and interesting things happening in the tech world every day that you can usually bring something new to the table most days.

So Twitter helps me to get to the headspace of bleeding edge tech and coffee—or a coffee break—helps me to get to the project mood.

How do you stay highly productive for long stretches of time?

When we talk about staying productive during a day, nobody should ever underestimate the power of a nap. If you feel tired, sleep for a bit. No developer is productive when tired. I also tend to show up later at work if I had a sleepless night or went to bed late. I don’t believe I can deliver much value to my customer or to our company if I’m sleepy. Being at work only physically doesn’t serve anyone.

Now, about staying productive on a long project is a much more difficult question. I believe that you can’t stay excited about a project for more than 6–12 months. After the initially exciting project starts to feel boring, no matter what. As developers do their best work when excited and motivated, this difference can be huge and very noticeable.

I think there are two solutions to project fatigue. First, side projects. Take time to work on something exciting and new on your own. If possible, drop to a four-day work week and spend the rest for something you really enjoy. This separation of work and fun can quickly make you overcome the project fatigue in your work project as well, and you can get the initial excitement and motivation back. Secondly, change projects. If you’re part of a consultant company, this should be relatively easy. Talk to your managers and express your desire to change scenery. Sometimes it’s enough to agree on an end date to gain your motivation back. When a slightly boring project is finite, you know you can get through it.

Juhani’s Recommendations

• About Face: The Essentials of Interaction Design | Alan Cooper, Robert Reimann, David Cronin and Christopher Noessel

• Java Posse podcast | Tor Norbye, Carl Quinn and Dick Wall

• The Design of Everyday Things | Don Norman