From Zero to the Ray Wenderlich Team - in 3 Years

It's safe to say I was a late starter with software development. At high school, I had very little interest in software. Later, in college, I chose to enroll in electrical engineering over computer science. I started to code as a hobby during my college years, and came across iOS v 5.1 when I bought my first iPad. I got most of my coding knowledge from online tutorials like RayWenderlich.com - which is one of the most popular iOS tutorial sites. Over the years, I've dived deeper and deeper into the iOS world. And three years later I not only read these tutorials but also write them: I've been accepted to the  Ray Wenderlich authors team.

It wasn't easy making it all this way. As I have since found out, writing a tutorial is really challenging. However, it is also extremely rewarding both in a professional and personal way. And of course the feeling of working together with the people who've taught me all I know about iOS - that is incredible.

But let's not get ahead of ourselves. Let's get back to what "zero" meant, and how I went from there.

From zero to software developer

My smartphone was the reason I started coding. In 2012 I had an Android phone (running version 2.2 at the time), and I started to create really simple apps for it. I installed Eclipse (back then there was no Android Studio :) ), and I started to get familiar with how mobile development works. Next stop was a third generation iPad, which is where my ongoing interest for iOS started. The setup here was more complex. I needed to use Xcode, and to do so, run OS X. Back then I only had access to Windows, so I had to set up a virtual environment to do development in Xcode.

Initially, I did most of my learning from the Big Nerd Ranch books. Their Objective C programming book was the most useful one for me. Of course for those starting out today, I would recommend the Swift programming book - back then, however, Swift didn't yet exist.

While doing my college degree I started working as an intern at Lufthansa Systems. The internship focused heavily on hands-on learning: apart from the day to day tasks it also included trainings on soft and technical skills. As luck would have it, I got assigned to a mobile software development team. When I joined, I immediately got thrown in at the deep end. My the team was in the home stretch of a large international project and needed all hands on deck. Luckily there were a couple of really senior developers on the team, whom I learned a lot from, from day one.

Picking up a full-time hobby

Around this time, I started to have this feeling, which surfaces again and again, to this day. The feeling of not knowing enough, and wanting to learn more. Of course, back then I was just starting off with software development, so I guess there isn't anything too surprising about this. But this feeling gave me the continuous motivation to learn more and catch up - not only while at work but at home, after work as well.

I remember very clearly the afternoon when I came home from work and decided that it's time for me to really dive deep into iOS. I made a list of all the resources I can use to learn more. I discovered NSHipster, objc.io and Mike Ash's blog.  I realized a lot of the iOS community is active on Twitter, so I also signed up, and to this date, I mostly use it to follow fellow developers. I also discovered a handful of great iOS newsletters, which I also subscribed to.

It was this time when I started to frequently read Ray Wenderlich. I immediately liked it because most articles and video tutorials were easy enough for a beginner like myself to follow. At the end of every tutorial, you learn something practical that you can immediately use. At the same time, the articles don't go into depths where a beginner would be hopelessly lost. This site was a really important tool for me learning the basics, like getting started with UITableViews or how to use Auto Layout. To this date, I still re-read some articles to refresh an area which I haven't used in a while.

After about two years of working as an iOS developer at Lufthansa Systems, I decided it was time for a new challenge, and I joined a new company, Misys. At the time of the switch, I also saw an open call for new authors on Ray Wenderlich. I wasn't sure I would have a realistic chance to get accepted as an author. At the same time, I was keen to find out, so I took a deep breath and applied. I sent a short description about myself and linked my GitHub profile. To my surprise, I got a response the very same day, and after passing a screening test, I became a member of the author team. The authors at Ray Wenderlich were the people I basically learned iOS development from. And now I belonged to them. This was an incredible feeling.

What is RayWenderlich.com

There are over a hundred contributors on the site. Apart from iOS, these tutorials often touch on Android, OS X, and game development. Along with written content, the site also offers great video tutorials. There are currently two Hungarian authors in the team: Attila Hegedus, and myself.

Anyone can apply as an author or editor, who has relevant experience in the technologies covered. To get accepted to the author team, one must complete a screening task. When I applied this meant fixing up an article that was not written well enough. These days, however, the screening task is slightly more complex: one must go through the complete process of publishing an article, including creating a demo app, the writing itself.

Writing an article: step by step

Topics are divided into a few major categories, like iOS, Android and Unity. Each category has a team lead. Team leads decide what topics are good candidates for articles and create assignments for these. Apart from these assignments, there's also a wishlist, where authors contribute topics they find interesting. As an author, one chooses from an assignment half the time, and the other half takes something from their wishlist. Once the topic is decided, it’s time to start writing the article.

The first part of writing a tutorial is creating the outline. There's a one-week time limit for this. The concept for the demo app also needs to be drafted in this period. For me, this was the most difficult thing during this phase. When writing about a new topic that I've not worked before, it’s hard to be certain of what can, and cannot be done as part of the demo app, so there’s definitely a lot of research involved in this phase.

The second part is creating the demo app itself. There's another week  for this task. There are a couple of important things that one needs to pay attention to when making the app. The coding style guide needs to be followed, and one should try to use the latest solutions and techniques in the domain. For example, all new articles should be written in Swift over Objective C, or that after UIStackView was released in iOS8, using this class where relevant was good practice - even if it's not available for iOS7. The demo app is reviewed along these lines, and also tested for functionality, code quality and readability.

When I wrote my first tutorial, in this phase one piece of feedback I received was that my app uses too much memory. It turned out that this was because I didn't handle assets correctly - and I promptly fixed this issue after this feedback. Small things like this show pretty well just how serious the reviewers take their task - which I found truly awesome.

After the demo app comes the difficult part: writing the actual article. The time limit is two weeks to finish the article itself. However, as most authors have a full-time job, this usually means much less time. The article needs to be written based on the draft and demo app. Steps to building the app need to be written in detail, with example code and pictures illustrating progress. Structure and clarity are really important. The ratio of text and code is something that one needs to pay attention to, as well as the clear and easy to follow instructions.

Once the article is complete, another three review rounds follow. First, the author receives a technical review, where reviewers check if the article is correct from the technical domain's side. Next, an editorial review is written, which analyzes the readability, grammar, and ease of understanding of the article. Based on these two, a final, summary review is produced of the article. All three reviewers rate the article: 1 for poor, 2 for average and 3 for exceptional quality.

Huge professional leap after writing one article

English is my second language and luckily I had the chance to learn it early on. I never had issues with making myself understood when talking to others. Based on this, I assumed this to be the case when writing an article as well. The feedback I received from my first article, however, was exactly the opposite. As it turns out, my sentences were difficult to understand, and some of them used incorrect grammar as well.

Of course, none of this should be new: I'm sure lots of people are familiar with the feeling when something just doesn't come together. For example, the feedback loop at university is something like this: you study, take an exam and get a grade. If the grade is good enough, you move on; if not, then you study more and retry. The same feedback loop repeats itself at many other parts of life. On one end, this kind of feedback is great, because you get to know if the time and energy invested was sufficient or not. However, this kind of "pass / no pass" feedback isn't particularly useful, as it doesn't help identify the blank spots, or give suggestions on how to learn a better way.

The Ray Wenderlich team, however, had a different, and much better feedback loop. Feedback here is much more than just a rating, or a one-line summary. I would often get multiple paragraphs of thoughts and advice on my articles. You can receive writing and grammar advice and technical help. The obvious goal of these reviews is to help you improve and learn. Previously I've gotten lots of feedback on my work, but in most cases it was not obvious what it would take to improve. However the feedback I received here made my weak spots crystal clear.

Just how much does quality feedback matter? My first article received a 2 for the technical review, and 1 for the editorial review. For the next article I wrote, I used the feedback I received from this first one to improve my writing style. And progress was very visible: I got 3, the exceptional review rating for all three categories. For me, this was the first time I experienced that constructive and actionable feedback like this exists, and that it makes learning and improving a much faster process.

Is it worth it?

I won't lie: writing a tutorial like this means investing lots of time and effort. I was given my JavaScriptCore assignment, without having worked with JavaScript before. I invested my time during a flight to get familiar with a language, and then I created a basic web page to play around with what I can do with code sharing. All of this was around Christmas, which meant sacrificing quite some time from my holiday.

However, if you're willing to sacrifice some of your free time, there are lots of benefits to this. From a professional standpoint, you get to learn lots of new things. For both my articles I wrote about topics that I was unfamiliar with before. Had I not written the articles, I would probably not know too much about those areas today. Apart from the professional development, I felt that I developed a lot in a personal sense: for example on how to receive and give efficient feedback, or how to communicate in clearer way.

Another benefit I see is that by writing a tutorial like this, I added something to the community knowledge base. I have a lot to thank the iOS community for - and by writing these tutorials, I finally have a way to give back. Also, ever since I joined the author team, I’ve been more active  in the developer community. I find myself working more on open source projects. Apart from sharing code I write, I try to contribute to other projects. This could be as simple as asking questions by opening issues, or submitting pull requests. Before, I shied away from these things, as I worried that I didn't know enough to contribute. Today, however I see it differently: software development is not only about writing code - the community part is just as important. The questions I have when reading someone else's code is something that others will probably have. And my solutions to some of these questions can later help others, who are stuck on the same problem.

Overall I believe that even though I invested lots of time, it was all very much worth it. I learned a ton and my writing style leveled up. And the articles that I produced as the result of this are resources that others can use to learn more.

(As the stories on this blog are  mostly told by Hungarian software engineers, all articles are also published in Hungarian. You can read the Hungarian version of this one here: Nulláról a világ legnagyobb iOS oktató oldalának a szerzői csapatába - három év alatt)

A kommenteket a Disqus jeleníti meg