Today I want to talk about some engineering practices we use here at Dashcam to stay productive!

Most of our team are engineers with an affinity to build products, some of us like to describe what we do with the term of product engineering.

As product engineers we spend a lot of time thinking about features and how they would help our customers, we do that by talking to them and looking at usage metrics of Dashcam across the whole spectrum of users.

Additionally we keep an open mind about the competition and often will compare what we’re building with what’s available on the market. We believe it’s important to stay focused on our mission, but also to stay on top of the wave!

Being a product engineer means you also do a lot of testing and experimenting. The famous build -> track -> improve life cycle. We don’t just write code!

This is the first in a series of posts about how we do product engineering, as a team of engineers!

How we use Github to stay productive

If you’ve worked at a startup or any small company you must be familiar with the pull request system, regardless of your role. During the day you might hear the term “pull request” being thrown in casual conversations…sometimes abbreviated as a PR (pea-are)

Pull requests on GitHub enable effective code review workflows. For collaborative software engineering efforts utilizing GitHub, extensive utilization of pull requests is recommended. Why? Because they allow for proper code-reviews to happen efficiently!

There might be other ways, but we believe that Pull requests (PRs) are the most efficient way for small teams to merge code into the main code base!

Pull requests can be initiated between different branches within the same code repository, also known as the shared repository model.

This model is advantageous compared to the fork and pull model due to its simplicity arising from fewer required git branches and remotes.

An optimal practice is to have another engineer merge contributed code into the main code branch, ensuring dual code review.

This is how we do it at Dashcam, and it works for us, it helps us iterate fast!
One person builds a feature (or part of it), someone else on the team has to read and test the code.
Although this works really well in teams our size or slightly larger, it might be that in larger teams a more complicated system might help in suggesting which individual(s) should review a particular code contribution.

Now you might be wondering: why utilizing distinct git branches for pull requests?

1. You can push multiple independent pull requests without ambiguity, as additional commits pushed to the pull request branch become incorporated into the initial contribution. This prevents the main branch from becoming a “free for all”.

2. You can also rebase or squash the pull request commits when merging to curate the repository commit history. Basing pull requests on temporary branches rather than the main branch enables simpler git history rewriting. The temporary pull request branches can be discarded/deleted once the pull request is merged without issue. At Dashcam, we don’t actually do this, we keep all branches – but we thought about purging them eventually!

Keep submitting PRs!

Overall, dedicated git branches help you create clean pull requests, keeping them isolated one from another, keeping the processes simple and loosely coupled from the core codebase.

It also helps making pull request maintenance better: you never know when you have to reverse a PR, so using this method keeps it simple…and that’s how we do it at Dashcam!