Building With Ember.js

Plus advice for Full Stack Developers And More With Allen Cheung, Engineering Manager At Square

Allen Cheung is an Engineering Manager at Square. He and his team developed Square Analytics, one of the largest Ember apps in production at Square. Allen confessed on Quora that he shares some of the “blame” for the decision to use Ember.js.

The Square card reader in action. Square was founded by Jim McKelvey andJack Dorsey in 2009. Jack previously founded Twitter.

Can you please describe your path to what you’re doing now?

I started my career as a QA Engineer for a financial software company. It was a few years after the dotcom bust, and those of us who were adamant on entering the software industry were lucky to find any jobs available, especially entry-level engineering jobs. I eventually jumped around a few startups in Silicon Valley, hung out at Google for a year, then landed at Square, where I am today.

At Square, my career evolved from front-end engineer, to tech lead, to engineering manager. Front-end engineering has always been interesting to me, and I got started in the field way before it was popular to build well-crafted web sites and apps. My claim to fame is working myself through the dark ages of IE6 compatibility.

We heard you’re running one of the largest Ember apps in production at Square. Why did you choose Ember in the first place?

We started on the single-page app route quite a few years ago, when Backbone was the main choice for complex web applications. Ember wasn’t called Ember back then; it was Sproutcore 2.0 beta, an open source sequel to Sproutcore 1.x which was the framework Apple used for its iWorks web apps.

Square Dashboard, the product that Allen helped build.

I think a lot of what attracted us to Ember in its early days was its out-of-the-box two-way binding support, and how easy it’d be to drop Ember in and out of a HTML page (e.g., it didn’t want to take over the entire page). Of course, over time Ember’s philosophy has changed and it is now providing much more tooling to make running Ember easy, but we have been comfortable with Ember for so long that it hasn’t made sense to move away from the framework.

How did everyone in your team get up to speed with Ember?

We were lucky, in that we knew some of Ember’s core contributors, and they were generous enough to get us off the ground and running within a few days of looking at our main Rails repo. When we first sat down to pair program, I was complaining about how the docs didn’t seem to line up with the source code we were grepping over, only to be told that the latest docs had to be compiled from a working repo that hadn’t been public yet. Documentation in the early days was definitely a work in progress.

Our front-end team simply got comfortable with the framework over time with increasingly bigger projects. Pair programming and code reviews also helped (and still helps) reinforce best practices and technical knowledge transfers.

Ember went through a few radical changes ever since you started using it in 2012. How did you guys manage the process of migrating your code for compatibility with the newest versions of Ember?

Honestly, Ember 1.0 broke us. There have been others who’ve managed to get from pre-1.0 to 1.0 with some elbow grease, but we decided to rewrite the app when we hit that milestone. Fortunately, since then the subsequent point upgrades have been easy, by design, and we’re looking forward to Ember 2.0 and the core team’s plans to upgrade apps to that point.

How do you split the work among team members? How granular is a typical task for a team member (for example: implement a full Ember component, or a route)? Does anyone solve both backend and frontend tasks at the same time?

We’re product and feature-focused, and so our tasks are typically scoped around user-facing stories. “Build a page” is a better task to be assigned to an individual compared to a component; if the latter is built, it’d be in service of the former.

As to back-end and front-end work, it really depends on the disposition of the individual and the complexity of the back-end systems. Sometimes it makes sense for the same engineer to do both: e.g., adding an API endpoint in a Rails app to be consumed by the Ember app. Other times, building out the back-end for a feature involves multiple complex systems, and while people can probably figure it out given enough time, there’s a clear division of labor and we can parallelize the work.

What are other challenges of developing and running a large scale Ember app?

One of the challenges I’ve been dealing with, that most people don’t think about, is how to manage a large application. A codebase that’s worked on by one hacker becomes a different beast when there’s a team of 5 people checking in code, and wholly different again when there’s 20–30 active contributors. Failing tests affect more builds; deployments are a lot hairier; code reviews procedures are needed to accommodate the large variety of experience and skill. People rag on Java for being overly verbose and harboring too many levels of indirection, but it’s not too far off from what maintainable large codebases start to look and feel like.

Did you get any important benefits from Ember that you didn’t consider initially?

For us, the biggest unexpected benefit has been leveraging Ember’s framework conventions to just get work done. Of course, we didn’t consider this initially, as the framework was not as strongly opinionated as it is today. We see this as mostly a benefit; there are less debates about what to name things and where to place them, and the Ember docs make it easy enough to onboard new engineers to the framework. Building your own JS framework nowadays seems to be a rite of passage, but there’s some real benefits to standardizing on publicly known, easily accessible conventions and norms.

What are your thoughts on frontend-first vs backend-first? How do you do it in your team? Why?

I may be a bit biased here, but I like the idea of front-end first development when that’s possible. For most features that aren’t constrained by back-end limitations (e.g., expensive database queries), having the front end completed to design usually means that all that’s required is hooking up APIs on the back end, with much of the design iteration completed without wasting time building back end support for features that would never be released. This approach also forces the front-end team to properly define APIs and mock out test data, which will eventually pay dividends in testing and future development.

How do you learn new things? Do you attend conferences, learn through building products at your job or work on your own projects outside your job?

I used to attend conferences, but the last few years have seen lectures opened up online and broadcast widely, so I don’t find those as useful anymore outside of networking with folks.

I’ve learned a ton from my talented colleagues at Square, and I continue to discover new things simply by working with some really smart people who know a lot more than I do about all aspects of software development. Whenever possible, don’t be the smartest person in the room, or the best engineer at a company.

What are the things you did in your early days as a developer that were most beneficial for your career? (school, side projects, getting a job early etc.)

I’d be lying if I didn’t say that getting a computer science degree from a good school doesn’t help; unfortunately, with little work experience, companies end up looking at school and degree (and usually GPA, despite Google’s insistence that it doesn’t matter) to filter candidates, and getting into a software-focused firm with good engineering practices is hugely beneficial in setting the right direction early in a career.

In my case, working on my own blog engine turned out to be key in breaking into web development. I still recommend this sometimes, but I doubt it’d get the same results in 2014 as it did back in 2004; web technologies were much less understood and mature than they are today. What does apply, though, is the idea of working on side projects using technologies that are new and unfamiliar, and develop expertise before it becomes commonplace.

In what types of environments do full stack devs thrive and in what environments do they not?

It’s cliche, but full stack developers work well in startups, where they have comparatively more responsibility and are expected to deliver on products and features, irrespective of the tech stacks involved. Building the UI, the API, the business model, and the database layers without having multiple people work on these parts is a huge efficiency gain, and there may be insights full stack devs gleam from understanding all aspects of the stack that would be hard to tease out across a larger team of devs.

Conversely, full stack devs suffer in any environment that prefers or demands specialization. If you have to build UI prototypes all day or write Ruby extensions in C, there’s just little opportunity to exercise your full stack abilities, and you won’t be as good as those who’ve spent their careers working in that field.

That last point bears repeating: learning a whole bunch of technologies is a tradeoff that full stack devs make, with the opportunity cost being the lack concentration in one specific area. The strength of full stack development comes from the integration of all its constituent parts, but you’ll likely find devs who’ve specialized in a language or area be better in that environment. The upside is that you can level yourself up by learning from these experts.

Do you have any advice to share with full stack developers that are early in their career?

The generic advice given to people new to our industry is usually to not be afraid to learn. Focus on trying to understand what you don’t know, and you’ll eventually figure out the details; bet on potential and not pre-existing knowledge.

Understanding what to learn and when to focus on learning are equally important. We all have finite time and energy, and it’s challenging to learn and keep up with new developments especially when you’re trying to be productive. Getting that sense of which technologies you should learn, what methodologies to follow or ignore, and when to dig deep into an issue versus routing around it, is more art than science. As full stack developers, honing this skill will pay dividends for the rest of your careers.

Written by Octav Druta. A version of this post first appeared on the Talentbuddy blog. Talentbuddy is the simplest way to learn full stack web development with Javascript. The program is focused on teaching the unique challenges of building real-time web applications with fast-growing technologies (Javascript, Ember.js, Node.js, Express.js, MongoDB) Find out more.