Onboarding Script

This is an example of a script that we have found success with. However, you should feel free to create one that you feel comfortable with.

Each section should be copy and pasted one at a time, with headings formatted as Bold and Italic and giving the engineer ample amount of time to read through and think about the sentences they're reading. Be careful not to overwhelm them by posting too much at once.

Before you begin, be sure to prepare a dogfooding challenge and quiz for the engineer. They will be used later in this script:

  1. Quiz
  2. Dogfooding

Manager's Note:

During the example script below, we have the engineer complete a quiz and a dogfooding challenge. We consider both to be important to the onboarding process and recommend creating them before starting.

Welcome Notes

Welcome to the team! I'm ${yourName}, and I ${whatYouDo} here at Duro. Let’s get you started with the onboarding process.

Please note: all time related to Duro, even if it isn’t direct coding, should be logged on Upwork.

Discuss Check-Ins

Ok, the next thing we’ll do is have you set up a time with me for your Weekly Check-in. This is a 1 hour meeting between you and me that takes place every week. Does ${yourPreferredTime} work for you?

About our Check-in’s:

We use the Check-in meetings to see how engaged our engineers are.

If an engineer comes to a Check-in every week without much to discuss, we become concerned that they are not as engaged as we would like. The Check-in functions as your opportunity to speak with me about anything that is important to you. This can be about your work or questions pertaining to personal development.

I will also use Check-in’s as an opportunity to provide you with feedback. I am here to help guide you with your work at Duro, and I am also interested in your overall progress as an engineer.

Every day when you sit down and do work here at Duro, think about the challenges you face. Think about what you would like to see change, or what you could be doing to make things change.

In the end, the Weekly Check-in’s are only going to be as good as you can make it. You have to bring your own contributions because ultimately, they are all about you.

Weekly Team Meetings

These meetings are mandatory and take place every {$dayOfTheWeek} at {$yourPreferredTime}PT.

They function as a method to get the team on the same track for the week and to focus everyone's goals. This can be used to pinpoint or address the previous week's pain points or successes, as well as address any areas of communication that need improvement.

Manager's Note:

The time that these meetings take place is entirely up to you. We do recommend that they take place at the beginning of the week to maximize their effectiveness.

Duro Acronyms & Definitions

We have a lot of acronyms we use around the workspace. Now that you have access to Jira, please take a moment to review the names within the workspace along with their definitions.

Duro Acronyms & Definitions Document

Add them to Standuply

Manager's Note:

We have had great success with Standuply as it has allowed us to form a way for engineers to structure their day, but more importantly plan. It forces them to think in terms of input and output as a daily routine.

This functions in a different way for the manager. With Standuply we can see what they have worked on, plan to work on, if their daily plan succeeded, or if it failed and why.

The uses this tool provides is truly invaluable.

I added you to Standuply, so you’ll now get reminders for status updates each day at 9am. You will have 15 minutes to respond, so you can choose when you submit your updates.

NOTE: an important thing about responses given to Standuply is to make sure that vague statements are avoided.

Specific and Measurable Responses

It is more helpful if the answer provides more details as to what was specifically worked on for that ticket.

When responding to the questions from Standuply it is imperative to be descriptive and avoid vague statements. The response needs to be a measurable, durable change to the repository. Thinking and planning is acceptable as long as there is actual verifiable output.

For example:

`What do you plan to accomplish before the next Standup?

“I wrote up a doc researching and comparing the different ways to fix `<issue>` and it is available in a PR/issue/slack post”

"By EOD, the `<component>` will change to teal when :hover is triggered."`

are the correct responses, not:

`"What do you plan to accomplish before the next Standup?"

“I thought a lot about how to fix `<issue>`”

"Will work on `<component>`."`

Below are some more good examples of appropriate responses:

"I will create a Research Summary Doc for Project XYZ"

"I will complete feature XYZ"

"I will write three tests for Bug XYZ"

Here are some more bad examples:

"Will work on X"

"Working on feature XYZ"

"Researching bug XYZ"

If you run into an issue, please be sure to consult the documents and then ask your fellow engineers.

Slack Etiquette

No Work DM

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.

If you and another engineer are discussing a topic and are unable to come to a solution, a public conversation allows both of you to quickly include someone else. That engineer can read the previous conversation and get up to speed quickly. Public conversations can also serve as documentation. Someone searching for a term related to that conversation may find that it helps them to understand the problem they are currently facing.

Effective Communication

We are social creatures, so it makes sense that we want to make sure that there is someone to talk to before we send a post out into the void of a channel.

ex. "Hey, has anyone encountered problem X?"

This may seem like a rather miscellaneous question, and you'd be right. What exactly is wrong with miscellaneous questions? Answer: They waste time and space.

With miscellaneous questions, you can expect the conversation to flow like this:

[12:01] Dev 1: "Hey, has anyone encountered problem X?"

[12:03] Dev 2: "Oh yeah, that's a doozy."

[12:03] Dev 1: "How did you figure it out?"

[12:06] Dev 2: "I did fix=XYZ."

[12:08] Dev 1: "I've already tried that, didn't work."

[12:12] Dev 2: "Link me your PR"

[12:17] Dev 1: "Done"

[12:24] Dev 2: "Oh wait, your PR is for repo ABC! That's why my solution didn't work. Try fix = ABC"

[12:30] Dev 1: "You're right! That did the trick, thanks!"

That's 9 posts in a channel if they don't use threads, and over 30 minutes to solve an issue that had a quick fix.

Let's see what the conversation might look like if we cut out miscellaneous questions and instead used concise, well-thought out communication:

[12:01] Dev 1: "Hey @dev2, @dev3: I'm working on LinkToPR in Repo ABC, I've tried fix=XYZ,FIX=X. Am I approaching this the wrong way?

[12:02] Dev 3: "Did that last night, use fix=ABC"

[12:03] Dev 2: "Agree with @Dev 3. Fix=ABC is the solution."

[12:05] Dev 1: "Fix=ABC worked! Thanks!"

That took up 4 lines of code and lasted 5 minutes. Effective communication builds the team and helps the engineer learn how to communicate better.

Status & Notifications

Since we require you to be active from 9am - 5pm PDT, please be sure to keep your status on Slack active. As any @mentions you may receive have the chance to nullified by an "Away" status.

I would also like for you to set the notifications for this Weekly-Check-In channel to "every new message".

Company Code Standards

Code quality is very important to us, and we hope it is to you too. In this guide we'll share our engineering process that we use to ensure that we can build quickly while keeping our projects stable and maintainable.

Please use the links below to view all of Duro's Engineering and Communication Standards:

Some developers feel the need to debate code style. Other engineers will use the project's style and get stuff done. We prefer engineers who get stuff done. Consistency is important, please follow these guidelines.

We use the Airbnb Style in our code. This is the style used by React, Honey, ZocDoc, Zillow, Shutterfly, REI, Airbnb, and many others. Be sure to use an automatic formatter like eslint-config-airbnb for the IDE of your choice.

Please follow our gist to streamline your setup process.

Line length should be limited to 80 characters.

Code Principles

  • Code should be as simple, explicit, and as easy to understand as possible.
  • Functional style is preferred to OOP. When possible functions should be pure and not rely on shared state or side effects.

Modules

  • Always use modules (import/export) over a non-standard module system. You can always transpile to your preferred module system.
  • Do not use wildcard imports.

  • Do not export directly from an import.

  • Put all imports above non-import statements. eslint: import/first

  • Multiline imports should be indented just like multiline array and object literals. eslint: object-curly-newline

Ordering

  • Modules must use this order so that they can be understood quickly when skimmed:

    1. External dependencies: anything listed in package.json, e.g. require('http')
    2. Internal dependencies: any files created in the project itself, e.g. require('./api')
    3. Constants and other setup: this includes anything absolutely necessary to be defined before module.exports
    4. Exports: module.exports should be as close to the beginning of the file as possible. The module should export either a single function or a "catalog object", e.g. module.exports = { method1, method2, ... }
    5. Functions: these go after the above sections. Use function hoisting to control the placement of your functions so that important, high-level functions are above smaller more-general utility functions.

Naming Conventions

  • Use camelCase when naming objects, functions, and instances. eslint: camelcase
  • Use descriptive variable names. Function names should be a verb like route() or verb combined with a noun like routeRequest().
    • Avoid single letter names. Be descriptive with your naming. eslint: id-length
  • Use PascalCase only when naming constructors or classes. eslint: new-cap

Functions

  • Use named function expressions instead of function declarations. eslint: func-style
  • Wrap immediately invoked function expressions in parentheses. eslint: wrap-iife
  • Keep your functions short. If your function is over 40 lines, you should have a good reason.
  • Functions should not accept more than 3 arguments. Use a single options object if you need more arguments.
  • Keep nesting to a minimum. Use early returns, single-line conditionals, and function calls.

Code Review

All PRs must be reviewed by a teammate before they are eligable to be merged into the master branch. Large PRs are difficult to review. Be sure to break large PRs into smaller ones so that they can be reviewed quickly and deployed to production.

  • Never commit passwords, access tokens, or other credentials into version control. If you think you absolutely have to, ask first. If you do this by accident, tell your manager immediately.
  • Each commit should be as small and as simple as possible.
  • The project must be operational and have all tests passing after every commit.
  • Use Conventional Commits
    • Valid types are chore:, docs:, style:, refactor:, perf:, and test:
  • Do not mix feature changes (added functionality) with fixes (restored functionality), refactors (no change in functionality), or style changes (only whitespace or other cosmetic changes).
  • Before a PR is ready for review, make sure that it is a single commit. If the combined commit is too large or disparate, consider multiple PRs.
  • The exception to the above single commit rule is when a PR introduces new packages. Create one extra commit in the same PR for each new package your PR needs.
  • Do not modify a project's .gitignore to add files related to your editor or environment. Use your own global .gitignore for that instead.
  • Be sure that your PRs have descriptive titles that explain what has been changed. Typically the commit message is sufficient. "Fixes #66" is not.
  • When submitting a PR with UI or visual changes, please add before and after screenshots to the PR. This makes it easy for the reviewer to quickly see what has been done.

Workflow

Engineering Duties

Always Have a Plan

When faced with a problem, most engineers will launch right into a solution. Rare is the engineer who will set down and weigh out the pros & cons of a particular solution. In doing so, they might happen a better solution than the one they initial came up with.

Not every task requires a plan. Fixing the margin on a button or creating a simple CRUD API endpoint do not warrant the need for a plan. Implementing a new function solution? Plan it out. Building a major new feature for the site? Plan it out.

Self-sufficient

Even the most well-intentioned engineer has a bad day, resulting in a choice that accumulates debt at a higher interest rate than others.

You should be self-sufficient and adept at navigating existing code that they did not author. Turning to others for help is actively encouraged, but only after first trying your best to comprehend on your own first.

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" and have their assigned engineer notified so that they can be corrected.

Permissive > Prescriptive

It is not uncommon for an engineer to ask for permission to make a small change. But there is one thing you need to remember: you have the power to make changes here, but with this power comes responsibility. We need you to discuss your potential changes with your team. There are exceptions of course. “Can we use this plugin?” You probably don’t need to ask. “Can we update our whole build process, causing countless man hours to be wasted on upgrading something that doesn’t really need an upgrade?” It’s a possibility but it needs to be discussed first. Another important lesson to learn is deciding when to discuss a small change vs simply implementing that change and submitting a pull request. 30-60 minutes on a PR might be a better use of time than the same 30-60 minutes spent discussing it on Slack. Worst case, the pull request gets denied and a small amount of time was spent on something that ultimately was not worthwhile. That is okay. It’s a fine line between being proactive and knowing when to ask for permission. Being consistent about your goals and communication will help in this area.

Articles

Dogfooding

This is where we would generally place the engineer as the perfect time to introduce your companies approach to dogfooding.

Manager's Note:

Consider this your chance to show the engineer what the app should look like from a customer’s perspective.

Show them what the app should look and function like. Give them an idea of how customers will navigate, message doctors, create meetings, and more.

Often times this means creating a dummy account and having the engineer complete certain steps to gain an idea of the app they are working on.

This is a common onboarding tactic when bringing on new people that gets them “on the same page” as everyone else. Thus making them work towards the same goals your team has.

Quiz

You're almost done! Taking all of the information you've learned above, please answer these questions: Duro Onboarding Quiz

Manager's Note:

This is where you have them fill out a form that you believe best showcases their understanding about their workspace and what is expected of them.

It can be a Google Form, Typeform, or any other form of polling that you choose to use. The length and amount of detail in this quiz is entirely up to you as well.

It is important for you to pick necessary aspects of the job that you want to be 100% clear with the employee on. This can be used as a reference later on as well.

Introduction to Team

I would like to introduce you to the team and have you give them some information about yourself. Let us know when you have completed your intro and please post it on #dev!

Get Them Started

You’re all set! Welcome to Duro!

Manager's Note:

Once all of this is done, the engineer will be setup to start their first PR with you.

It is recommended that their first PR consist of a simple problem that brings them through the engineering lifecycle and gets them further acquainted with their surroundings.

After this, you will have a fully integrated engineer working on your team. Congratulations!

results matching ""

    No results matching ""