6 Months at Vail Systems
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.
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.
- React (CRA) / Yarn
- Typescript (monorepo shared typings)
- Node / NestJS / GraphQL
- Cypress / react-testing-library
- Nock / CucumberJS
- DataGrip + KnexJS
- Jenkins + k8s
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.
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.
Maintaining / configuring a mono repo in Jenkins with dynamic tests for linting, component + integration at both the UI and API layers, and e2e.
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.
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.
- 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.
- 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.
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.
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.
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.
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.
- Atlassian on Remote Work research findings - link