跳转至

34 An Interview with Ray Wenderlich

Ray is part of a great team — the raywenderlich.com team, a group of over 200 developers and editors from across the world. He and the rest of the team are passionate both about making apps and teaching others the techniques to make them. When Ray’s not programming, he’s probably playing video games, role playing games, or board games.

Ray WenderlichRay Wenderlich

Connect with Ray

Twitter: @RayFromVA LinkedIn: /in/raywenderlich Facebook: /raywenderlich

Interview

Ray, we would love to hear more about your story. How do you move from writing articles as an indie developer into founding a company with over 200 elite developers and editors? Was there any common pattern along your way in this process?

Before I started as an indie iOS developer, I was working at Electronic Arts on the back-end tools for a game called Warhammer Online. I absolutely loved the job and the people there. But the thing was: I had always wanted to start my own business. And when I got married to my wife Vicki in 2010, I realized if I ever wanted to start my own business, now was the time—before any major responsibilities (like kids) might make it a lot more difficult!

So I decided to quit my job and become an indie iOS developer. I spent a couple of weeks reading books and learning, then started making my own apps. I did the programming, and Vicki did the art. At first, we weren’t earning much money through our apps, but after about a year we were earning enough to pay our bills. While I was creating apps, I was writing tutorials on what I was learning on my website, raywenderlich.com. I didn’t think much of it at the time—it was something I was doing just for fun. The tutorials became popular, and eventually became too much work to do on my own. So I recruited a team of awesome authors, and we wrote tutorials together and became known as the Tutorial Team.

After a while, someone on the Tutorial Team suggested we write a book together. We did, and the book was very popular—so the next year we wrote another. We continued doing this, and eventually the books did so well that Vicki and I decided to focus on the web site full time. Since then, the site and the team have continued to grow, and we are now a team of 200 authors and editors from around the world who team up and create high-quality tutorials, books, and video courses, currently focused on iOS, Android, Unity, and Server Side Swift.

How does your team create an article or tutorial that provides value to the potential readers?

It definitely takes a lot of care to craft a great tutorial. The goal is to make the tutorial fun and easy to understand, and for the instructions to 100% work. The way I see it is developers are busy people with a very limited amount of learning time. If a busy developer trusts you with their limited time, you don’t want to let them down!

In order to reach this high-quality standard every time, we have a guide of tips and tricks we’ve learned over the years creating tutorials, that all of our tutorial authors follow. For example, we have a rule called, “Build and run, build and run.” This means each instruction section should end with a command for the reader to build and run so they can check their work as they go, just like you would normally while programming. That prevents you from a terrible situation where you follow along pages and pages of a tutorial, only to realize you typed a line wrong somewhere, and have no clue where!

In addition, every tutorial on our site goes through three rounds of editing: a tech edit, an English language edit, and a final check by a senior member of our team. That way, we can be sure that every tutorial that goes out is amazing!

We see a rampant term in our industry: ageism. Elders seem to move into management positions or disappear from technical careers. Is there any life after 40? How can we keep ourselves updated and staying technical as we age?

I think part of this is natural. As you become more senior in your field, you also become more experienced and knowledgeable, and those are desirable traits for a leader to have. That’s why there is often pressure for developers to progress from an individual contributor to a team lead to a manager and onwards.

For some people, that’s great and a valid career path. I think the challenge, though, is sometimes developers feel like this is the only way they can progress in their career. However, that’s not true: There is definitely tremendous value in super-experienced individual contributors, and having developers on your team who have been through the “school of hard knocks” for many years, in many technologies, is incredibly valuable. If your company doesn’t recognize that, find another that does.

I think the first step is you need to decide what is best for you personally: Do you want to advance to management positions, or are you happier staying as an individual contributor? And then stay firm with your choice, even if you may get pressure in the opposite direction. If you live your life according to your values, you’ll be happier for it.

For those entering the industry for the first time, there are very strong opinions of how to conduct interviews: whiteboarding, homework, pair programming. Which system do you find ineffective?

At Razeware, we use the following interview process for all positions (whether technical or not). This is optimized for speed of hiring, and it works well with a small team (we’re only 15 full-time people) in a remote environment (we’re 100% remote).

First, we use resume screening. I look through the resumes and weed out anyone I think isn’t a good fit for the job. I try to give folks the benefit of the doubt at this point and keep a wide net at this stage.

Next, we do a video interview. I send them a short seven-minute video about our company, the job, and the interview process. This allows me to give more people a chance than I would if I were to schedule interviews with each person at this stage.

We then provide a challenge. At the end of the video, I give them a short challenge that should be able to be completed in a half hour or less, and it is related to something they will do on the job. Once they are past this stage, we do a half-hour interview. This interview is mostly focused on culture and big-picture fit at this point. To better test their skills, we do a short paid contracting job. This is usually an eight-hour task that can be completed on evenings or weekends, and we pay hourly for the time—that way people are compensated even if we don’t offer the job. The job mimics real-world tasks they would do if they take the job, so is an excellent indicator to us if they’ll be successful here once they take the job—and shows them if they like the work!

Then, a final 1.5-hour interview for the top 1–3 candidates. We have a final interview where we go into much more detail on the person and their background. We send the offer to the best candidate at the end.

I prefer this method of interviewing because it closely mimics how our company works: we all work independently, remotely, and (mostly) asynchronously. We’ve had good success with it so far!

What would you recommend to an already experienced developer to keep progressing in the career?

Always keep learning. As an experienced developer, it’s sometimes tempting to settle into a rhythm and do things you’re already very familiar with. After all, who doesn’t like that feeling of expertise! But I think you’ll grow even further if you push yourself to always be learning something new—even if you have to go back to being a beginner again! Learn a new language, a new platform, a new architecture, how to be an effective manager—whatever you’re passionate about! Not only will this help your career, but I think you’ll find it a lot of fun, too.

You are mostly managing a team of international people. Some people might be interested in transitioning from a technical position into a managerial one. How can they reach this milestone; what would you recommend them?

The best way to become a leader is to demonstrate leadership—even if you aren’t in a leadership position already. For example, a few years back, someone applied to our tutorial team in an entry-level position: as a tech editor for videos. He always gave excellent feedback, he was prompt and responsive, an excellent communicator, and went above and beyond in helping the video courses he worked on stay on track and be as excellent as possible. Essentially, he was leading from within. He did so well that we promoted him to a final pass editor—that senior editor we have who does the final review on all of our tutorials. Again, he demonstrated his strong ability to meet deadlines, communicate well with his team, and went above and beyond to keep his projects running smoothly—and even helped out with areas outside of his responsibility! So we promoted him again, and I’m happy to say he is now our iOS team lead—Richard Critz—and is one of the best leaders I know.

So if you want to become a leader, be a leader now—in whatever role you already have. Take on extra responsibility, and show people you know how to get things done. If you have good leaders in your company, your efforts will be noticed and rewarded.

What is the biggest mistake you see junior developers making over and over again in their work? Why do you think they keep making this mistake?

As someone running a tutorial site, I see too many junior developers getting stuck in “tutorial purgatory.” They just read tutorial after tutorial, but are a bit afraid to go off and build something on their own. Tutorials are an incredibly helpful way to learn quickly, but every once in a while, it pays to take a break from tutorials, and try implementing what you’ve learned on your own. It may be hard at first, but that is how you learn.

By doing this, you’ll solidify the knowledge that you’ve learned in the tutorials through practical experience. Then you can come back to some more tutorials to learn even more, but now that you have some solid experience, the concepts will make even more sense. The tutorials and practice combination is a virtuous cycle.

What is the biggest obstacle, technical or personal, that you have had to overcome to get where you are today? How did you get past that obstacle?

By far, my biggest challenge so far has been identity. Throughout my life, my identity had always been as a software developer. That’s what I did and enjoyed doing. And I had this idea that managers were always “the people who did nothing,” while the developers did the “real work.” But as my company grew, I found myself doing less and less software development, and more and more management. So when I looked in the mirror expecting to see a software developer, and instead saw a manager, there was this mental dissonance that made me feel quite badly about myself. I faced a choice: I could either change my actions (stop being a manager and get back to programming), or I could change my identity (and think of myself as a manager/leader/entrepreneur). I obviously decided on the latter. And although it seems easy to just make that mental switch, it was still a struggle for me—and took many years to change the way I thought about myself. Luckily, it was mostly a matter of time for me, and I’m very happy with my current role!

What is your leadership philosophy? That is, what core principles and beliefs guide you when you are in a position of leadership or mentoring others?

Follow the Golden Rule. Care about your people and treat them the way you would like to be treated. If you do that, everything else works itself out. The most important part of any company is your team, so nurture them with care.

What are the best apps or tools that you just can’t live without? This could be in your personal or professional life.

For project management, we use Trello, which is a lightweight tool that can be easily used to manage multi-stage group projects. We use it to manage the process by which we create tutorials, books, and videos.

For documentation, we make heavy use of Confluence, which is a wiki-like tool by the creators of Jira. As our company grows, it is important to have a central place to store links to all the information we create. This way, we can have a “one-stop shop” for all the information we have as a company. For project plans, we designate a person who takes the lead and creates a proposal in Google Docs, then sends it to the rest of the team for asynchronous comments and review.

For my personal notes, I use Evernote, which is a tool to write notes and sync them across multiple devices, quite heavily. For example, I have kept notes on every video chat I’ve had for the past 10 years in Evernote, which is incredibly helpful when I forget a conversation I had a few months ago. I also use it for TODOs and other notes I need to keep for future reference.

Although we prefer asynchronous communication as a remote team, sometimes we need to talk to each other instantly, and we use Slack for that.

“It’s critical to give yourself permission to take breaks when necessary to recharge your batteries—again this isn’t weakness, but is normal and essential.”

What is something you have learned “the hard way” in your career, that you wish you’d known 10 years ago?

Know your limits. Jobs can be demanding—especially for developers and leaders. There are times you’ll need to burn the midnight oil, but it’s essential to be aware of your own limits, and to understand what you can get done each day/week, in a sustainable way.

When you are an organized and responsible person at work, people will notice that you can get things done, and next thing you know they’ll throw more and more work at you. As a person who gets things done, you might have a temptation to keep saying yes, and keep working harder, doing more and more.

But part of being dependable is to understand your limits, and sometimes you may need to push back—even to your boss—and say, “I’d love to do this, but right now my plate is full. Can you help me prioritize these tasks so I can focus on what’s most important, or is there anyone else who can help with this?” This isn’t a sign of weakness; it’s actually a sign of strength, and you’ll gain even more respect for it.

In addition, it’s critical to give yourself permission to take breaks when necessary to recharge your batteries—again this isn’t weakness, but is normal and essential. Remember a career, or a business, is a marathon and not a sprint. It’s more important to have the energy to keep going day after day, than overdoing it and burning out. Burning out is real—I’ve been there many times. It took me a while to learn and accept my limits, and I hope you can find that perfect work/life balance in your life faster than I did.

Ray’s Recommendations