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.
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.
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.
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.
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!
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.
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).
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.
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.
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.
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 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.
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:
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.
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."
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.
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.