Engineering Duties
Below are the list of expected duties the engineer will continuously carry out when working for GVNG. You may notice that a few items here have been included in the onboarding script. However, you will find more detail here along with other important topics.
It is important to know each of these duties and reinforce them continually through the day as well as in the Check-ins if necessary.
Always Have a Plan
From talking about it continuously in All-Hands and Weekly Check-ins, to requiring a plan be discussed prior to starting any major work, planning is one of the most important habits that we try to instill in our engineering team. Oftentimes we all ask the engineers to come up with 3 different approaches that list out the pros & cons of each approach before writing any code. An intermittent review of the Weekly and Daily Standup answers is done to see if the engineers are properly planning on meeting the goals they set out to do the day before.
Open Collaboration
On a remote team, collaboration is key. One of the drawbacks of doing remote work is that it is easy for an engineer to withdraw into the background, only focusing on the task in front of them. When another engineer asks for assistance, the thought "someone else will help them out, I'm too busy right now" can be prevalent. This can lead to no one answering the question, forcing the engineer to privately message someone for assistance.
The team should also get a reminder in the Weekly All-Hands. Engineers who fail to follow a simple rule such this can be an indicator that this engineer may struggle with following directions in other, more important matters.
Experience has shown that teams who frequently message each other privately are not as cohesive when it comes to collaboration as those who actively discuss topics in public forums. Enforcing this rule is paramount for the engineer team to work successfully as a team.
Self-sufficient
The nature of contracting remote engineers from around the world can mean that longevity is not always in the engineer's best interests. One engineer's best practice is another engineer's focal point of refactoring. It does not take long for well-maintained code base to quickly devolve into a morass of undocumented design decisions and shifting standards.
These engineers should be gently reminded that they have a number of tools at their disposal. Git, closed tickets, old Slack conversations, and the code itself are all useful tools that can aid in providing clarity for past decisions made by others. If after several attempts to course correct this engineer are met with failure, they should be let go so they can find a team that better suits their needs.
Incremental Development
When developing software on remote teams, it can be easy for discrepancies to develop between the spec and the final product. The earlier we can get the results, however raw they be at first, in the hands of stakeholders, the sooner we can make sure that everyone is aligned. By delivering small, incremental changes, we allow for quicker feedback.
To talk about the day-to-day advantages of this approach, we must first discuss the opposite approach of engineers working in isolation for weeks on end, only to surface when asked for a status update or when the product is days away from being launched. Creating a parent branch is Git and then continuously iterating on it, while merging in the main once a day (if you're lucky) is how a lot of teams approach large projects. The benefits to this method can be great but ask an engineer why they choose to work that way and they'll usually respond with something along the lines of "that's how I've always worked."
Large parent branches that are separated from the day-to-day work of the rest of the organization can feel like a necessity when developing features that can take weeks to implement. That is, until some bug fix has been made upstream on the existing feature that is being actively worked on in a silo. It takes a diligent engineer to spot that upstream bug fix and make sure it is properly incorporated into the parent branch so that bug is not reintroduced when the new feature work is launched. When it comes time to merge that parent branch into the main branch, a nasty bug can result in reverting weeks-worth of work. The resulting haystack can be quite frustrating to wade through, demoralizing a team upon what was supposed to be a big launch day.
To avoid silos and maintenance nightmares, small, incremental changes are required. New work is continuously merged into the main branch, allowing for those changes to be used immediately. If there is a bug, it is easier to pinpoint the culprit in a PR with 10 lines of code when compared to a PR with 1000s.
Larger projects that require weeks-worth of small PRs can hide their work behind a feature flag. Instead of showing rough draft UI to the end user, a feature flag can permit for those changes to make it into the main branch. Stakeholders can preview the work in production by using that feature flag. Launch day is as simple as removing a few lines of code to disable the feature flag.
Working in this manner can be difficult at first. It requires constant vigilance from those who are reviewing and deploying PRs. Good work can be denied from being deployed, pushed back with a note that explains how it should be broken up into smaller commits. Once the benefits are explained, most engineers embrace this paradigm, championing it when reviewing another person's pull request.
Limit Access to 3rd Party Services
An important standard to maintain is keeping all sensitive secrets (API keys, tokens, etc) out of the hands of the engineers. Albeit rare, there are stories of a rogue dev with access to AWS who changes the password and then demands payment in the form of whatever is the latest in fashion crypto-currency. To avoid that potentiality, we strongly advise that no engineer should ever be given any kind of access to a 3rd party service that could allow for a malicious person to cause harm to the organization. When access is given, it should be "read" access only.
Preventing access to a crucial 3rd party service can make it challenging to build the necessary functionality that relies upon said service. To get around this, the engineers will have to rely upon mocking the service using the documentation that it provides. And if an engineer must have more than "read" access, then it is important to make a note of that in your offboarding notes so that the access can be properly revoked if and when they are offboarded.
Test-Driven Development
Test-Driven Development (or TDD) is essential to ensuring the quality of our code, allowing for bugs to be potentially caught during development. Both front-end and back-end code should be covered by tests. Any pull requests that do not include sufficient test coverage should be sent back to "In Progress" so that they can be corrected.
Following Best Practices
Best practices are laid out in the coding guidelines and should be tirelessly upheld by engineers through code reviews. With a wide pool of international talent, it is important that the notion of strict adherence to high standards is maintained. Contract workers are not always afforded the luxury to work on a team that follows stringent rules around how to write code.
Bugs
The importance of quickly tackling bugs warrants its own Slack
channel, #dev-bugs. Whenever a bug is discovered, the
relevant members of the team need to address it immediately.
It is easy for remote engineers to silo themselves in the ticket
directly in front of me, neglecting urgent issues as they arise.
Failure for the team to react to a bug in an expedient manner
requires a stern warning in the appropriate forum. When bugs go
unaddressed, confidence in the engineering team as a whole erodes.
Engineers who view the bug but are unable to address it themselves
should @ other devs in the bug Slack thread to get their
attention.