Bringing Job Spotter to iOS: Indeed’s First React Native App

In 2013, Facebook released ReactJS and changed the way a lot of people (including us) think about web development. In 2015, Facebook released React Native, allowing developers to create powerful native mobile experiences using JavaScript and React. When we planned to bring the Job Spotter app to iOS, we were hopeful that React Native would live up to its promise.

Spoiler alert: it did.

Intro to React and React Native

React is a different way of thinking about web development. Instead of separating code by function, React encourages separating code by components. Each component contains all the layout, styling and business logic it needs – often in the same file.

React’s other important feature is one-way data flow. Compared to the two-way flow implied by other frameworks, it is much easier to figure out how state changes affect the app in React. One-way data flow also enables powerful libraries like Redux.

React Native lets you write JavaScript for Android or iOS apps with React that deliver native performance. Web developers can write powerful native apps, without needing to spend time learning unfamiliar native mobile development technologies.

Wins

React Native helped us speed up our mobile development cycle. Using out-of-the-box tools, we can run our React Native app locally in the iOS simulator. That allows us to refresh the app to test changes without recompilation, just like we would in the web. Even better, application state is maintained across these “hot reloads.” These development features of React Native translate into a big savings in time and effort, allowing us to focus on developing new features.

Since we could leverage our previous React knowledge, we didn’t have to learn a new language and could get straight into coding. This was especially great for our team, since none of us had used Objective-C or Swift. Another bonus was that, except for some custom event logging, we hardly had to write any native code.

Another interesting aspect of React Native is that it requires using inline-styles, in which CSS “classes” are actually JavaScript objects. This seemed strange at first, but we’ve grown to love it. Since we were dealing with objects, we could create powerful, composable, and extensible CSS classes and avoid a lot of style duplication seen in traditional webapps. We could develop different looks and functions as needed, rather than having to repurpose the same styles for different needs.

React Native makes heavy use of Flexbox, a newer CSS module that aims to make styling more consistent and straightforward. This removes the need to know many of the traditional quirks of CSS. After overcoming the learning curve, the more declarative approach of Flexbox allowed us to style new components more rapidly than in traditional CSS.

Debugging was also easier than we expected. We just connected to the debugger in the Chrome Developer Tools and debugged the same way we would on the web. React Native has several additional tools – the element inspector determines the styling applied to a component, and the network inspector analyzes the XHR requests your application makes. Being able to reuse familiar tools helped us track down and fix issues as they arose.

Challenges

React Native enabled us to develop more rapidly, but React Native itself developed just as fast. In the two months that we worked on the Job Spotter iOS app, React Native had six releases. After updating to each new release, we would have to do a full regression test of our app.

Another major and related challenge: React Native’s newness. A lot of capabilities that would be better as default features still required third-party libraries, such as accessing the camera and file system and handling permissions. The community works hard to pick up the slack of React Native core. However, these third-party libraries sometimes lacked the quality we expected from the core library. In fact, we had to patch more than one such library.

The components available for navigation and screen transitions were also inconsistent. We ran into an issue with the Navigator component in which every transition needed some kind of animation, with no option for an empty transition. This initially made some of our scene transitions look awkward. We tried using the NavigatorIOS component, but its interface was less friendly and straightforward, and lacked many of Navigator’s features.

Similarly the TabBarIOS component works quite well, but its transitions were completely independent of whatever Navigator we used. We wanted a single navigator handling everything. We had to use different code paths for supporting navigation when we would have liked one.

It’s worth it

Despite these challenges, we continue using React Native. It fits well in our toolbox. We can use our web development expertise to build rich mobile experiences without having to become Android or iOS experts. And as React Native matures, we expect many of these current issues to be resolved.

Our next step is porting the React Native version of Job Spotter to Android to replace our existing native Android app.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

IndeedEng Culture: Be Ambitious, Stay Humble

In my previous posts on Indeed’s engineering culture, I wrote about keeping teams independent, making better mistakes, dealing with consolidation debt, encouraging autonomy and initiative, and the importance of not stack ranking individuals. These are my closing thoughts on how we work here at Indeed.

Perhaps one of Indeed’s traits that has struck me the most is how individuals, including top engineers and managers, have stayed humble, although they have built this company from the ground up. Bragging and boasting are not behaviors I have seen at Indeed. As I met my colleagues, it seems like being right or wrong is overrated. Instead, we are all focused on doing the right thing. I was surprised how veterans had time and patience. At first I wondered what I did to deserve it. They were curious to hear my perspectives although I had not demonstrated anything yet.

It took me some time to understand why. Then I figured it out. Being data-driven and expecting initiative means there is always a practical and immediate way to settle a burning argument. If you really believe that feature X is what the business needs, you don’t need to convince an army of managers and directors. You don’t need to be resentful for failing to do so, or not even trying. Your credentials (almost) do not matter. The only thing you need to do is to design the experiment that will prove or disprove your theory, and ship it. And if you are not doing so, why are you talking?


Editor’s note: This post concludes our 5-year anniversary series highlighting some of the most important aspects of Indeed’s engineering culture. We want to thank James Dingle for sharing his perspective and reminding us why we love coming to work here every day. Want to join us? Learn more at http://indeed.jobs.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

IndeedEng Culture: Don’t Stack Rank

In this post, I stand unabashedly against stack ranking. Evaluate how employees perform, not how they compare. Is this really controversial?

people cogs

If you assign to teams or divisions a fixed budget for bonuses, promotions or stocks, you create de facto a zero-sum game. You need losers to have winners. From that point, you can make lengthy speeches about the importance of being on a team, you will see people nod at you silently, but immediately after your all-hands meeting, they will go on competing with each other.

“But competition is good, right?”

Not when it turns into sabotaging each other’s work, by action or inaction, consciously or not. Teams accomplish much more when they combine their efforts. It won’t happen if peers do not have a genuine interest in helping each other, but have more interest in watching each other fail.

“Everything in the company is budgeted, why not compensation?”

Every budget item has unknowns, including compensation. In a small company, the absolute numbers do not really matter. As the company gets bigger, statistics kick in, and compensation becomes predictable enough without requiring comparing individuals.

“If there is no fixed budget, managers will be too generous.”

After all, it is not their money, so why not give it away. But that would quickly lower the productivity and incentive.  

At Indeed, we don’t stack rank or fit to an expected distribution. We have a process that aligns performance reviews across teams and offices, so the company keeps the same definition of what “good”, “better”, “best”, and “not enough” means. No manager decides alone an individual’s evaluation, and there is no competition between teams. This review process is probably the fairest I have ever seen.

What’s next?

In the next post, I conclude my series on Indeed’s culture with thoughts on the most striking trait of individuals at Indeed.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone