Vokal Engineering Process

Development Process

Every iteration of a project follows the same process at Vokal:

Criteria for passing a code review is based upon having completed tests that cover the acceptance criteria for that iteration. You can find details on testing procedures in our Testing Documentation.

Once your code is tested and ready for code review, a pull request should be opened. Finding an engineer to review your changes is entirely up to you--you can tag individuals, request reviews, or bug people on Slack as necessary. Reviews can take a few minutes or potentially more than an hour, depending upon how much oversight what you're putting together requires. In general, strive to have small pull requests that don't require a huge amount of time from a reviewer. That said, you should always expect that whomever you ask to perform a code review will not be able to do it immediately. Once your changes have been reviewed you will either have the pull request signed off by the reviewing engineer or have changes that need to be made. Assuming changes need to be made, repeat the process until those changes are signed off. Once you have an engineer sign off on those changes, a Senior Engineer will merge the pull request for you.

Time

It's critical that you factor time for review into your iterations. Getting your code merged is entirely dependent upon having it reviewed and signed off on by another developer, which means you need to give yourself enough time to let your changes go through that process. Generally we consider this time overhead to be 2 full days. If for whatever reason you are finding that you aren't going to be able to complete all of your stories with enough time for proper review and rework, speak up! If you're overwhelmed with work for every iteration, talk to a Senior Engineer or the Product Owner for your project. Expectations for an iteration can (and will) always be adjusted to ensure that you're given the time you need to do your job as best as possible.

Code Quality and Accountability

Members of Vokal's Engineering team are expected to take 100% accountability for the quality of their code. It is up to you as the Engineer to ensure that your tests are covering the acceptance criteria as closely as possible, and that you're doing your part to perform productive and informative code reviews for your peers.

Accountability for your work leads to credibility, and that's crucial when you're running into issues that may halt the production of your project. Blocking issues come up all the time, and you will frequently run into cases where you're unable to deliver all of the stories for a given iteration. As long as you're doing your part to deliver well-tested, well-reviewed code this will not be held against you. In fact, we encourage that you speak up when something is potentially going to stop production. Problems often manifest at the development phase, but they're also often created elsewhere. Regardless of where the issue occurred, speaking up and backing your reasoning with a full suite of tests is all that we ask.

Work Week Expectations

Problems happen in every project, but that doesn't mean you need to work twice the hours to make it up. A person's brain tends to shut down after 8 hours of work, and any development done after that point begins to yield more bugs rather than more features. Going overboard to make up for lost time doesn't help you, or anybody else working on the project.

If you find that you're regularly working more than 40 hours a week you should speak up to a Senior Engineer. If you don't speak up and 50 or more hours begins regularly showing up on your time logs, you'll probably hear from your manager. Let the team help you stay sane and working at full potential.