Learning EmberJS at AuditBoard

Author: Jacob Beltran, Senior Engineer II

About a year and a half ago, I embarked on a new adventure. As someone who has spent well over a decade in the front-end engineering space, I’ve seen a lot of change. I’ve seen frameworks come and go, I’ve seen patterns and ideas come in and out of vogue. I’ve noticed our industry’s tendency toward the shiny and new thing of the week. When I spent some time interviewing and getting to know some of the good people at AuditBoard, I was presented with the challenge of quickly becoming proficient in a framework called EmberJS. Yes… that EmberJS.

My reaction upon hearing mention of EmberJS in 2023:

My background

Now, a little about how I’ve spent the past few years… Like many in the industry, I had spent my last several gigs in React land. I actually had first started using React way back in the `0.13.x` days. This was back when JavaScript native `class` support was barely coming around and `mixins` were still a thing. Functional components were still a couple years away, and hooks were not even a glimmer in the React core-team’s eye. Still, there was something interesting and exciting about React, and it wasn’t long before much of the industry felt the same way.

I went on to get to know React extremely well, building design systems and component libraries. I even wrote a (now largely obsolete) blog post about performance optimization for React in those days. I’ve seen the rise of functional components, the proliferation of hooks, the explosion of state management patterns and I’ve loved every step of the way. So why would someone like me decide to take a job working with a framework like Ember?

The simple answer is that it comes down to two basic ideas.

1. Good people make you better.

2. Interesting problems are framework-agnostic.

Let’s dig a little deeper into each of those ideas…

Good people make you better

The thing that struck me about my first interactions with AuditBoard was just how cool the people were. My interviews felt more like a conversation among friends and there was a kindness and genuineness about them. Now, I’ve worked with a lot of great people throughout my career, but it felt like there was something special here.

After joining AuditBoard and starting to get familiarized with Ember and its concepts, it became clear that my initial hunch was correct. Not only were the crew at AuditBoard immediately welcoming and helpful, but they made a point to take time out of their day to pair with me, sharing with me as much of their knowledge as I could absorb. They wanted to make sure that I knew it was okay to ask for help.

That bit about asking for help… I’ll admit, it’s not something that comes naturally to me. If you ask my wife, she’d probably say I’m “stubborn”. I prefer “determined”. I’m the kind of person who takes pride in going solo and being able to pick up every required piece of knowledge on my own. My background at a number of small, fast-paced startups, amplified this mindset of mine. So when I was being actively encouraged to ask for help, it felt a bit foreign at first.

I must say though, going against my own built-in tendencies proved to be both refreshing and immensely pragmatic. You see, the team here at AuditBoard has some of the smartest, most knowledgeable people on the planet when it comes to Ember and its ecosystem. It turns out that not only are there experts in-house, but actual CORE team members and longtime pillars of the Ember community.

Being able to pick the brains of these people has been such an enjoyable and illuminating experience. I’ve been helped to understand not just the how of Ember, but the why and when. Pairing and collaborating with these top-tier engineers has helped me see things from different perspectives. Working with people like this has leveled up my understanding in areas like accessibility, performance, abstractions, and so much more. What’s more, I never once felt like I was being a burden to anyone with my noob questions or lack of clear understanding of certain concepts. Quite the contrary, I was actively welcomed and encouraged to grow by these kind folks.

I’d like to specifically thank Scott Newcomer, who was one of the first guys to welcome me to AuditBoard and who always pointed me in the right direction; Jaco Joubert who can wield Ember like a musical instrument; and Chris Thoburn who has graciously been helping me to develop a deeper understanding of EmberData and its inner workings.

It turns out being surrounded by great people and being open to asking for help will set you on the path to becoming better at the things you do.

Interesting problems are framework-agnostic

One of my initial reservations about joining AuditBoard was some hesitation about learning a new framework that wasn’t exactly “new.” I was concerned that learning EmberJS would be a dead-end, that much of the knowledge I had accumulated up to that point in React wouldn’t transfer. I had a nice chat with Dave Laird, the Director of Engineering at AuditBoard about my reservations. He listened earnestly to my concerns, agreed that there was validity behind them, but he also prompted me to think about the most interesting problems I had worked on in the past. He asked, in his quirky-yet-kind Kiwi accent, “how much of those interesting problems were actually related to React, specifically?” I’m paraphrasing of course, but the question and the idea behind it were sound. I came away from that conversation realizing that there will always be interesting problems to solve, and that which framework I was using mattered much less than what the framework was being used to build. I quite enjoy interesting problems, so I was sold.

Here’s the thing that really surprised me. There are tons of interesting problems to solve in the governance, risk, and compliance (GRC) space. Not only is there the inherent complexity of the audit & compliance process, but there’s the constant question of, “how can this be made easier and more simple?”. When dealing with such a vast and critical problem space as GRC, it turns out there’s a lot of thought and conversations to be had, ideas to develop, and things to test and experiment with. There’s a very real opportunity here to innovate and lead an ambitious, yet under-served industry.

Within my first couple weeks at AuditBoard, while I was still getting up to speed on the ginormous scope of the industry, I was already being included in discussions around automation of evidence collection and how to approach that problem from a UX perspective. My “outsider” perspective was considered valuable, and I felt free to share my thoughts as others listened. As a product-centric frontend engineer this was delightful to me. Within a couple more weeks I was already working on building out a concept UI and helping with the design of the overall UX. I felt like I was in my element.

One thing that I surprisingly ended up thinking little about was that I was using EmberJS instead of React. It turns out that the distinction between frameworks isn’t as great as the Reddit threads, Twitter posts, and blog think pieces would have you believe. Ultimately all frameworks have a concept of components, conventions around state management, some kind of routing, and patterns for event handling. Sure, there’s differences in those things, but at the foundational, conceptual level, they’re all working to solve a very similar set of problems.

As a frontend engineer who’s mostly concerned with solving interesting problems, I realized that the framework conventions and APIs don’t really matter much when compared to things like building a solid application architecture, defining optimal component consumption APIs, and ensuring that component boundaries are well defined and that components don’t do too much or too little. The architecture matters more than the framework. Clear thinking and strong foundational skills are what really make or break an app. Creativity lives outside the boundaries of your framework APIs.

Looking Forward

I have now been at AuditBoard (and part of the Ember ecosystem) for about a year and a half. I feel comfortable enough with Ember to not really give it much thought on a day to day level. Sure, there is always more to understand, subtleties and nuances that will take time to fully grasp. But I’m happy to be able to focus on the bigger and more interesting things. That combined with the good, kind, and smart people I’m surrounded with makes me happy to have taken the unexpected step into a new (old) framework.

I’ve already begun working with one of the core team members of the EmberData library. I’m looking forward to eventually becoming a contributor and full-fledged member of the Ember community. Until then, I’ll continue to learn and grow with the help of my friends.

My parting piece of advice, don’t be afraid to look into counterintuitive paths forward. Sometimes leveling up means taking a step back and becoming a beginner again.