​​Fullscript Developer Handbook ​đź“—​ 
​​Congratulations, you’re a Fullscript developer! You’ve been selected to be part of our team - something that we take great care creating. This handbook should act as a reference guide for how to be a successful member of our 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 & Communication

​​We want employees to challenge ideas, engage in technological debates, and to do the best work of their careers. 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.

​​Respect

​​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

​​It’s easy to get carried away in a discussion. Be mindful of your volume & tone when speaking with other members of the Fullscript team. 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!

​​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

​​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. 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.

​​Giving and Receiving Feedback

​​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.

​​Avoid Knowledge Silos

​​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. Share the knowledge, educate others, and don’t be afraid to tackle problems that are outside of your domain. 

​​Issue & Conflict Resolution

​​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 (Chris Wise), or the HR Department (Alix Balevi). Fullscript wants to ensure that everyone feels happy & healthy at the organization. 

​​Processes and Craftsmanship

​​Without expectations, there is no bar; if there is no bar, no one knows how they are doing. Here are some sound principles that the development team follows at Fullscript. 

​​Prioritization and Tracking

​​The development team is constantly juggling a high volume of projects. As a result, effective tracking and prioritization is an essential part of being a technical resource at Fullscript. 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.

​​Efficiency vs Technical Debt

​​We’re a startup - and time matters! We move quickly and value delivering high quality products to our stakeholders as quickly as we can. Done is better than perfect (but you need to ensure that its still great). Be proud of what you create.
​​
​​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 and Understand 
  • ​​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

​​While you should do everything possible to make sure your work is complete and accurate, you are not a robot and mistakes happen. That’s why we have code reviews and testing. However, sometimes things still fall through the cracks. If you realize that you have made a mistake, it is 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.

​​Accountability

​​We are a team - we succeed and fail as one. 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.

​​Deadlines

  • ​​Soft Deadlines are 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 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. 
  • ​​(example: our payment provider is shutting down and we need to be off of them within 60 days - it has happened!)

​​Technologies

​​At Fullscript we have a chosen technology stack that we believe provides a tool for every job, while also keeping our products approachable by other developers in the organization. While we believe there is a right tool for every job, we are also very careful about adding new technologies to the stack. 
​​We have chosen three main languages for development: