20 An Interview with Mike Wolfson

Mike Wolfson is a product-focused developer working out of Phoenix. He has been working in the software field for more than 20 years, and with Android since its introduction. He is a Google Developer Expert in Android and the author of the book Android Developer Tools Essentials published by O’Reilly. He has spoken about Android and mobile development at a variety of conferences and user groups (including Google I/O, Oscon, GDGSiliconValley, Droidcon NYC and Turin, AnDevCon, and others). When he is not geeking out about phones, he enjoys the outdoors (snowboarding, hiking, scuba diving), collecting PEZ dispensers, and chasing his young (but quick) daughter.

Mike Wolfson

Connect with Mike

Twitter: @mikewolfson LinkedIn: /in/mswolfson Website: mikewolfson.com

Interview

How did you become involved in mobile development?

I was excited about mobile, and I thought it represented the future. I picked Android for a variety of reasons, but mostly because it wasn’t iOS. The next trend is clearly going to be machine learning.

When choosing a direction, it’s important to follow your passion. I’ve never been passionate about databases, and that’s not the approach that I took. I’m interested in mobile. Making an app is really exciting for me. It’s something I was instantly passionate about, and then it became not only my hobby but my job.

What inspires you?

I like solving problems, which take many forms. What inspires me to start is really solving the right problems and solving user problems.

I know you listen to a lot of podcasts. Are there any that have had a lasting impact on how you work?

The first one that I really enjoy is The Tim Ferriss Show. The Rick Rubin episode about how to find your Zen is great. The Derek Sivers episode is really good, too. It’s a great resource for anyone interested in productivity and systems and how to be more effective.

Another podcast I really like is The Joe Rogan Experience. Again, it’s about being a better person.

A podcast that really impacts me personally is Design Matters, by Debbie Millman. She’s a famous designer in New York City. In her podcast, she discusses unique perspectives on design. As a show, it’s about how to look at the world with a unique perspective towards solving problems and keeping the human part of the computer equation.

Speaking of both sides of the equation, have you noticed any negative trends in our industry?

There seems to be a bias toward using machine learning for every problem.

What would you do differently?

The first question to ask in any situation is what problem you’re trying to solve and whether machine learning actually solves that problem. It’s important to be mindful of how machine learning might impact the solution. It’s important to think not only about how to solve a problem using machine learning but also what unforeseen problems might result from applying automated algorithms. In essence, machine learning can have complicated consequences, so applying it requires significant forethought, as well as oversight of the process. You may not know how machine learning is affecting your solution in the immediate term, but you need to be very mindful over the lifetime of the application to do auditing and understand what’s happening and how your decisions are affecting your outcomes.

Years ago, the trend was that everything needed to be mobile, no matter what. I think we may be in the same sort of situation now, where every problem looks like it has a machine learning solution, though it may not.

Mike, you’re an advocate for remote work. What are the less obvious advantages of remote work?

The flexibility of work-life balance. The most unexpected benefit is the ability for me as a developer to get into a flow state, in which I can avoid outside distractions. As a remote worker, I often find myself doing concentrated work, which software engineering requires.

The ability to get into that flow state is much easier when you’re remote. I think people don’t quite understand that. They think about all the practical abilities of being home and being able to fold laundry. But the ability to concentrate deeply is key.

Are there drawbacks to working remotely? If so, how do you manage them?

The biggest drawback of being remote is being out of sight, out of mind. This can be problematic when decisions are made without your attention or you’re left out of discussions. As a remote worker, you have to make it visible when you’re interacting with your co-colleagues. You have to be present in a standup meeting or video conference. Even if you’re not physically there, you have to make your voice heard. Your time to make that impact is much shorter than other people, so make sure that you take advantage of it.

That’s a great insight. How can a company develop a remote-friendly culture?

I’ve given this a lot of thought. The best way for a company to go remote is to give it a try. Set up some sample projects with desired metrics and measure the result of remote work on the small, confined sample project. For example, start with a single sprint for a software release. I think it’s critically important to start small and create metrics that allow you to demonstrate that you’re still being productive while you’re trying these new things.

Secondly, roll out remote work gradually. There’s no need to convert full-time office employees to full-time remote employees in an instant. Some companies are trying “no-meetings Wednesdays.” Having a policy like no meetings on a regularly scheduled day means people can anticipate and best make use of that “head down” time.

The idea of one regular day without meetings is fantastic, even for companies that don’t have remote workers.

I think that has a lot of secret sauce built into it. Freeing up just that one day for people has a big impact. It allows them to get a lot done that time spent in meetings would have prevented.

In addition to working as a developer, you also find time for writing. You wrote the Android Developer Tools Essential together with Donn Felker. What have you learned from writing this book that you couldn’t have learned as a developer?

I learned perseverance with that project. It took a long time to write, and I encountered many obstacles, but I was able to work through the obstacles and commit the time to get it done. Now I have a book on my resumé, and it’s something I’m very proud of. I think I learned dedication from that project.

How can an aspiring writer be successful?

First, practice, practice, practice. Writing is like exercise, and you need to do a lot of it. Writing blog posts or other content that is related to the book content is a great way to get started. Writing a page or two daily really helps.

As well, find inspiration in other content that matches the style that you’re aiming for. Find an author or content that you want to imitate, and tailor your own version of that product to create something awesome. It’s much harder to start with a blank slate than to start with a point of inspiration.

You might expect great developers to have a similar daily routine, but it turns out that everyone has distinct habits.

When I’ve been at the Googleplex for conferences and whatnot, as you have been, I’m always surprised by the emptiness of the parking lot before 9:00 a.m. At my workplace, our core hours are from 10:00 a.m. to 3:00 p.m., but I think there is a lot of variation. I think it’s best to appreciate that variation in people. I do my best work in the morning. At night I’m not so good, but I think a lot of other people hit their full stride in the evenings.

“The mistake is being closed off to alternative approaches. The older I get, the more I realize how much I have to learn from everyone around me.”

What’s a mistake you commonly see developers making, and how can they avoid it?

Beginning developers seem to be less open to listening to other people, especially people who are younger or have less experience. The mistake there is being closed off to alternative approaches. The older I get, the more I realize how much I have to learn from everyone around me.

What’s the best path toward cultivating seniority and expertise as a developer?

Create a portfolio and a public persona. I spend so much time with the people at my company who are writing documentation or libraries or other components for my company. That kind of work has no mobility outside of the organization and no long-term value. I tell everyone I know to write content for public consumption. It’s fine to link it back to your company, but make it about you. That way, you can build a portfolio of products, whether that’s talks you’ve given at conferences, blog posts you’ve written, or code snippets you’ve created. You own it, and you can use it to promote yourself.

In some instances, I’ve used my portfolio to avoid doing software coding challenges. I can supply a code repo that has a recycler view that downloads from a restful interface and demonstrates all the same things that their code challenge wants and avoid doing additional work. Creating a public persona has been the single best thing that has allowed me to demonstrate my expertise.

Practically speaking, people tend to change jobs frequently in the software industry. Having an online portfolio helps to establish credibility despite frequent career moves. Instead of being new at every job, you arrive with a demonstrated knowledge base that people can review and use to get to know you without your having to reestablish your expertise.

Mike’s Recommendations

• The Tim Ferriss Show podcast | Tim Ferriss
• Design Matters podcast | Debbie Millman
• The Joe Rogan Experience podcast | Joe Rogan