Skip to content

ReportStream Experience Eng Lead

Jump to bottom
sean pennino edited this page Jan 14, 2022 · 5 revisions

ReportStream Experience Eng Lead Job Description

The Engineering Lead on the Experience Team is responsible for:

  • Setting and deliverying on a technical vision for the RS web experience
  • Ensuring the team is implementing and using modern engineering best practices
  • Onboarding and training engineers on the team
  • (If USDSer) Identifying and training a long term lead

Regular Responsibilities (no particular order)

  1. Meetings
    • Weekly sync with Rachel and Drew
    • Dev Leads sync
    • Leading the RS Experience Eng sync on Thursdays
    • All other RS Experience sprint meetings (standups, backlog, retro, etc)
  2. Staging and post deploy frontend QA
    • Once a day run through staging login, download, and upload just to try to catch any critical bugs. Eventually this should be automated but since it only requires ~2 min/day it hasn't been prioritized.
    • Similar to staging testing, after production deploys the same testing is run
  3. Dependabot
    • Once a week on Monday Dependabot opens PRs for npm version bumps. These usually just require quick sanity checks before merging. For anything complicated that is not resolving a bug or security vulnerability, I close the PR with a note why.
  4. Ensuring all engineers have something to work on and are unblocked
    • Ticket delegation
    • PR review
    • Managing cross-team dependencies where necessary
  5. Taking on engineer tasks
    • It is important for the person in the role to also contribute to coding both to help team with team velocity and to maintain a deeper understanding of our software
  6. Responding to site outages
    • Since launching the React app we've had 3 instances of "drop everything and fix it" bugs: log in being broken due ot a Okta misconfiguration, data not loading due to networking misconfiguration, and the site being down due a build error. The Eng Lead won't always be the engineer resolving the problem, but should be responsible for triaging and coordinating the response.
  7. Deploys
    • Presently all of ReportStream is deployed on Tuesday and Thursday. Eventually the frontend should have its own deploy process (more info below). The Experience Eng Leader should be ready and able to help with regular deploys, ad hoc deploys, and own the frontend deploy when that is split out.

Feature priorities looking forward (as of January 2022)

  1. Engineering vision for csv validation

  2. Engineering vision for improving engineering best practices

    • Setting up an environment (such as on test.reportstream.cdc.gov) where engineers can deploy any branch to will speed QA by making it easier for designers and PMs to easily review work in progress. Presently work in progress can only be tested from a local dev environment since the staging server is only set up to show what is presently in the main branch.
    • Separating the React app's deploy from the rest of ReportStream will allow more frequent releases and avoid situations where backend bugs block frontend releases and vice versa. This will require building integration testing on the frontend (since front and backend changes will not go out synchronously), removing the frontend deploy from the current build and release scripts, and creating new build and release scripts for the React app. See Research Integration Testing
    • The ReportStream is missing a defined QA process. Presently features are reviewed and tested ad hoc, which works for most cases, though will not scale as the app grows in complexity.

  3. Engineering vision for Admin tools

  4. Engineering vision for foundational web features

    • Moving off SimpleReport Okta emails and integrations
      • Presently ReportStream uses SimpleReport's Okta automated emails and password set/reset flows, which is a confusing user experience and gives us unnecessary dependencies on SR. See Okta Branding Proposal.
    • User authentication
      • We curent reply ok Okta group naming conventions to determine whether a user is a sender, receiver, or admin. This is hacky and bug prone. See Proposal for React permissions
    • Separationg of concerns
      • The marketing pages (public/unauthenticated pages), user authenticated pages (download, upload, submission history), and admin pages/features (org dropdown, org settings) serve 3 distinct purposes, but are bundled into one app. As features are added to each, this is likely to get a bit jumbled, leading to confusing UIs and bugs.
      • Options to consider:
        • Separate app for authenticated and unauthenticated experiences. Marketing material can be then be easily edited by non-engineers without need an app deploy
        • Separate experience for admin features (possibly hosted elsewhere such as on admin.reportstream.cdc.gov). Features here can be more barebones since the main focus is utility for internal users.
Clone this wiki locally