There's plenty of dev/beta/test servers and databases to use.
Trainerroad careers code#
We've got a beta system that has a flow of production data that helps you develop and test your code without worry of breaking things. Every web PR that is approved is automatically deployed (CI). We have a dedicated QA team to manually check your PR (it requires four testers to sign off). Every PR has a set of unit tests and automated UI tests run against it. Instead of experiencing a merge/testing hell at the end of the project, we encourage small PRs into master with a "feature flag" on the new project that allows employees to use the feature in production but not our users. Oftentimes projects will take weeks/months before they are launched. Our process prevents bugs/regressions and ultimately saves a lot of time. When they submit a PR there's always code review, UI/Unit tests run, then QA manually tests.įor the web, we automatically push every PR that's merged into Master.įor the app, we do weekly releases where there's a final regression test with all merged PRs from the previous week. We have engineers review issues before a sprint for clarity and completeness. We want just enough process to be awesome, and nothing more. That's why we love fast computers, hot reloading, and a great build chain. To be a successful engineer, you need to get into "flow" (more on that below) as often as you can. We still run thousands of unit tests per build, but we're not testing 1+1 = 2. We test the areas that are most likely to break, are tricky, or are likely to be changed.
![trainerroad careers trainerroad careers](https://www.outsideonline.com/wp-content/uploads/2021/03/24/trainerroad-chart-3.jpg)
Good code is testable, however, you don't get the same testing ROI for every line of code. We believe in a few more lines of code for the sake of clarity and debugging ease. Sure, there are fewer lines of code, but it takes someone a few days to figure out what's going on and it's easy to write bugs. We've had complex class hierarchies and really shown off our CS skills. We admit it, we've made things too complex in the past. Good code ships, great code gets "tinkered" with and debated about ad nauseam. Write good code, but not necessarily great code. This job is primarily TypeScript development using React (on Electron or web) and React Native. Our website is built in Angular 2+ and opportunity exists to work on the web in Angular, although we will be migrating to React in the future. We want this loop to be as quick as possible. We track what our users do, learn from that, and improve the product. Our goal was to increase the speed of app development, and we did this through hot reloading, fast computers, a great build chain, automated testing, clear and well-defined issues, and a dedicated QA team that tests every PR. We've recently re-written our mobile and desktop apps in React/RN with TypeScript. It's a solid codebase (it can always be better) and we strive to add to it without making it exponentially more complicated.
![trainerroad careers trainerroad careers](https://cdn.shopify.com/s/files/1/2318/5263/files/TR4_2048x2048.png)
Trainerroad careers software#
We're looking for smart software engineers who "get things done." They will be full-time employees of TrainerRoad and will join a cross-functional pod on an established remote team.Īreas of work include TypeScript, React, Electron, and React Native.
![trainerroad careers trainerroad careers](https://media.glassdoor.com/sqll/1374854/trainerroad-squarelogo-1582699433452.png)
TrainerRoad is looking to expand our engineering group.
Trainerroad careers professional#
Do you do your own dishes? We've got a job for you (and it's not dishwashing -) ).ĭo you put them in the sink and expect someone else to do them? Move on, please.ĭo you get pissed (in a professional way) when someone else leaves their dishes in the sink? Please apply!