Fullscript Developer Handbook

A reference guide for how to be a successful member of our dev team. It describes our culture, processes, and explains how we’ve gone about creating a platform that has taken the integrative health industry by storm.

Culture

Enabling employees to do the best work of their careers

Code Reviews

Reviewing code is an essential part of our process.

It’s an opportunity for education for both the author of the code and the peers reviewing it. It acts as a gatekeeper for quality within the codebase. Receiving criticism on your work can be difficult. It is easy to become attached to your code or view it as a reflection of yourself. It’s important to remember that you are not your code. We all have off days, or patterns and tricks we haven’t learned yet. Code reviews help us all become better in our field. Use them as an opportunity to give and receive knowledge.

Proposals

Writing proposals allows your teammates to provide feedback on your ideas, ensure that technology & processes are well thought out, and have buy-in from the team.

If you have ideas for new technology, changing a process, or how we can build better software - proposals are the best way to introduce your ideas to the team. This can be anything from coding conventions, all the way through to what we should use for message passing between applications.

Knowledge Silos

Share the knowledge, educate others, and don’t be afraid to tackle problems that are outside of your domain.

Just because Jane built checkout does not mean that she should be the only developer in charge of working on it. Similarly, just because Joe built a report does not mean that only Joe can make changes or fix issues with it.

Communication

Challenge ideas and engage in technological debates, but stay respectful

Respect

Naturally, when you put a bunch of smart people in a room, you’re bound to have some differing opinions.

The golden rule is that all discussions happen in a respectful manner. We are all passionate people and trying to do our best. We want an environment where everyone feels heard & respected.

This goes without saying - respect should be at the foundation with all communication at Fullscript. We’re a group of smart folks that have come together to build something great. Collectively we have a wealth of experience to draw from when planning out new projects. Let’s make sure to hear each other out.

Tone

Be mindful of your volume & tone when speaking with other members of the Fullscript team.

It’s easy to get carried away in a discussion. Sometimes we can feel defensive, or tempers can flare when having a debate. If you’re ever feeling overwhelmed in a meeting, it’s ok to ask for a break and time to cool down. Tone is remarkably important to ensure that we have healthy & productive discussions. When this happens - everyone wins!

Feedback

Giving and receiving feedback is an essential element of personal growth and allows us to share knowledge as a team.

Do not take constructive criticism personally and use it as an opportunity to be learn and be better. Also remember this when you are the one giving criticism and do it in a way that yourself would like to receive it.

Conflict Resolution

We want to ensure that everyone feels happy & healthy at the organization.

We encourage employees to speak to each other if they feel comfortable doing so. However, if at any time there’s an issue that you’d like to discuss with a manager, you may reach out to your team lead, the CTO (Kurtis Funai), or the HR Department (Jess Trager).

Processes

Some sound principles that the development team follows at Fullscript

Prioritization and Tracking

Effective prioritization and tracking is an essential part of being a technical resource at Fullscript.

The development team is constantly juggling a high volume of projects. As a result, effective prioritization and tracking is essential. If you are in danger of missing a deadline or unsure of how to prioritize your tasks, it is your responsibility to communicate this with your team lead as soon as possible. They can help you reprioritize and communicate implications to the necessary stakeholders.

Documentation

Effective documentation of projects is a must for members of the Fullscript development team.

Your approach to documentation should adhere to the “Won the Lottery” rule: if you were to win the lottery tomorrow and stop coming to work, would another member of the team be able to understand your workflow and pick up your projects where you left off? This means that you should be documenting as you go. Not only will this make sure you don’t forget anything, it will also make the task of documentation much quicker and less tedious.

Deadlines

Soft Deadlines

Most often used for projects at Fullscript. These are set by the team to ensure that the company is keeping on track with our longterm goals. They set constraints on feature sets and require us to distill the product down to what can be accomplished within a given timeframe.

Hard Deadlines

These are used only when absolutely necessary. This means that the company will have some serious repercussion if this timeline is not hit. At these times we may ask developers to pitch in some extra effort to ensure that we safely hit the deadline.

Emergencies

Of course by this we mean emergencies pertaining to the Fullscript platform - for real emergencies call 911, duh!

Emergencies can come in many forms - a broken deploy, a failing third party dependency, and all manners of other things. If the issue is important but non-urgent - email & slack are usually good enough. If it is an urgent issue do not hesitate to call the CTO, your team lead, or the devops team. Phone numbers can be found on Slack profiles, as well as the company directory.

An incident report should be generated for the event and mailed to the devops team & CTO for historical purposes.

Craftsmanship

Without expectations, there is no bar; if there is no bar, no one knows how they are doing

Efficiency vs Technical Debt

Done is better than perfect, but you need to ensure that it's still great.

We’re a startup - and time matters! We move quickly and value delivering high quality products to our stakeholders as quickly as we can.

That being said, you need to be focused beyond just getting projects done as quickly as possible. All team members should strive to deliver work that will scale and can be iterated in the future. Be considerate of this when writing code or creating reports. In general, your work should be:

Easy to Read
Easy to Change
Easy to Test

Ultimately, whatever form your work takes, you should be proud to stamp your name next to it. If you are not, then you are introducing technical debt. And again, document your work to assist others with picking up where you left off, if necessary.

It’s Y(our) House

Leave it cleaner than you found it. The Fullscript codebase is our home and we want it to remain a place we enjoy living in for years to come! The expectation for all developers is to take care of it.

Ok, enough with the house metaphor. If it wasn’t clear, we are talking about technical debt. Sometimes taking on technical debt is a necessary requirement of software development. We want to ensure that everyone does their part in reducing technical debt when they encounter it. This is not always straight forward, but here’s a good rule of thumb:

"Prioritizing debt can be done by asking yourself 'Is this issue impacting the company or increasing friction into developing code here?' If the answer is yes, bring it up with your team and come up with a plan to solve it. If the answer is no, then it’s fair to assume that debt can remain unpaid for a while longer."

Mistakes and Accountability

While you should do everything possible to make sure your work is complete and accurate, you are not a robot and mistakes happen.

Shit happens – just learn from it

Even after code reviews and testing, things sometimes still fall through the cracks. If you realize that you have made a mistake, it's your responsibility to own up to it as soon as possible. This can help us mitigate the effects of the error and avoid catastrophic emergencies. Once it has been fixed, learn from your mistakes and move on.

Shared accountability

We are all about sharing responsibility: as a team we are responsible to our users, the company, and to each other to do the best job we can. It’s all about the small things, attention to detail, and ensuring that our work is the best it can be. We are a team - we succeed and fail as one.

Technologies

We have chosen a technology stack that we believe provides a tool for every job, while also keeping our products approachable by other developers in the organization.

Languages

  • Ruby
  • JS (ES6+)
  • Golang

Databases

  • MySQL
  • PostgreSQL
We have the opportunity to develop something that is truly core to the medical profession, and in turn improve the lines of communication between practitioners and patients. Our efforts will be a multiplier on both sides of healthcare. By developing a faster, easier system, we can help doctors heal more patients, or even help patients heal themselves.

Brand Guide

To further understand our approach to development, please take a moment to give our brand guide a read as well. If you're interested to know more about or design philosphy, give the designer handbook a look as well.

Read our brand guide Read our designer handbook