6 Months at Vail Systems

In June of 2020, I started as a full-time Web Software Engineer at
Vail Systems. Here are highlights of what I’ve
learned, and what I’ll be working on going forward. The plan is to do one of
these a month as quick bullet points, starting in March.

Cross posted on dev.to

In June of 2020, I started as a full-time Web Software Engineer at
Vail Systems. Here are highlights of what I’ve
learned, and what I’ll be working on going forward. The plan is to do one of
these a month as quick bullet points, starting in March.

What I’ve worked on

Our team of 5 made a full-stack app for translating text and generating corresponding audio.
Large quantities of text are imported inside CSVs and then edited
further inside the client React app.
A NestJS API then resolves translations and audio generation with AWS services,
stores resulting audio in S3, and maintains transaction data in a Vail MSSQL
database.

Technology used:

  • React (CRA) / Yarn
  • Typescript (monorepo shared typings)
  • Node / NestJS / GraphQL
  • Cypress / react-testing-library
  • Nock / CucumberJS
  • DataGrip + KnexJS
  • Jenkins + k8s
  • Docusaurus

What I’ve Learned (Technical)

Make TDD work for you

I’ve found that TDD is intimidating for some developers, especially in
client-side testing. I used to think that to do TDD, I had
to have every single assertion down ahead of time. That’s not the case. Just
make a test case with a proper title, and if you’re stuck, write out assertions
in a comment:
// when clicked, the button will turn blue

Don’t let assertions distract you from the purpose of TDD: to have a clear
achievable goal while coding + making decisions. You can still fulfill that purpose
without syntax perfect assertions. After writing enough tests, assertions
will come more naturally.

Starting an app from scratch

I’ve been fortunate to start working on a product from its start and
it’s taught me more than I can write here, but some days I wasted time by trying
to add as many new + exciting tools as possible. After focusing on core
framework functionality and less added tooling, we were able to K.I.S.S
(keep it simple stupid 💋). Now, we have many more options and choices for what
we’d like to add when implementing new features because we’re not limited by
1000x external dependencies. Shout-out to my team lead Nav for helping set those
restraints.

Jenkins + Docker

Maintaining / configuring a mono repo in Jenkins with dynamic tests for linting,
component + integration at both the UI and API layers, and e2e.

Auth

We implemented auth several times looking for a technology we liked. Was good to
understand why auth solutions work the way they do and what they protect against
(XXS, HttpOnly, Secure, Localstorage vs cookies, etc…), as opposed to just how to
configure PassportJS.

What I’ve Learned (Personal)

Pairing remote

It’s been good to practice:

  • giving a pairing partner space to consider a problem while on a call. It’s
    easy to accidentally interrupt.
  • Working off a shared to-do list helps keep efforts focused when new ideas pop.
  • Gathering resources / searching online to help solve a problem, while someone
    is actively working on it.

Work balance while working from home

  • How to take a 30-minute mind break to prepare something for dinner, without
    it derailing your entire afternoon.
  • Taking breaks away from screens. Video games aren’t the best break for the
    mind or the eyes.
  • How to work async: Send updates + check in on others. Grateful that my
    teammates are always up for a call / question.
  • Creating a work environment: Move your desk into a space dedicated for 9-5
    and change the scenery every once and a while.
  • Communicate with others when struggling! It’s easy to forget you’re not in
    it alone.

Taking notes

  • When someone says “how do we do that again”, it feels great to fire off a
    document / confluence page with a breakdown + meeting summary. Meetings become
    2x as valuable when an artifact exists afterward, especially in a remote
    setting. I’m a big fan of docs and making creating documentation part of the
    development process.

What I’d like to improve (Technical)

Client-side performance metrics (web.dev)

We don’t have metrics for many of our operations. I’d like to find ways to
incorporate things like “time to interactive” and “first paint” in our test
suite so that we can find regressions.

Nock

Some of our tests interact with AWS and cause conflicts when running tests on
multiple branches. I’d like to work on understanding “Nock” and using it to
replace AWS calls.

Docs

Areas of our app like authentication and simple things like our implementation
of recaptcha would benefit strongly from a docs page. I’d like to practice
writing things up on new features as they’re being implemented. Instead of
trying to force myself to do them after they’ve been completed.

What I’d like to improve (Personal)

Following through on new ideas + making tickets

Often I think “oh we could improve X by doing Y” or “Hmmm X seems like it’s performing strangely”.
If those ideas aren’t related to the task at hand, it’s easy for me to throw
them to the wayside. I’d like to build a better habit of making actionable
tickets for those thoughts, or at the bare minimum, noting them down.

Resources found / Articles I liked:

  • Atlassian on Remote Work research findings - link