vic.ai

I started at vic.ai in 2020 right before covid fully took over. Initially I was looking to get back in the office and they had a "headquarters" in new york (where I interviewed), so it made a great fit. That quickly changed as the pandemic got worse and soon there were only a few of us left in the office while most chose to work remotely.

Unlike my previous company however, vic.ai has basically always been remote-first as our founders were from Norway and much of the engineering team initially started in Europe. This made adapting to covid-life a fairly easy transition for the company as a whole and eventually I got used to working remotely yet again...

the early days

When I first joined, the company had just raised a Series A which was heavily tied to one large contract. Much of the engineering team was focused on onboarding that customer, however our product lead, a designer and I peeled off to start revamping and redesigning much of the initial feature set.

After a lot of hard work (and a decent amount of shimming that's probably all too common at startups), the rest of the team finally got that customer on the platform. They joined us in readying a more generalized and stable version of the tool that was easier to sell to a broad array of customers. Our user base, accountants, were particularly used to interactive spreadsheets and we dove pretty deep into building something that supported efficient keyboard shortcuts while also having a more modern feel.

While I certainly won't say we made all the right decisions at this early stage, we seemed to have done something right because in September 2021 we succeeded in securing a Series B.

our ui stack

When I started as a senior engineer, we had been using angular despite the discontinued long term support. I surfaced to our product lead and CEO that we'd eventually have to transition away from it but understood that a migration was hard pill to swallow for such an early stage company. I knew we could cross-load frameworks but coming up with that solution would take some time to get right.

So, while we pushed towards the Series B round, I focused on cleaning up the existing codebase, introducing more reusable components and reducing our dependence on angular via more vanilla js. We eventually phased out all the angular "services" in favor of top-level component state and vanilla utility functions.

Once the Series B was out of the way, we started hiring more aggressively and I set up a bridge component so we could drop into react and redux at any level of the application. Given that this was a large codebase with ~1,000 active users, we didn't have the option to pause releases for months while we ported everything over in one mega-migration.

This more granular, inside-out approach has worked quite well and we're now just a few components away from removing angular entirely. Once we've replaced it and its router at the top level, we'll drop angular-cli in favor of a more modern bundler like parcel or vite.

what i've learned

Even though I'm happy with the overall approach, there are still things that in hindsight I probably would've done differently. Depending on the framework you're migrating from -- as well as the one you're migrating to -- a cross-loading setup is actually not too hard to put in place. This is actually a huge advantage of react and its runtime vs frameworks like svelte and angular that are coupled more closely with a specific compiler.

Had I known it would only take me a week or so to explore and set up, I would have pushed the stakeholders harder to start that move earlier. It's funny also because I had one or two engineers write off the possibility of cross-loading entirely, figuring that no two ui frameworks would play nicely together. Now that I've seen it in action, I can see the potential of low touch exploration that teams can do to quickly sample a framework in an isolated portion of an application or use one to tackle a specific performance issue (though obviously that comes with the maintenance tradeoff of maintaining multiple frameworks, so there'd have to be very good rationale for it).

In any case, we're about done with that migration, the team has grown and I've since been promoted to Lead UI Engineer and subsequently Director of UI Engineering. Now that were almost through with the migration and have more people on them team, my job is transitioning to...

  • Early stage technical specifications and planning
  • Supporting members of the team as they drive more projects themselves
  • Cross-stack architecture and tech debt

While in the world of engineering meetings are often referred to as terrible thing, I've come to appreciate the ones with a clear purpose and outcome; for example spreading context, driving consensus around a key decision, or even one on ones to help an individual get unblocked or plan their week. As engineers and for individual contributors in general, it's very easy to forget how important communication and cross-team / cross-stack vision really is. If you make quick decisions based on personal preference rather than clear ratitonale that's been discussed throughout the team, much of your work is bound to be reverted by the next person who just sees it all as spaghetti code compared to their personal preferences.

what's to come

I'm still figuring this question out to some extent. While I have to start letting go of more low-level decisions at work and instead trusting newer members of the team to make them, I still love building and try my best to keep up with the industry. While my expertise is definitely in UI engineering, I'm now more interested in full-stack architecture at least from a high level. That being said I also care pretty deeply about product and design (which was my initial segue into the engineering world). Even workflow and project management piques my interest because without organization and focus, it's really hard to bring any meaningful endeavor to life.

It's always been a goal of mine to solve problems on a broader scale. I think softwares' real promise is its reach, and therefore delivering solutions to a wide userbase has always excited me. Maybe the wide breadth of interests will make me a good fit for higher level positions and decision making. I'd love to start a software company at some point but that will take more practice when it comes to trust and comfort with delegating decisions.