跳转至

32 An Interview with Dr. Joseph Howard

Joe is a former physicist that studied computational particle physics using parallel Fortran simulations. He gradually shifted into systems engineering and then ultimately software engineering around the time of the release of the iOS and Android SDKs. He’s been a mobile, web, and systems software developer since 2009. He’s currently a Senior Architect at CVS Health, helping people on their path to a better health.

Dr. Joseph HowardDr. Joseph Howard

Connect with Joseph

Twitter: @orionthewake

Interview

In your current role, you have a diverse set of responsibilities. You lead a team of Android developers, write tutorials and books for raywenderlich.com, and you’re currently the Android Pillar Lead for raywenderlich.com. How do you balance all of them?

In any role in which you’re managing a team, it’s important to have long-term goals and short-term goals. This is also true as an individual contributor when making applications or content. So I try to break things down to form long-term goals — the ones that I’m thinking about in terms of, say, a calendar year. We do that internally at our company, Razeware, starting in January and wrapping it up in December. But, to give more structure to the goals, I approach them on a week-by-week basis—how to go through each week to try to achieve those long-term goals. Then, each week I think of daily priorities. So I break down all the goals and try to prioritize them. What do I need to do week to week, then what do I need to do each day of the week to finish what I need to do for that week.

In terms of my specific responsibilities, there’s a lot of context switching. I’m doing more now than just Android, leading other teams as well. So I’m building things on Android and building things using other technologies, some of which I’m brand new to.

I try to organize my week so that each day I’m within one context, whether it’s making videos, writing content, performing editing tasks or whatever the case may be, I try to find tasks that will take a full day, to try to minimize the context switching. Rather than spending an hour on one thing and an hour on something else, I do what I can to try to spend a day on a given thing. It rarely happens that way. But, at the beginning of the week, I lay out what I’m going to do each day and then try to spend as many hours on any given day doing that thing. There are meetings and other things that get in the way, but I just try to take it day-by-day and build-up from those daily tasks I’m working on.

A few good weeks in a row lets me know I’m on the way to achieving the long-term goals that I set out for the year.

You’ve mentioned meetings and I think there is a connection between meetings and context switching and these might be a particularly important problem to solve in a remote company since communication is the key. So what are your views on the meetings between development teams? How often should they happen? How long should everybody be at the meeting? How do you operate?

I’m a stereotypical engineer that’s not the biggest fan of meetings. Fewer meetings always sounds good to me. Meetings are necessary and, in certain situations, you need to have long meetings. But, for me, a working meeting should always be half an hour or less. People tend to schedule most meetings at an hour by default just to make sure they have time to talk about whatever they need to talk about. And then often that hour gets filled with stuff that wasn’t necessary for that particular meeting.

I try to keep things short, be direct, talk about the thing we need to talk about and then let everyone go—go on and do what they need to do. Being remote, it’s very nice in that you kind of strip down and just have the meetings that you need. For someone like me, it’s great because we’re using technology to have the meetings, whether it’s Google Hangouts or Skype or something else, and that motivates everyone to have a good meeting. We discuss what we need and then go about our day after that.

In my role, I tend to have some weeks that have just one meeting — a weekly all-hands meeting. Other weeks, I’ll have 10 or more. It varies week by week. The days when I have no meetings are the days I’m the most productive for sure.

To start, finding the right tools that will help you work remotely is key. My previous position was full-time, working in the nearest city. The management team started letting people work from home one day a week. Remote workers would use Google Hangouts or the like to go to whatever meetings they needed to go to. If your company is trying to go in this direction, it’s important to figure out what the tools are that you can use in terms of meetings and communication. Slack is another great tool to maintain communication between people. It’s also important to set guidelines for communication—what’s best communicated over email versus Slack? What’s the right tool to use for a meeting?

For example, when I write someone a Slack message, I don’t expect them to respond to me right away. Even if it says they’re online, I assume, okay, they’re going to get this and they’re going to respond to me when they can. Making it clear to everyone what the expectations are is important so that people know what to expect. If you use email, for example, consider an informal rule that you’re not expecting someone to get back to you for a couple of days, but then expect everyone to respond to emails within a couple of days so that you’re not leaving people hanging when they send you an email. This kind of communication expectations can happen when onboarding people onto your team.

I also try to be very flexible because our company is remote and you have to be very flexible with scheduling, adapt to changing requirements and plans, and have different expectations over time. With each different group of people that I work with, I just try to be as flexible and understanding as possible and work with people in ways that are good for them.

You’re leading different kinds of teams: writers, editors, instructors, and developers. What are the key differences in leading different kinds of teams?

Learn the terminology of each group of people that you’re working with. For example, the technical language of a developer, or the terminology that a writer uses to communicate. And then also understand each person individually, what their background is, and what their role is. If I’m talking to an Android developer that I’ve worked with before, and I know roughly their level of experience with Android, then I can use certain terms and assume things about what they will know.

On the other hand, when I’m working with an editor from our site who isn’t an Android developer and who doesn’t have that background, I won’t just throw out an Android term and expect them to know what it means, because they don’t have that context. I try as best I can to treat people as individuals.

As you work for a global company, there is a lot of diversity in your team. How does diversity improve a team and how do you think we can increase the diversity in the tech industry?

Diversity improves a team because everyone has different experiences. Everyone has different backgrounds, education, and many other things that shape who they are. No one knows everything. Having a diverse team makes the overall team stronger because people can share their knowledge and experiences with one another. It’s extremely important to be able to learn from other people and understand how each of us contributes. It’s important to learn from each other and be open to the possibility that other people know more than you do on a given topic or area or life experience. You also need to be willing to share and be open with them about what your background is.

In terms of improving diversity, we try to make sure people have equal opportunity to excel. We need to try to engage communities that haven’t been represented in tech and engineering, and then do everything we can to bring that opportunity to every community in ways that could help build that diversity over time.

“My job is to give the people that I’m working with what they need to succeed in whatever it is we’re working on, but also beyond that in their careers, and, longer-term, as people. I work for them; not the other way around.”

What are the other traits of a good leader or a good manager? What is your leadership philosophy?

Leading by example is one of the best ways to be a leader. As I’ve gotten into leadership positions over time, I’ve found that to be the most natural way to try to lead. I’m not the most extroverted person—definitely more of an introverted person. I try to do my thing and not worry so much about the people with whom I’m working seeing what I’m doing. It’s also important, as a manager, to provide people on a team with what they need to succeed. As I’ve been put into management positions, my approach is to feel that I’m working for the team; the team isn’t working for me. My job is to give the people that I’m working with what they need to succeed in whatever it is we’re working on, but also beyond that in their careers, and, longer-term, as people. I try to work for them and not the other way around.

What is a common error that leaders commit and what do you think they should do instead?

I’ve seen leaders be a little bit too careful with information and not sharing information readily. That can be demoralizing to teams. It’s important to be as communicative as possible with all members of a team. People don’t appreciate being kept in the dark. If that happens regularly, it can bring a team down and be demotivating. There are valid reasons why people in leadership positions can only give out so much information. But I’ve seen leaders and managers that have done that way too much. It’s very important to give as much communication to your team as you can and let them know what’s going on to the greatest extent that you can. It empowers people once they have a better idea of what the goals of an organization are and they see how you are planning to get there.

In drawing your own insight from outside resources, what do you prefer—podcasts or books?

I enjoy both. I listen to podcasts as much as I can, for sure. Having said that, I am a huge book person. I buy way too many books and eBooks. I’m kind of at the point where I can’t find books to buy because I’m constantly at the bookstore looking for new things and always trying to make sure I’m staying on top of the latest technologies. I find that books, even though they’re not as real-time as blog posts or the things you would find online, have a full narrative of start to finish. I get to start from the beginning of the book and then feel that I’ve accomplished something once I’m done.

When eBooks first became a thing, I thought they were the holy grail. I thought, “Oh this is so great; I can stop buying all these books and spend less money and have everything on my computer.” But, then, over time, I realized I do prefer print books. I like the fact that they’re formatted and people have put a lot of thought and effort into making them look good and giving them a real flow. For most books, especially ones that I’m into, I buy both—print and eBook if it’s available. When I have time to sit down and read, I’ll pull up the print book and then, especially if it’s a technical or programming book of some kind, I will have it on my computer to try to follow along with the code.

What are three books that have had a lasting impact on your work?

One would be Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. It’s a well-known book that many software developers have read. My background isn’t in software or computer science. I was actually a physicist before starting my career as a software developer; my background training is in physics. So I didn’t come to software as a software engineer, I came to it more as a scientist. Clean Code made an impact on me in understanding that there’s a lot more to programming than just writing code. It’s a prevalent idea that code is read much more frequently than it’s written. That book was the first one that exposed me to the idea that you’re writing code for yourself and other developers, not so much for whatever the application is you’re developing. You have to balance both things. It made a strong impact on me and it is still completely relevant to this day.

Another one is more recent. It’s called The Problem With Software: Why Smart Engineers Write Bad Code by Adam Barr, and it’s also made a strong impact on me. It’s about the experiences that we, as software engineers, all have. Barr writes about the difficulty with software and why it’s hard, and the ways to deal with the complexity of making software. It’s a little bit less technical than Clean Code and more anecdotal on why writing software is hard.

The last one is more specific to my role as an Android developer. Most of my experience in the past five years has been in Android development. There’s a book named Kotlin in Action by Dmitry Jemerov and Svetlana Isakova, from Manning. The Manning books are fantastic. Kotlin in Action was one of the first books available for learning how to program in Kotlin. But I mention it because it’s such a well-written book. I think one of the best technical books I’ve ever read. The two authors are from JetBrains, the company that created the Kotlin language. It definitely assumes that you’re a developer and that you are probably coming from a Java background. It’s probably not a book I would read if I were starting from scratch as a developer on Android.

Having gone through that book, I felt that I suddenly knew how to program in Kotlin; not all technical books give you that feeling. With some, you feel that when you’re done, well, you’ve learned a little bit about the topic. But this book covers almost everything in the Kotlin language and it was unbelievably efficient. It’s just an amazing book and I love it so much. I’d recommend it to any experienced Android developer who’s looking to pick up Kotlin for sure.

Joe’s Recommendations

  • Can’t Hurt Me: Master Your Mind and Defy the Odds | David Goggins
  • The Meaning of Happiness: The Quest for Freedom of the Spirit in Modern Psychology and the Wisdom of the East | Alan Watts
  • 12 Rules for Life: An Antidote to Chaos | Jordan B. Peterson