17 An Interview with Joe Birch¶

Joe is an Android Engineer and Google Developer Expert for Android Assistant, Flutter and Google Pay based in Brighton, UK working on the Android team at Buffer. Passionate about engineering, he loves to create robust, polished and exciting projects for mobile and beyond—in fact, he’ll probably be toying with whatever the new thing is at the time you’re reading this! Joe is also a prolific public speaker and keen writer, he loves to share his learnings and experiences with others wherever he can.

Joe Birch

Connect with Joe¶

Twitter: @hitherejoe LinkedIn: in/joe-birch-80392157 Medium: @hitherejoe

Interview¶

You’re tremendously prolific when it comes to writing articles. How do you manage to write articles with this frequency? Are there any tips that you would like to give to potential writers to achieve the sort of productivity you have?¶

I often start a draft on my blog based on something I’m doing at work. Even if it’s just a little writing or a few notes, I start something. I go back later in the day or a few weeks later and finish the article. The list of articles I’ve started drafting on my blog contains ideas that are three or five months old that I haven’t gotten around to working on, or things I started but wasn’t in the mood to finish. I always come back to those things. My style is to make notes and start drafts and add things and then I come back to articles when I feel like I’m in the mood. This process keeps me going and provides a regular cycle of subjects to write about.

So I can imagine your drafts list is probably half-full with articles that have not been finished yet?¶

There are some that just have the title, and maybe I’ll finish, but maybe I won’t. Some are halfway written. I try to do at least one article a week, and sometimes I manage a couple. I feel that it’s good to get into that habit of sharing ideas often and in the open.

I prioritize getting things out there and focusing on what I think will be useful for people. Of course, I want to make sure what I contribute works properly, with regard to open-source code. When it comes to writing, I do a quick proofread, but I like just putting things out there once they’re done. Sometimes I’ll go back and change things around. Most of the time, I feel like they’re good enough for people to learn something from.

Another topic where I feel you are an authority is in remote work. You work at Buffer, which is a remote company. You’re the founder of the Remote Dev podcast about remote work. What were the main challenges you’ve faced in getting the podcast off the ground?

The first thing we found difficult was finding the first guest. As well, we weren’t sure how it would be structured or what the approach should be. Another challenge was our lack of experience with recording and mixing. How do we make sure everyone’s recording? How do you get it in sync? There’s a lot to learn. We’ve gotten the hang of it now, but it was a lot more difficult than we thought it would be. We thought it would be just as simple as hitting record.

Buffer, where you work, is entirely based on remote work. What’s a regular day like for you at Buffer?

Yes, we’re one-hundred percent remote and we have nearly 90 people working for us worldwide. As you might imagine, we’re all in a range of time zones. The Android and iOS teams are small, and we also have a mobile engineering manager, as well as a designer. My Android team member works on a six-hour time difference from me, so I work alone through the mornings. There are a few advocacy team members who I might communicate with during the morning, but generally, this is the time of day when I get deeply into the work.

I tend to start quite early. I start at about eight o’clock in the morning, and then take lunch at noon. I do that because it gives me a two-hour lunch break. In that time, I do my own things, like maybe a bit of writing or open source work. I started doing that over the last few months and it helped to switch off a bit from work.

In the afternoons, almost half the company comes online. At that point, things start to pick up a bit more, and I have my calls and team syncs. We don’t really do pair programming. Once a week we have strategy syncs with the team leads to discuss any ongoing issues.

I switch off at five, so it’s a normal work day. I think most people are surprised by this. Honestly, I work the same schedule remotely as I did on a non-remote basis, but with added flexibility.

What are three tools you use in your daily work to communicate with your peers remotely?

Slack is the Holy Grail. We use it for everything. We try and make sure everything is in Slack, so everything’s recorded and someone who comes online when you’re offline can see things that happened throughout the day.

We use Zoom for video calls. It’s great for one-on-one chats, but we also have our all-hands meetings in Zoom. It has two view modes, so you can view either the person who’s speaking, or you can view every camera for everyone who’s online.

A third tool we use at Buffer for remote work is Threads. Threads is a forum on which you can post a subject. You give it a description, and then people can comment on it and post images and hold a discussion. It has Slack integration. It’s helping to improve our asynchronous conversations.

What do you think of the recent trend of making salaries public? Are there advantages that this practice can provide to the company or the culture?

Knowing what people earn can increase trust. At Buffer, everyone knows what everyone earns. No one wonders whether someone working in the same role makes more money. As well, this policy is great for hiring because your salary is predetermined based on your location. If you apply for a job, you know what you’re going to be paid from the get-go. This transparency definitely brings a huge sense of trust to the team.

“I also like to give people the chance to be challenged, explore problems themselves and find their own solutions.”

What’s your leadership philosophy? What core principles and beliefs guide you when you are in a position of leadership?

I value honesty. Honest feedback allows for the chance to grow. And I do the same with people who I’ve mentored along the way. Trusting someone who’s helping you or someone you’re helping is essential. I also like to give people the chance to be challenged, explore problems themselves and find their own solutions.

Should all information be public in a company?

I think it should be. It’s good to know that whatever is going on, you’re going to know about it. At Buffer, we see all the emails and conversations between the CEO and the investors. That’s giving you the full context. Even when Buffer had previously made layoffs, there was full transparency around this topic during the time. There’s a peace of mind that comes when everyone is in the loop.

How do you manage your productivity when you’re programming? Is there any system that you particularly like and follow in order to be productive while you’re coding?

At the moment I don’t have any specific thing in place. I used to follow the Pomodoro technique, based on 25 minutes of work and interspersed with short breaks. I used to do that, but I kind of just grew out of the habit. When I stopped using the Pomodoro technique, I didn’t feel any less productive.

In the morning, I tend to do an hour of deep work, and then I’ll pop downstairs for ten minutes and just have a little break. That seems to give me enough time to focus and also refresh my mind. I tend to follow this throughout the day. An hour of heads down concentration, followed by a short break or stretch to give me that moment to refresh.

What do you wish that someone had told you back when you started your career in software development that you had to learn the hard way instead?

So this is to do with knowledge scope. I like to know a lot of things from a lot of different areas like technology. When I first started, I wanted to know everything. If I was working on Android, I wanted to know all the Android libraries. If it was machine learning or whatever, I researched these things. That’s how I approach things. It’s just taking anything on board and learning it.

And I think about a year before I left my last job, I was incredibly stressed and I was doing so much. I used to get home from work and I’d be writing open source code and reading up on things. I’d wake up the next morning and do writing before I went to work, and then it would just be a constant cycle of unending work. I was trying to know everything.

The truth is, you don’t need to know every part of your sector. You’re not going to use every part of the hundred frameworks and libraries that are available. I definitely learned that the hard way when I realized how stressed I was becoming and how it was affecting my life. I had a three week holiday and did some traveling. When I came back, I changed things around a bit because I saw how my workflow was affecting me, and I realized that it just wasn’t worth that stress.

What books would you recommend to someone getting started in the industry?

First, The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. I’m due to read it again. I read it every so often just because it’s just a nice refresher and it’s got some advice that could definitely help refresh your mind and shape the way you do things. A book called Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma and Richard Helm helped me understand what I was learning at university. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin is really refreshing and helps to define how to approach coding.

Are there any negative trends you’ve noticed in the industry, and how would you fix them?

Flexible work hours are important for remote workers and can significantly impact employee satisfaction. In one of my previous roles, we had a typical workplace with a ping pong table and games and stuff, but we had inflexible work hours. Really, I just want to be at home for an hour in the morning to get a package, or to leave work an hour early or so.

How do you see the future of remote working?

I think it’s definitely getting more popular. I think in the U.S. it’s going to continue to grow. But I’d love to see it more in the U.K. It’s definitely not as popular over here as it is in the States. It’s a step in the right direction.

What are the first steps a company should take in order to implement remote work?

Try and cultivate a culture in which everyone is included. For example, if you have a meeting, be sure to remember about the remote workers. It’s definitely important to get that right from the start.

There’s been a lot of controversy over hiring practices. From your point of view, what ensures a fair hiring process?

I don’t feel algorithms are a good way of measuring someone. I used to be a fan of take-home exercises, but you’ve got to be respectful of people’s time. It can’t be too time-consuming because people will spend as long as they can to get the job. Time is expensive. If onboarding takes a few days, you then have to expect people to be able to take a few days off work. I think that’s a great way of making sure that people are right for the company because then you can get a feel for what it’s like working with them.

I think pair-programming sessions are the way to go. Having a coding task or even better, a ticket in Jira or a small feature that you need to build and having a pair-programming session with the interview candidate. That way, they’re working in your code base, and they’re fixing a real problem representative of what their job would be. The task should be something that gives you an impression of what it would be like to work with them. That’s a good way of determining whether someone’s a good fit.

Joe’s Recommendations¶

The Pragmatic Programmer: From Journeyman to Master | Andrew Hunt and David Thomas
Design Patterns: Elements of Reusable Object-Oriented Software | Erich Gamma and Richard Helm
The Effective Engineer: How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact | Edmond Lau