12 An Interview with Ash Furrow¶

Ash is a compassionate software developer from Canada. After working at Artsy for seven years, he now works for Shopify. His background is originally in native iOS apps, but nowadays he builds a lot of software in React Native. He has published a number of books, built many apps, and is a prolific contributor to open source software. On his blog, he writes about a range of topics, from interesting programming to explorations of analogue music and the humanities.

Ash Furrow

Connect with Ash¶

Twitter: @ashfurrow Website: ashfurrow.com GitHub: github.com/ashfurrow

Interview¶

You’re a renaissance man. You’ve become an expert in many different technologies, defying the traditionally held idea that a developer should master a single technology. Was this an intentional strategy on your part?¶

I wanted to increase the scale of my impact at Artsy, and iOS is only a small part of Artsy’s technology stack. To have a bigger impact on that stack, I had to learn new technologies. This was the motivating factor. My desire was very intentional, but how I went about it was very organic. I happened to be working on a team that was building something with Scala, so I learned Scala. And then the team happened to be building something in JavaScript, so I learned JavaScript and React.

For beginners, I recommend focusing on a single technology. The problem is that people continue to focus on one thing for a very long time. Once they have achieved a certain level of depth, developers should start to branch out. There’s no right answer about when it’s best to branch out, but I think most developers wait too long. The longer you wait to branch out, the more difficult it is to learn new technologies. For beginners, learning how to program is already so overwhelming that focusing on a specific language or a specific framework is a good idea. Once they’re feeling confident, I like to encourage them to branch out into related technologies. For example, if they’ve learned a lot of Swift, they could learn Objective-C. It doesn’t need to be something entirely different. They don’t need to jump from Swift to some unrelated language, like Scala, or Ruby even. Start with something related to what they already know.

Is there any factor developers seeking to branch out should consider when they’re trying to choose a new technology to learn? How might the answer be different or similar for junior and senior developers?¶

It depends on what their motivation is. If they want to learn something purely because they enjoy learning and it’s a hobby, then they should pick whatever is the most appealing to them. If they’re working in a team, then they should ask themselves, “What does the team need me to learn?” Ideally, you’d list what the team needs and what you want, and then find out where they overlap. That’s where you should focus your attention.

“Not everyone is a skilled writer, but that’s okay. The writing isn’t the important part. It’s the sharing knowledge that’s important.”

You’re also a prolific writer and have published several books. What’s the biggest lesson you learned from writing your books? Would you recommend other developers follow in your footsteps?

Writing books is something I eventually did, but writing is something that I did from the very beginning. When I started learning how to write iOS apps, called iPhone apps at the time, I started a blog. I would write about the things that I learned like how to use NSArray. Through the process of writing about them and teaching others, I learned so much more about those technologies. That’s something I encourage everyone to do. Not everyone is a skilled writer, but that’s okay. The writing isn’t the important part. It’s the sharing knowledge that’s important.

To get started, organize a weekly lunch and learn where people share the things that they’ve learned over the past week with each other. Get in the habit of teaching others something new. I think that’s a great way to start building your presentation skills. Maybe you want to write a blog, or maybe you want to present to a meetup or at a conference. I think that sharing knowledge is important, and writing is the way I happen to do that. Everyone can contribute to knowledge sharing. You don’t have to be a skilled writer.

For instance, some developers might prefer to make open-source contributions or YouTube tutorials. Right?

Exactly. For instance, I held weekly office hours at Artsy where I invited people to come and work on knowledge sharing. If they wanted to write a blog post, I helped them write a blog post. If they wanted to present at a meetup, I helped them do their outline and their slide designs. If they wanted to start a podcast, I helped them learn how to edit audio. There are several ways to share knowledge, and I encouraged people to try something new and keep at it. Initial failure is to be expected. That’s okay.

What resources have had a lasting impact on how you work?

The first book I would recommend is Buckminster Fuller’s Operating Manual for Spaceship Earth. This was written decades ago, so it’s not about computer programming specifically, but it’s about thinking in terms of systems that interact with each other and thinking about large scale ideas and concepts. That framework for thinking about things at a high level has helped me as a software developer to think about software architecture and to build software on a team. I don’t work as an individual, I work as a team member, so thinking about the team as a system has helped me not just to be productive personally, but to help my colleagues be productive, which I think is more important.

The second resource I’d recommend is a podcast called Pessimists Archive with Jason Feifer. It looks throughout history at newspaper articles and other artifacts. It focuses on new technologies that seemed scary at the time, but that now we take for granted. One example is the introduction of the bicycle, which society initially feared. Another example is the subway. In the U.S., people were afraid of being underground, and so it took a long time to get subway construction started. There’s such a variety of technologies throughout history that we’ve been afraid of. Sometimes, those fears are valid. Looking at how people have historically reacted to technology has influenced how I look at the technology I’m building today.

The third resource I’d recommend is a book called Awakening Compassion at Work: The Quiet Power That Elevates People and Organizations by Monica C. Worline and Jane E. Dutton. Again, this is not a programming book, but it’s a book about how to foster compassion in teams. This has been important for me as an engineer because, again, I work on a team with other people, and the product of the team is influenced directly by the quality of our team and how we work together. A book about compassion and how to be compassionate in the workplace is a great resource for software engineers.

What concerns you about the industry?

The way software developers categorize ourselves is unhealthy. People who call themselves iOS developers or Android developers or JavaScript developers are putting themselves in a box with a label on it. I would prefer that engineers look at themselves as people who solve problems, and they just happen to solve problems with iOS, for example. We shouldn’t define ourselves based on the technology that we use to solve problems, because then if we see a problem that can’t be solved with our technology, we won’t try to solve it.

How would you recommend junior or beginning developers boost their careers?

When you’re starting, it’s very difficult to stay motivated because there’s so much to learn. I recommend people find others who are learning and learn together. This can help you stay motivated and also help you answer questions. More importantly, when you’re learning how to build software, pick something that you want to build yourself. I’ll speak from my personal experience.

My first iOS app was a very basic app that helped you make coffee. I wanted an app to help me make coffee, and through building my own, I learned the discipline of app building. That intrinsic motivation kept me focused on the difficulties of learning how to write iPhone apps.

What is something you wish someone had told you when you started working as a software developer that you had to learn the hard way?

I wish someone had told me to be more assertive with my bosses. The first two jobs I had after university weren’t great, and I stayed at both of them longer than I should have because I was afraid of disappointing my bosses. Eventually, I did leave, and I felt better because I didn’t want to work at a place that didn’t respect me. It was also better for them because they no longer had an employee who was unhappy and unmotivated, and they could hire someone else who was a better fit.

You’ve also contributed to a lot of open-source code. How do developers get started doing that?

There are a lot of ways to contribute to open source. I encourage people to open issues on projects they use. If they find a bug or have a feature request or suggestion, they should open an issue about it. That’s a good way to start contributing—to let the project maintainers know that you’re using the project, you like the project, and what you’d like to see out of the project.

Other ways to contribute include updating READMEs or documentation and fixing typos. These are all valuable things that help other people use and contribute to a project. I tell people not to focus on the code aspect of contributing to open source, but to focus on a project itself. How is it organized? How is it documented?

There’s also the idea of building something yourself. I’d like to see more engineers open source their side projects. If they have an app on the app store, open source it, because it’s a great way to get feedback from other developers about how you’ve implemented things. It’s also a great way to give back to the community as other people can learn from your experience.

As junior and senior software developers, how do we keep improving? What should we do to avoid career paralysis?

Many engineers focus on the depth of their technical experience rather than focusing on the impact that they can have on their teams and on the business they work for. I’d encourage people to look at where they like to work in the technology stack that they work in. If they prefer front-end or back-end or somewhere in the middle, find that spot and then look for opportunities to increase your impact at that level.

If you’re a front-end engineer, you might look for better ways to write user interface code, or you might look for ways to help your colleagues write better interface code. Focusing on advancement in your existing work environment prevents the disappointment that comes from learning a complicated technical skill and then not having anywhere to apply it.

Besides all your community contributions such as articles, books, and open source, you’ve been contributing to the offline community in New York and doing some volunteering. Do developers have an obligation to volunteer?

Volunteering has benefits, but I don’t think it’s an obligation. Not everyone can contribute outside of work. There are people with families and other time commitments that leave them unable to contribute in this way. I think it’s something that should be encouraged and celebrated, but I don’t think it’s something that should be required.

How do you stay highly productive in your work for long periods?

I find it difficult to find long stretches of time to be productive because I have a lot of meetings and responsibilities outside of coding. Some people will block off long periods on their calendar to work, and I find that unhelpful because it sort of divides my time, and I find it difficult to switch between tasks. Instead, I’ve tried to get better at being productive in short bursts of time. It’s difficult to do, but it’s worthwhile. If I have ten minutes before a meeting, being able to contribute a request that helps out a colleague or fixes a bug in a very short amount of time is more valuable to me than finding four hours in the afternoon to be productive alone.

There’s a theory that developers should work for one or two hours uninterrupted because it takes at least thirty minutes to get into the flow of work. Do you think that this is true?

I think working for long periods is fun, but it’s not always the most productive. If you’re working on a problem for four hours and it turns out that the problem isn’t what you thought, or you weren’t solving the correct problem, then you run the risk of having wasted those four hours. On the other hand, if you take 15 minutes to build a quick prototype and then ask for input from others, or if you take five minutes to talk to your designer and your product manager about what exactly you’re building, you can spend more time focusing on building the right thing. I encourage people to explore how they work best and how their minds work best and to set up habits and routines to support that.

How does remote work fit into your workflow?

In the past, I found remote work isolating, but I may be in a better position to work remotely now. I have some fully remote colleagues, and they enjoy it. They take steps to make sure that they have opportunities for socialization with other members of the team and that they’re able to get outside and get some fresh air. They set up habits to help them be happy and productive as remote workers. Remote work takes effort. It’s not just working outside of the office.

Ash’s Recommendations¶

Operating Manual for Spaceship Earth | Buckminster Fuller
The Pessimists Archive podcast | Jason Feifer
Awakening Compassion at Work | Jane E. Dutton and Monica C. Worline