Our mission is to accelerate progress in medical imaging by sharing knowledge, creating tools, and providing quality services to our clients, with the ultimate purpose of improving patient health. We do so while providing meaningful, flexible, and financially rewarding careers to our team.
This handbook describes how we develop great software while maintaining enjoyable, flexible, and financially rewarding careers. We wrote it for a few different audiences.
If you are considering joining us, this handbook should help you decide by providing insight into how we work.
If you just joined us, this handbook should contain everything you need to know to hit the ground running. We are excited that you are on the team.
If you have been with us for a while, then you are probably checking to see whether Black Friday is a company holiday (it is).
If you have hired us, this handbook may be rather dull, but we are glad that you are curious about how we work.
This handbook is hosted in a git repository. If you have a question that you wish the handbook answered, let us know. Please make a suggestion in #general if you are a team member, or email us. Team members can also submit pull requests with proposed changes.
Please note, links to the GitHub repository and Slack will only be accessible to Innolitics employees.
We do our best to keep our values at the center of how we work. Our company values are to:
Pursue a deep understanding.
- We don't just code and hack our way through problems.
- We aren't satisfied just knowing that it works; we want to know why it works.
- We view the computer logically and without superstition---there is no magic.
- We seek projects that will provide us an opportunity to learn.
- We spend time most weeks learning and discussing topics related to our work.
- We write articles to solidify our understanding.
- We enjoy experimenting with new technologies so that we can use the best tools for the job.
Build quality software.
- We write automated tests to guide our design and ensure our code continues working.
- We write code that is as simple as possible for others to understand.
- We prefer projects where we have the time to build the system architecture correctly from the beginning.
Treat our clients ethically.
- We don't provide unrealistic project estimates to close deals.
- We educate our clients so that they can make good business decisions instead of capitalizing on the lack of software expertise.
- We recommend partner firms if we believe they would be more appropriate for a client's problem.
- We write high-quality code so that it can be maintained as cheaply as possible.
Understand the business context.
- We aim to understand the purpose of a feature before we build it.
- We use technologies with the best interest of our clients in mind, even if they are less appealing to us as developers.
- We don't waste time over-building features that are not relevant to the business.
- We value correct grammar and a strong grasp of the English language.
- We write with a clear and professional tone in our external communication.
- We try not to send vague or confusing emails.
- We invest in improving our writing, presentation, and conversational skills.
Be responsible for our work.
- We push hard to meet deadlines.
- We don't leave sloppy bugs for others.
- We don't leave broken code, even if we did not write it ourselves.
- We try to solve problems before asking help but also know when to ask.
- We continually and actively improve the development processes used in our projects.
Be pleasant to work with.
- We help each other learn new things.
- We compliment others when they write good code.
- We try not to complain.
- We don't dump our work on others.
Respect the autonomy of fellow developers.
- We avoid micromanagement.
- We value logic and reasoning over seniority when making technical decisions.
- We avoid prescribing up-front solutions to problems; we prefer allowing developers to explore their ideas first.
Make the world better.
- We love working with talented people, regardless of their age, gender, race, ethnicity, sexual orientation or background.
- We financially contribute to open source projects that we use.
- We don't work on projects that we don't believe make the world better.
- We don't work on projects that we don't believe will be used or will be useful for others.
Enjoy our work, and relax.
- We want everyone on our team to enjoy their work.
- We provide a flexible work environment.
- We push back on unrealistic deadlines.
- We encourage vacation to maintain a sustainable workload.
We suspect most of these values are not controversial. Still, if you disagree with any of them, or if you want us to add or modify any of them, please initiate a discussion! Here are a few examples of how our values have changed over time:
After we hired our first developer, we added “We love working with talented people, regardless of their age, ethnicity, sexual-orientation or background”. A few months later we added “gender” to the list.
We added “We financially contribute to open source projects that we use” to the list because, as a profitable company that uses many open source projects, we feel we should give back.
We clarified “we write automated tests to ensure our code works (and continues to work)” by re-writing it as “we write automated tests to guide our design and ensure our code continues working” to highlight our belief that tests not only help catch bugs but also improve our designs.
Originally, one of our values read: “We don’t prescribe solutions to problems; we allow developers to independently discover their solutions first”. After some discussion, we changed this to: “We avoid prescribing up-front solutions to problems; we prefer allowing developers to independently explore their ideas first”. This change was made because we realized that sometimes it is too time consuming to allow everyone to explore their solution, especially junior developers working on problems that have been solved many times in the past. In these cases, we believe it can make sense for the more experienced developer to prescribe a solution up-front. We prefer to have junior developers to find their solution first because it is educational and can lead to better solutions (perhaps a new technology was developed recently, or the junior developer comes up with a new approach).
This last example highlights that many situations we run into as developers are not black-and-white. Our values are a foundation for discussion, but often we are weighing competing goods. For example, “We enjoy experimenting with new technologies so that we can use the best tools for the job” and “We use technologies with the best interest of our clients in mind, even if they are less appealing to us as developers” can be competing goods.
Most importantly, if you feel that we are not following our values, say something! We can not stress this enough. It is essential that you say what you think.
Several months after adding our commitment to contribute to open source software, we still had not done so. Someone brought this up, and in response we setup our open source contribution page.
Medical Imaging Software Services
We love working on medical imaging software. Our work helps doctors diagnose and treat patients in the clinic and helps researchers make breakthroughs in the lab. We believe that software has the potential to transform the medical imaging industry, and we are excited to be front and center in this transformation.
Medical imaging software is a specialized field, so we don’t expect everyone who joins our team to have a strong background in it. Many of our projects have challenges that are not unique to the medical imaging. That being said, you do need to be interested in medical imaging, have some mathematical background, and have a desire to learn more to be a successful part of our software team.
We Are a Remote Only Company
We are a remote only company. We don’t have a central office, and most of our communication occurs in Slack, video calls, and email.
Working remotely allows for a flexible work schedule. For example, David’s wife is a nurse. She works night shifts and during many weekends, but is frequently off during the work week. If David did not have the flexible schedule that remote work affords, he would see his wife much less often. As it is, he can work longer days when she works, and work shorter days when she is off. Also, because he works from home, he can see her when she wakes up in the afternoons.
Although flexible work schedules are possible for non-remote workers, they are harder to arrange or take advantage of. When everyone is working in the same location, there is a lot of pressure to be “visible” at meetings and during the typical work day. Going on an afternoon errand run is often impractical. Conversely, when a company employs only some remote workers, it is easy for those workers to get left out of meetings and company activities.
A remote only company encourages everyone to focus on their value-added instead of hours worked because value-added is more visible than long hours in a remote setting.
There are many more benefits to working remotely which we will not list here. However, there are also important-to-mention disadvantages to working remotely.
Working from home is not for everyone; it can be lonely, and it is easy to go stir crazy. It is more difficult to separate work from your personal life.
If you have never worked remotely before, it is worth thinking through how you will manage or respond to these various issues. Some people prefer to work from a co-working space on some days. Other people like working from coffee shops in the mornings. David has two “users” on his MacBook, one for his personal life, and one for work. This allows him to turn off notifications when he isn’t working.
It is more difficult to develop strong relationships with remote teammates because we can’t grab a beer after work or chat in person. There are a few ways we alleviate this. The first is via conversations on #random. Next are our 10x Discussions about various medical imaging and programming topics. Finally, we have retreats at least twice a year. More about our 10x discussions and our retreats in a bit.
We are a small team. We have eight full time members as of August 2018.
We are planning on growing the company substantially over the next few years.
Working on a small team means we have relatively little structure and more personal responsibility. As an early member of our team, you will have the opportunity to grow with the company, and to influence how the company develops.
We work on projects of varying sizes. Our typical engagement lasts about a year, although we have been working with some of our clients for several years. Typically, everyone is assigned to a single project at a time.
Each project has a project lead who is ultimately responsible for the success of the project. The project lead’s responsibilities include:
- Being the main point of contact for the client
- Making sure there is someone to step in as main point of contact if they will be out of communication (e.g. on vacation)
- Advocating for the client’s happiness to the group (e.g. if the project could use some extra resources to meet a deadline)
- Relaying to the group what tasks need to be accomplished on the project (during task meetings as well as when unexpected items come up during the week)
- Organizing tasks in the project management tool, and tracking deadlines
- Facilitating discussion about the proper tech stack to use on a project.
We usually have client progress meetings on Mondays, and additional meetings as necessary throughout the week.
On Wednesdays from 2:30 - 5:00 PM CST we have 10x time (we choose Wednesdays so that we can travel on Monday or Friday). Some weeks we’ll skip 10x time if there is an impending deadline or many folks are on vacation. We do not have a 10x time during the week of Thanksgiving or the Wednesday in between Christmas and New Years.
We have two types of 10x time:
- Discuss an article, video, or book chapter. Everyone reads the chapter from 2:30 - 3:45 PM CST, and we discuss on a group video call from 3:45 - 5:00 PM CST.
- Three-week mini-project. During the first two weeks we work on the project and discuss in Slack. On the third week, we work from 2:30 - 3:45 and discuss from 3:45 - 5:00 PM CST. If you prefer, and your client obligations allow it, feel free to lump all three learning sessions into the third week (i.e. work on the mini project all day).
Usually, only a single partner will participate in mini-projects. Also, we suggest pushing your mini-project work onto GitHub.
We try to pick topics that are fun and interesting and will make us better developers. Please feel free to suggest topics in #learning. If we end up using your suggestion, please add a new item to our list of previous discussions. We try to choose the discussion material or mini-project Friday afternoon of the previous week. You can see a list of our previous discussions here.
If we are having a good discussion, we will often go 15 minutes or so past 5:00 PM CST. If you have plans and need to duck out, but can’t get a word in to say so, just drop out of the call and leave a comment in Slack; everyone will understand.
We meet one or two times each year to have some fun and get face time with one another. The retreats usually begin Thursday afternoon and end Saturday afternoon. The destination always changes. We cover the travel, housing, and food during the retreats.
Unless there is a very good reason (and please let us know as soon as possible), everyone is expected to attend all of our retreats.
We keep travel to a minimum, but we occasionally must travel for
- 10x retreats
- Project meeting kickoffs
- Design sprints.
When you travel, keep receipts for food, transportation, and accommodation expenses. We can not reimburse expenses if there are no receipts, so please be careful to keep them!
Please use your best judgment when purchasing food, flights, and hotels. Keep in mind your time is valuable. For example, it is worth spending an extra $100 to get a direct flight or to avoid needing to fly out at an uncomfortably early time. Feel free to ask David or Yujan if in doubt.
If you are driving your own car, track how many miles you drive, ideally by taking a photo of the dashboard at the start and end of your trip. We use the mileage numbers to calculate the IRS standard mileage rates for reimbursements. For 2017, this was $0.53/mile. Note that the standard mileage rate’s include the cost of gas, so please do not include receipts for gas.
You must create an expense report to be reimbursed. We provide two different ways to create expense reports, which are described below. After submitting your expense report, you should be reimbursed on the next payroll cycle. If you are traveling and you need to purchase a flight, feel free to send an expense report with just your flight and a second report with all of your other travel expenses.
Expense Reports With Expensify
Download the free Expensify app. After creating an account, you can:
- Forward receipts to
email@example.com(this is convenient for flight and hotel receipts in emails)
- Scan paper receipts with the mobile-phone app (this is convenient for coffees, food, and other expenses during the trip; we recommend taking pictures immediately, so you don’t forget or lose them)
- Upload images of receipts via the web interface (this is the backup option).
Once all of your receipts are uploaded, download a PDF copy of the report and email it to
Expense Reports With Excel
Fill out this spreadsheet and send it and the images of the receipts to
We value our flexible work schedules, however, this does not mean that we can work anytime we wish.
- Everyone should be available for our 10x discussions.
- Everyone must be flexible enough to make client meetings. We typically try to schedule these on Mondays, however, it varies from project to project.
- Your work hours must, to some degree, overlap with the hours of other team members who work on the project. This overlap is important to ensure that code is reviewed promptly and timely communication can occur.
- All else being equal, it is best to work during the normal work week.
We have mid-year reviews and end-of-year reviews. We also have a short review three months after you join Innolitics, primarily to check that you are happy with the position and it meets the expectations you had when you accepted the position.
When you join Innolitics, we will setup a private GitHub repository which will only be visible to partners and yourself. For now, these repositories will have a single file,
Reviews occur as follows:
- A partner (usually the partner with whom you have worked the most since your previous review) will reach out on Slack and schedule a time for the review.
- You should read through the list of questions, written below, and write out any thoughts you may have in a new branch in your repository.
- During the review, you and the partner will talk through:
- The answers to the review questions
- Your performance since the last review
- Your personal growth goal
- Your annual raise and bonus (only during our end-of-year review)
- After the review, write out notes from the discussion in the new branch you created, and then create a pull-request from the branch and assign it to the partner who did the review.
Here are a list of questions to consider before your review. Please let us know if you can think of any questions to add to this list.
- Have you been satisfied with your job since our last review?
- Are you happy with your growth and performance since our last review?
- What surprising things, good and bad, happened since our last review?
- Which of the following changes would make the most significant difference in your job satisfaction?
- More time off
- Increased compensation (either through your salary or other benefits)
- More responsibility, ownership, or career-growth
- More interesting or meaningful work
- More opportunities to learn or develop new skills
- Something else
- Do you feel like you have a healthy work/life balance?
- Project organization and management
- Do you know what you need to work on?
- Is the project (or projects) you are working on organized in such a way that you can be productive with your time?
- Are there any project-specific constraints/policies that hamper your ability to be productive?
- With respect to your work, do you wish you had more guidance or less?
- Do you ever wish you were working on a different project at Innolitics, and if so, which one?
- Are recognized when you do good work?
- When someone else on the team underperforms, is it addressed and corrected?
- Do you feel like you have opportunities for your career to grow at Innolitics?
- Do you feel like Innolitics has moved in the right direction since your last review?
- Do you have any ideas about open source tools, products, or services that we could offer that would help further our company mission?
Email is best for non-urgent communication that requires a formal or well thought out response.
Slack is best for most everyday communication. Here are some rules of thumb for Slack communication:
- Write messages in the appropriate channel.
- When someone asks a question or makes a request, respond quickly—even if it is just to acknowledge that you are “looking into it.” Often the other person will be waiting for a response and if you look into the issue before responding, the other person will waste time.
- @mention people when you need their feedback.
- If your presence or absence may affect other team mates, it is nice to keep your Slack status up-to-date so that others know when you start working or go to lunch. You may also want to check to see if others have any last minute questions before you leave for the day.
- Only use direct messages when you have private stuff to say that would be of no interest to anyone else. It is typically better to keep most conversations in public channels so that other people on the project can see what is going on (even “future” people that may join the project at a later time).
In a remote working environment, a Slack mention is the equivalent to walking over to someone’s desk and tapping on their shoulder. The impetus is on everyone to not over-use mentions as they are disruptive, but when someone does mention you, you are at your desk, and not in a call, respond quickly! By “quickly” we mean within 5 - 10 seconds.
The best way to respond this quickly to mentions is to use Slack desktop notifications (and audible notifications if necessary).
In order to avoid being inundated with notifications, we suggest telling Slack to only notify you about “Direct messages, mentions & keywords.” You can set this from your Slack preferences. This article has more details. If you have any channels where you want to be notified of all messages (e.g. a client’s channel), use the channel specific notification preferences to turn notifications on for “All new messages.”
If you need a solid block of time to focus on a technical problem free from interruptions, we suggest setting your status to indicate as such. David tends to use the Robot icon for this (e.g.,
/status :robot_face: head down coding).
We use Slack for most video calls; we use Skype as a backup.
The person who initially mentions starting a call in Slack should initiate the call; this convention avoids delays that can occur when both members are waiting for the other person to call.
When on a client call, follow some video call etiquette:
- Wear a collared shirt (e.g. a polo or button down); if you a last minute meeting is scheduled and you are wearing something less formal, either turn off the camera or orient it so that only your face is visible.
- Mute yourself when you aren’t speaking if there is background noise or if many people are on the call.
- Look into the camera, and not at the video stream.
- Ensure you have proper lighting.
- Smile! It can feel unnatural smiling at a webcam, however, it makes you look better.
Respond to client emails promptly during the business week, even if it is just to say that you will respond in full at a later time. Clients really appreciate quick and prompt communication.
Informal writing is sufficient for internal emails. However, when emailing clients, please pay extra attention to your grammar and spelling. We highly recommend using a tool like Grammarly to double check your writing. Let us know, and we can set up an account for you to use.
Be sure to read client emails slowly and completely so that you are sure you address all their questions and concerns. It is easy to miss important details or comments after the end of a long quotation block.
It is usually best to include a time-zone when indicating times, however, in the absence of an accompanying time-zone, assume that times are in CST.
To retain flexible work schedules, we do not have a morning “standup” unless the client requests one. Instead, we post our progress in the #standup Slack channel.
The frequency and level of detail included in your standup messages should reflect the project and team members you are working with. If you are tightly collaborating with several people, daily standups may be worthwhile. If you are the only person working on a project, a weekly update is likely sufficient. Please post updates at least once each week. It is nice for everyone else on the team to be aware of your work. Even if nobody needs to know what you are working on, writing some details about your work is worthwhile. Doing so increases opportunities for collaboration by telling everyone what you are working on, what you are struggling with, and what technologies you are experienced with.
If you are working on more than one project at a time, then please provide details about which projects you worked on in during a given week or day. This will help project leads allocate time when billing our clients.
If team members or your project lead request that you post standups more frequently, please do it.
A typical standup should include:
- What you accomplished since your last update (if you didn’t accomplish what you said you would)
- What you hope to accomplish during this day (or week, or whatever time-period you post updates)
- Whether anyone is blocking your progress in a non-urgent way (if it is urgent, contact them directly).
Paid Time Off and Holidays
Members typically receive two weeks of paid time off during their first year, three weeks for their second and third year, and four weeks each year after that.
We also have Christmas Eve, Christmas Day, Thanksgiving Day, Black Friday, Memorial Day, July 4th, Labor Day and New Years Day off. If these Holidays fall on weekends, we observe them on the closest weekday. Please note that this list does not directly match the US federal holidays. For example, we do NOT observe Columbus day (a federal holiday), while we do observe Black Friday (not a federal holiday).
Notify your project lead in advance when you want to take a vacation, and be sure to request it using Gusto with as much notice as is possible.
One of the perks of working remotely is having a flexible work schedule. Because of this, sometimes we will take off during the week but will make it up over the weekend or in the evenings without taking vacation time. Taking off during the week depends on the demands of the project you are currently assigned to; for example, often we have client meetings during the week.
Payments and Compensation
We run payroll every two weeks. The last payroll of the year will include any annual bonuses. Payments are made using Gusto.
We have a 401(k) plan that allows for traditional and Roth contributions. We provide an automatic 3% of your salary to the plan whether or not you choose to invest. Our 401(k) plan provider is Guideline, and the plan has many low-fee mutual funds available. You become eligible to contribute to the plan after six months of employment.
No Health Insurance
We do not currently provide company health insurance.
Open Source Contributions
Each quarter we donate $500 to an open source project. We decide which project through discussions with everyone in the company. You can see previous projects we have donated to here.
Our information security policies are designed to help us protect:
- our client’s data and intellectual property,
- Innolitics’ data and intellectual property, and
- Protected Health Information which we may come into contact with during our work.
Failure to follow these policies may result in disciplinary action.
Health Information is information in any medium that originates from a provider, insurer, or other healthcare entity, and relates to physical or mental health, or to the billing for healthcare services.
Protected Health Information (PHI) means individually identifiable health information.
Electronic Protected Health Information (EPHI) means PHI stored or transmitted in electronic form (e.g., on a computer hard disk).
A breach is the actual or potential acquisition, access, use, or disclosure of PHI other than for approved uses.
A workstation is an electronic computing device, for example, a laptop or desktop computer or smartphone, or any other device that performs similar functions, and storage media connected to it.
A covered system is a workstation or server which may contain or store EPHI.
A covered connection is a connection between a covered workstation and a source of EPHI. The following are examples of covered connections:
- Support emails from a client containing EPHI
- Access to a client’s Dropbox accounts, which contains EPHI
- SSH access to a server within a client’s network; this server has access to an EMR (which contains EPHI)
Workforce members are employees, subcontracted staff, or others with roles that may interface with sensitive information.
A covered workforce member is an Innolitics workforce member who is able to make a covered connection.
A project lead is the Innolitics employee (typically a partner) who is managing a particular client project.
A security incident is a potential data breach or other possible compromise in the confidentiality, integrity, or availability of protected information.
A secure password is at least 8 characters long, is unique, is not repetitive, and either includes multiple types of characters or is very long. These are examples of good passwords:
ilovetowritehighqualitycode(is very long)
@B1heul!l1(uses special characters and numbers throughout)
These are examples of bad passwords:
hola123!(many people put special characters and numbers at the end)
@B1heul!l2(fine normally, unless you also use
Here are our policies for password management:
- Your LastPass master password must be secure and your account must be protected with multifactor authentication.
- Your company email password must be secure and your email account must be protected with multifactor authentication.
- Store all company passwords in LastPass, except your master and email passwords.
- Generate new passwords with LastPass meeting the minimum standards outlined above.
- Do not write down your email password or your master password, except possibly for a few days while you are ingraining them in your memory.
- Never share your master password or company email password with anyone.
- Share passwords using LastPass.
- Passwords which need to be shared for a particular project should have a shared project-specific folder.
- Software licenses, keys, and other especially sensitive information should be stored and shared using LastPass secure notes.
If you are unfamiliar with LastPass, these video tutorials are helpful.
Although we don’t typically look at it, LastPass keeps a log of when different people log in to different Innolitics LastPass accounts—so you may not want to add personal logins to your company LastPass account. Instead, we recommend setting up a personal LastPass account, and linking the two.
Email and Web Security
Before sending a message that contain sensitive information, double check that the recipient address is correct. It is helpful to mention in the message that the contents are sensitive and should not be shared with others.
Spear phishing is an increasingly common tactic that can result in a compromised account, web browser, or workstation. A spear phishing message can be disguised to see legitimate; often the links embedded in the message are designed to exploit a web browser, the attachment exploits the application that interprets it, or the email itself has a call to action to divulge information. Once exploited, a workstation might download a malware payload that can execute instructions defined by the attacker.
A bulletin was published by the US Department of Health and Human Services on the topic, if you are curious to see the guidance given to the healthcare industry in general.
There are a variety of pretext attacks on the web that are similar to phishing. Innolitics requires multiple layers of security controls to mitigate the risks of attacks like these.
All covered workstations and systems must implement the following security controls:
- Require a password, fingerprint, or facial recognition to log in,
- Automatically lock after an hour of inactivity,
- Encrypt internal storage at rest, and
- Automatically update operating system and application security patches, or are manually updated once each quarter, and
- Antimalware agents set to automatically update malware definitions.
If feasible, non-covered workstations should also be setup in this way. If you opt to use manual updates, we recommend setting a repeating reminder so you don’t forget.
Working with Sensitive Information
In order the limit the proliferation of sensitive information beyond the control of Innolitics and to meet our agreements with the data originator, sensitive information should only be stored and viewed on covered workstations. Before you start working with sensitive information on a new workstation, inform your project lead so that they can record details of the host for tracking purposes. We need to keep a record of where sensitive information is stored, so that we can be sure it gets deleted when no longer needed.
Innolitics requires the following practices when working with sensitive information:
- Only store EPHI information on covered workstations.
- Store the minimal amount to complete the tasks which require the sensitive information.
- Purge sensitive data from your workstation as soon as reasonably possible using the procedure below.
- When feasible, store all sensitive information in a single location on your workstation, so that it is easier to track and delete it when you are finished working with it.
- Exclude workspaces with sensitive data from any automatic backup utilities that copy the data to external devices or to a cloud service.
- Don’t store EPHI on external media such as external hard drives or USB drives.
- Don’t share EPHI in GitHub, Slack, Google Drive, iCloud, or other cloud services.
- Don’t share sensitive information with people outside of Innolitics or the client.
- Don’t share sensitive information with individuals within Innolitics unless necessary and approved to do so by your project lead.
- If you believe that sensitive information may have been breached, notify your project lead immediately.
Purging Sensitive Data
When finished with a project, it may no longer be necessary to retain information, and it is risky to hold on sensitive information longer than necessary. When you are sure that data are no longer needed, follow these guidelines to purge the files they cannot be inadvertently reconstructed.
- Use the GNU coreutils utility
shred -uto delete a filesystem handle and overwrite the data in the file multiple times.
- If storage cannot be purged locally, such as in a bucket on a cloud service, the best practice is to ensure the bucket is statically encrypted by the cloud service before data are written to it, then shred the decryption keys.
- If a covered system or workstation stops working while containing sensitive information, physically destroy the internal storage before disposing of the device.
We frequently use SSH to access remote servers. Here are policies regarding SSH:
- Use a different key pair on each workstation.
- Use a passphrase (it is fine if you use the same passphrase for all keys).
- Use an SSH agent when appropriate (e.g., when cloning a GitHub repository from a remote server).
Working in Public Places
Avoid working with sensitive information in a public place when feasible. If unavoidable, position your screen so that is not easily visible by others and be careful to lock your workstation before stepping away from it. Try not to leave your devices unattended.
When working on publicly shared internet connection, use a virtual private network service to tunnel your traffic through the untrusted connection. Tethering to a mobile phone is a more secure option.
Annual Training and Audits
If you work with EPHI, you will need to review these documents once each year and configure your devices to meet these security guidelines. Also, your project lead or Innolitics’ Security Officer will ask you a series of questions regarding how your devices are set up.
Coding Best Practices
Please read through our Coding Philosophy and Best Practices.
This handbook is intended to provide a general overview of the company’s policies and procedures. Nothing in this handbook is to be interpreted as a contract, expressed or implied.
We may revise, suspend, revoke, terminate, change or remove, prospectively or retroactively, any of the policies or procedures of the company, whether outlined in this handbook or elsewhere, in whole or in part, with or without notice at any time, at the company’s sole discretion.