Discovering NovoEd: Brian Takes Charge of the Rails 4 Upgrade
This is the first post of Discovering NovoEd, a series of blogs that will feature some of the current projects at NovoEd. The first in our series takes a deep-dive into an engineering project led by Brian, a Software Engineer at NovoEd.
I enjoy what I do at NovoEd because it has a lot of impact. I used to work in games; the way that you look at your work in games is different from the way that you look at the work you do in education. In games, much of the work that you do is often aimed with the company’s interests in mind such as: generate more revenue, grow the number of users, keep them playing longer. As these features can be so metric-oriented, players may or may not even appreciate the feature once it comes to life. When you work on a product like NovoEd that has a meaningful impact on the way that people live their lives, people can get better jobs, or have more access and opportunities. Here’s a reach that you can’t see in most other sectors.
At NovoEd, I have the opportunity to work on challenging projects with a meaningful objective and have ownership of them. When I first joined NovoEd in May 2015, my first big project was an infrastructure upgrade to the latest versions of Ruby and Rails, which would allow us to use new technologies that weren’t compatible with the older versions we were using and lead to a significant performance boost. I didn’t join NovoEd from a Ruby on Rails background, so this project allowed me to learn Ruby as well as how to manage and administrate it.
Overseeing the Rails Upgrade gave me a greater insight into how Ruby works and how NovoEd leverages it. Having had to touch so many things in the process, it gave me a much better tour of our codebase than any other project that I have worked on. Having more context for how things work, I feel more effective at my job because I am able to spend less time researching and more time executing.
The project required a lot of collaborative effort among the whole team, as I was diving into a large code base that had many different systems and dependencies. I had an idea of what success would ultimately look like, but I lacked context for many of the nuances that existed within our infrastructure. There were definitely times where it seemed like things were not going to work out for one reason or another, but collaboration with the team on these issues allowed me to push forward and enabled me to make decisions that made sense despite having limited exposure to the codebase and the infrastructure.
Initially we encountered a lot of challenges. There were a lot of different versions of Ruby I could choose from, but every choice seemed to lead to some sort of roadblock and it became less clear whether we were going to be able to upgrade in the timeline that we had committed to, or if we could keep all of the libraries we had grown accustomed to using. Either we had something in our codebase that would preclude us from choosing a version or I was simply choosing the wrong version to move forward with. An already big project just seemed to grow bigger and bigger.
Fortunately I was not alone. While this may have been my project to own, we had several other engineers on board, including Daniel, Farnaz, Abrey, who were more than happy to take time out from the projects they were working on to brainstorm on solutions and workarounds to the challenges I was facing. It was truly collaborative.
I look back at that project with a lot of pride. I came in with almost no context, pulled the rug out from under the whole tech stack and replaced it with a new one. It felt like a really risky project; a lot of things could have gone wrong when we actually made it live. I really wasn’t sure what to expect in terms of things that might fail post-launch, and what assumptions that may have been made that weren’t explicitly discussed. It was really rewarding to see everything running as well (if not better) as it was before despite all of the challenges that lead up to it.
Post launch, we saw a 40% – 50% improvement in response time as a result of this project – much higher than any of us had anticipated. It was an exciting project to work on, and challenging in all of the right ways. I’m really pleased with the way it worked out and it was a pleasure to be a part of.
Before 2020, organizations didn’t have to give much thought to the nature of their sales-training programs. But suddenly, face-to-face training, events and workshops came to a halt in the wake of the pandemic.
This year, we are launching the 20th iteration of our Foundations of LXD course, featuring advances in our learning design, technology, and learning community that have taken place over the past five years.