DEV Community

loading...
Cover image for 6 Months at Vail Systems

6 Months at Vail Systems

Ben Mitchinson
Web Software Engineering focused on code quality, learning new things, and creating effective processes for agile development. Likes to make apps that are fun to use.
Updated on ・4 min read

Cross posted from http://mitchinson.dev/Vail-2020/

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

Discussion (0)