Welcome onboard. This document will help you prepare your development environment step-by-step.
This should have been covered during your interview, but it is very important, so here is a reminder.
- happy clients
- high-quality code in the repository
That's it. It may be surprising that there is no "happy employees" entry on the list. That is because we don't assume that we know what makes people happy.
We use the Sociocracy 3.0 decision making process to give control over the environment to the company staff. They might choose, which sometimes they do, to use that power to change how the company works. That, in turn, might increase their happiness. This mechanism works surprisingly well.
Here you can find list of active agreements.
A developer working on a project must never discuss deadlines or give estimates (even rough) to a client. We have project managers for that. Why?
As it turns out, developers are usually overly optimistic in their estimates. They are also good people, at least the ones that we hire, so when a client politely asks if a developer can help him, the developer will usually agree. Delivering on such a promise is problematic and often stressful for everyone involved.
This is where project managers come in. They're particularly skilled at risk management, reducing the scope to what is really needed etc. Also, they enjoy talking to clients. Therefore, we let them take responsibility for the deadlines - they take care of developers' availability, risks, scheduling and so on. This way everyone is happier. Just to make it clear, if a developer ever provides an estimate or a deadline, it is considered to be invalid. The clients know this too, so they shouldn't ask and you shouldn't reply - just redirect them to a project manager or tell them you'll contact him/her yourself and produce an accurate estimate as soon as possible.
EDIT after 4 years: this rule served us really well, the only missed deadlines we had were caused by catastrophic unavailability of staff (due to a medical emergency, for example)
We avoid fixed-scope projects. The reason why is that we want to focus on the creation of software and not on amending contracts.
We will not accept a project targeted to manipulate people, to rip people off or put their savings at risk, such as insurance+retirement funds.
All data related to the company must be stored on encrypted media (usually in a virtual machine which has its image stored on an encrypted volume, but dual boot with full disk encryption is also allowed). This practice prevents potential data leaks, i.e. if your computer get stolen. There are a couple exceptions, you will read about them later on.
You should already have an email account in the reef.pl domain. Only ever use this email address (and the associated accounts) on secure environment (VM/dual boot) - this way your private and work accounts will never mix access or customer data.
2FA is mandatory everywhere it is possible to use it (more explanation below). We recommend Twilio's Authy because it has a pin code and e2e encrypted cloud backup.
The relatively high security level we keep allows us to work for financial institutions and, in general, institutions that treat their security seriously. Funny story moment: Pawel talked to a bank once, and they wanted him to work on site. Pawel described our security model and when he finished, an engineer from the bank said: "They have more security at their homes than we have at the office!". The manager looked at the engineer and he was not happy. ;)
UPDATE: A fully encrypted laptop of our senior developer has been stolen from his bag while he was on a train, returning from a conference in late 2017. Spooky.
Our clients really don't care how fast we type on our keyboards (in fact while on meetings we often don't touch the keyboard for an hour, getting a clean zero keystrokes per hour, delivering not only a very high amount of value per hour, but also infinite value per keystroke ;) ).
We employ several techniques to output a lot of value in a unit of time:
- Cut the backlog. Typically on the first meeting with the client 80-85% of the backlog is
removedpushed into a "future" version. - Re-use opensource things rather than write everything from scratch.
- Set up a new system with monitoring, error management, dh params, deployment etc in one hour. We don't like that part of the project so we invest in automation to minimize its impact.
- Design systems in such a way that they are easy to think about and implement.
- Design systems in such a way that they are durable and, whenever possible, self-healing.
- We prefer candidates who are not an order of magnitude slower than others. For example a program that reverts a small file can take like a minute to implement, but some of our candidates need more than 10 minutes. Someone might have a problem with this, but we don't hire the slowest developers on the market.
- If there is doubt on whether something should be done or not, we stop and ask. This theoretically increases Time To Market, but in practice it only does so on the last task of the iteration (so last task should be low-risk).
- We are allergic to waste. This drives many of our actions including good communication with the client who knows what must be done. While some software houses loose ~30% of their performance (due to misscommunications etc), we stay way below 5% (the exact number is hard to measure when the amount of waste is so low).
This guide will show how to set up a time tracking app.
It is not needed for recruitment assignments.
It is needed for trial period assignments.
The first step you need to take is to sign in to your new Google account at reef.pl. All the necessary information, including credentials, have been sent to your personal e-mail address.
Caution!
You should sign in for the first time from the host computer, as it is necessary to install the time-tracking application. This is the one and only situation when you are allowed to log in from your host machine.
Caution, again!
You have to set up 2-factor authentication within 24 hours from the first successful login, or the security policy will cut you off. It's best to set it up right after you perform the initial login.
We use an application that measures the time your spend at work and takes regular screenshots. The first step in preparing your work environment is to install it.
To avoid any issues with screenshot-grabbing and keep consistency across users, please install the tracker on your host machine. Please install it and then accept the invitation that you received on your email address.
You can download the application here: Hubstaff Tracker
If you ever wonder how Hubstaff calculates the activity levels, here is a handy link to their documentation (not that anyone looks on it, calls have 0% activity and we do them a few times per week, this metric is a bit impractical).
Here you can find time-tracking rules which were co-created by company staff members.
As it turns out, people usually find this document before they sign a contract with us and before their tracker account is created. Then they decide to work on their environment even before they have access to the tracker. If you are one of those people, please, track the time you spend on setting the encrypted partition, virtual machine etc, so that you know how much time it took and so that we can compensate you for this time as soon as you get access to the official company tracker. For example, you can use the free toptracker. We really, really don't like it when people work for us but are not getting paid for it.
UPDATE after 2 years or so: nobody seems to actually track it, but now that we have more data, we know it takes approximately 90 minutes to set everything up, so in worst case we can compensate based on that value.
Below you can find the list of RT projects alongside with their descriptions. The descriptions tell you where you should bill your RT time on hubstaff.
| Project | Description |
|---|---|
| RT / content marketing | writing articles or blog posts under company name; presenting the company to the outside world |
| RT / django cookiecutter template | modifying our internal django template |
| RT / internal infrastructure management | anything related to getting your workspace ready; creating encrypted partitions, installing vms or any software needed to work and not connected to any specific project. If it's related to any internal or external project then please bill the time on that project |
| RT / management | a project reserved for company management |
| RT / non-project meeting | phone calls and Slack conversations that are related to your work but not directly project-related |
| RT / virtual assistant | things related to organizing the equipment needed in the company (like laptops or any necessary office stuff or hardware) |
| RT / other internal development | spending time on improving internal infrastructure like onboarding, training or any other company related stuff that might be helpful for others |
| RT / pre-sales | any pre-work needed to be done before the contract is signed with the customer |
| RT / recruitment | time spent on actively recruiting other people |
| RT / sociocracy | for s3 meetings, but also for chatting on the channel and for tuners |
| RT / special assignment from CEO | bill like this only when specifically asked to |
| RT / onboarding | only during onboarding phase (going through training materials) |
| OTHER / just-in-case | this is in case you need to work on a project before you are assigned to it; in such case raise the problem to the management immediately and re-bill that time later to the proper project |
If you are working on any external project for a client, you should bill all your time spent on this project onto it. Knowledge gathering, environment preparation, actual programming, meetings or design. If you need to learn a framework, library or language in order to deliver value for the project, bill the learning to that project as well. If it took you a long time to learn a new skill, please mention it to our PM on that project - depending on the terms of the contract, a client may be eligible for a discount and it is the responsibility of the PM to manage that (but he won't be able to do his job well if you won't ever tell him anything ;) ).
Using Hubstaff TODOs only takes seconds to get right and there are a few reasons why we use it:
- On longer contracts sometimes the client would like to get an understanding of the cost of a particular feature when building another one in the future. Specifying which feature we are working on allows for easy aggregation of the time spent on its development and that allows the client to plan the future of their products to maximize the value
- One time we had a client who replaced us a vendor with us and he did not charge the user of the system for fixing the errors made by the previous vendor. Fair billing between our client and the user of the system was only possible because we logged the time appropriately.
- Sometimes we make a deal with a client to buy our a module we've built for them and opensource it, so that we can use it in the future. Ideally we'd predict that a module will be reusable before starting to work on it, but sometimes that comes as a hindsight.
- Sometimes a client decides to start a new company after something we've built becomes a success and in order to properly settle the development costs between the old client company and the new client company, we need to be able to make a report out of it.
- In Poland in some tax accounting modes there are different rates for development phase such as design, implementation, sysadmin work and coordination. Billing a feature and its development phase allows you to pay the proper taxes properly.
It may seem weird, but actually RT is not the only consulting business out there. Traditionally lawyers bill their clients per hour and nobody blinks an eye :)
In fact many software houses nowadays bill their clients by the hour. In consequence, the income generated by a staff member is (almost) directly proportional to the amount of hours they spend working on the client projects (ok it's a big simplification because how sales activity is organized, but I don't want to digress here). Now unfortunately in the age of remote work (especially after the pandemic when everyone thinks they can work remotely) it's regrettably clear that some people can concentrate on their work much better than others. What I mean is that while some people can output 35 hours per week of focused work, other people can only output 10-12h. It would not be totally fair to compensate both of those groups equally, right?
In the end it doesn't matter much - if you get paid by the hour, you do a certain amount of those hours in a year and then it's either divided equally into 12 installments or proportionally to the amount of work done in a given billing cycle. Assuning you earn at least slightly more than you spend and that you have some kind of a financial buffer, at the end of the year you'll end up with the same amount. In 2022Q2 we tried to open a position for a "full time" engagement with a fixed monthly payment model (which would automatically bonus people who perform well to make it fair, sort of like a liquidity pool)... But nobody was really interested and we took the job ad down.
Let me tell you a story.
One of our staff members worked from a room on the top floor of his 3 story house. A few times per day he wanted to get some tea 🍵, but the kitchen was downstairs, so he stopped the time tracker, walked down the squeaky wooden stairs, got to the kitchen, filled up the kettle, prepared a cup and a teabag while waiting for the kettle to boil the water, poured the hot water into the cup and waited for a few minutes for the tea to brew. He then removed the teabag from the cup and slowly walked up 3 flights of stairs. Started the timer and got back to work (well, sort of - that entire activity distracted him, so he needed to reload the task which he was working on to his short term memory before he could do actual development).
Later that day he has taken a look at his time log and realized he spent 15min on a tea break. It was not a very relaxing type of activity (trying not to burn himself with a hot liquid while going up stairs squeaky wooden stairs was not his favourite hobby) (actually his hobby was board games, but I digress).
Now, what's the moral of that story? Later that day he bought a kettle and installed it in his room. We could see it on video calls - he could reach behind his chair and start the kettle without loosing focus. Tea and cup were also there. That's like 30-45min extra more time per day spent on building something he loves to build. Python backends. This is why we are here. This is why you are here, am I right? Seriously, if you could choose between RT and a workplace optimized for "walking up squeaky wooden stairs while trying to not burn yourself with a hot liquid", what would you do?
(or maybe it was ☕? I don't remember)
Even if you'd only work for one client per billing period, you'd still log some time to RT / * and RTO / * projects and those are paid by the company and not by the client.
When you work on multiple projects, we want to know how much time was worked for which client, so that we can bill them for it appropriately. Billing a client inaccurately goes against a foundation of the company ("happy clients", see above).
After the end of a billing cycle (typically 1st day of a month) we semi-automatically calculate the invoice amounts for everyone. The polish tax system got way more complicated than it used to be in 2022 and lawful accounting of the optimal tax mode requires detailed time logs, which we then help our staff follow with automation.
Sometimes the work doesn't go as well as it should for an amount of time that cannot be ignored. If you have logs from the tracker that clearly show you've been working on the project, then it is a good thing. The client doesn't see us work in their office, so if there are no results, it is difficult to say whether someone is working hard but struggling with a challenge, or whether somoene is not trying hard enough.
As of writing this, the number of times the tracker was instrumental in preventing a rapid degradation of a relationship with a customer is: 5.
UPDATE: this counter stopped incrementing in mid 2018, when we changed the target client group. It seems that "better" clients don't really care about the time, but they do care about results. CEO even wanted to disable the screenshot feature of the tracker in early 2020, but others said they use it to inspect their own diary at the end of the day and after a short discussion everyone said they don't really care about it so we just left it as it was. It seems that nobody has reviewed a screenshot since July 2018, except for people reviewing their own thing at the end of the day. Being able to easily recover from a situation where you have accidentally billed a client for doing something private (as you forgot to pause the timer) is nice and in line with the company values.
Once you have installed the time-tracking app, it's time to prepare your environment.
This guide will show how to set up a standard, secure environment for software development.
It is not needed for recruitment assignments.
It may be needed for later trial period assignments. Usually, it is mandatory, unless the trial period assignment is an open-source project and there is nothing to hide. If in doubt, ask the person who is giving you the task.
Due to the variety of operating systems used by our team, we do not impose a specific solution. It depends on what software you use. For Linux systems it can be LUKS. For MacOS you can use built-in FileVault encryption.
Due to the large space utilization of our projects, the minimum partition size is 50 GB (recommended size: 100 GB).
In case you have no preferences, we recommend using VeraCrypt. A step-by-step instruction for the installation process can be found here.
It is allowed to use a non-virtual machine for work purposes (via dual boot or separate physical machine). This is not very common and if you are considering setting it up, you probably don't need detailed instructions, so the rest of the guide will show how to build a VM environment.
As with encryption software, we do not have specific requirements for what kind of solution you will use. The only requirement is the license. We recommend VirtualBox.
To maintain consistency across all virtual machines, we use the Linux Mint distribution. We would like you to work on this system, too. This will help us save time in the future.
A step-by-step guide to creating a virtual machine can be found here.
You will need the following packages to work:
$ sudo apt install \
docker.io \
docker-compose \
git \
python3-pip \
python3-setuptools \
python3-virtualenv \
direnv$ sudo pip3 install virtualenvwrapperFirst, generate an SSH key. We use Ed25519 which is more secure than the default RSA key. We provided a simple script that will do all the work for you.
Just download it from this repository and run it:
$ ./configure-keychain.shCopy the .gitconfig file included in this repository into your home directory:
$ cp .gitconfig ~/Complete username and email:
$ git config --global user.name "Name Surname"
$ git config --global user.email [email protected]Copy the .bashrc file into your home directory.
$ cp .bashrc ~/In order for this to take effect, relog your shell or run . .bashrc
Add your user to the docker group:
$ sudo gpasswd -a $USER dockerNote: For ease of use, an alias ** dc ** for docker-compose is added to the .bashrc file. Instead of typing a full name, you can use the shortened version.
Example:
$ dc upSince you've already configured your virtual machine, any logon to company accounts is done through the VM.
To improve the security of our accounts, we require you to enable 2-step verification.
Google's 2-step authorization setup
Create a new account on GitHub. The suggested username is the first letter of your first name and your full last name, and the suffix -reef, eg. jkowalski-reef or asmith-reef.
2-step authorization should be enabled as well. If you don't enable it (or if you disable it - which is crazy, but technically possible), a periodic audit will catch you and you will make the auditor very sad.
GitHub's 2-step authorization setup
Go here and select watching. This will send you an email whenever this repository is updated. This is useful to keep up with the training video/article list, description of chat channels and meaning of projects in the time tracker.
WARNING: if the document was updated after you started reading it and before you set the repository to watched, you could miss an update. Check the latest changes here after subscribing to updates.
Please add your photo (one that shows your face clearly without sunglasses etc) to all services that we use: Slack, Github, time tracker, Trello, Atlassian account etc. It is recommended to add it to gravatar, then It will load up automatically to many services. Avatars are important, especially on non-small teams, but also everywhere in context of communication with the client (or ourselves), where we want to be recognized as human beings rather than lines of text. Cultural differences, timezones and language barriers make communication a challenge - lets make it at least slightly easier by showing a smiling face to the client and his team.
Why no sunglasses? Please imagine the company in a few years, where almost every avatar on slack looks the same: either a sunglassed person or a 10-pixel high character on the top or bottom of a mountain. That won't work. Therefore we should all use clear pictures from the beginning.
We use simple hand signals during video calls to communicate more efficiently.
| sign | meaning | context |
|---|---|---|
| ✊ | pass (no comment) | moderated discussion |
| ☝️ | request voice | moderated discussion |
| 👍 | vote "consent" | S3 decision making |
| hand with palm down | vote "concern" | S3 decision making |
| hand with palm up | vote "protest" | S3 decision making |
| 👋 | ready to disconnect the call | call coming to an end |
When we're trying to make a decision or closing the call, everyone holds their sign until everyone shows a sign of their choice. This way, the situation is clear at a glance. In the past, we used to show signs for a moment, but then the quick responders hid their signals before the slow ones started signing and the situation was not clear. Now we all hold the sign until we're sure of the consent.
When you need to contact one of your Reef teammates, you have three channels to choose from: Slack, text message, and phone call.
First, we try to connect via Slack. Then, you can attempt a phone call and finally a text message or the other way around: a text message and then a phone call. Everyone has a description "phone -> SMS" or "SMS -> phone" under their avatar on Slack. Please choose which sequence suits you better, and we will respect it. We expect you to respect our contact preferences too.
We don't really use email for communications, as some people don't check it too often. If you need to be sure that someone sees your email, ping them on Slack.
For business communications, we use Slack and Zoom. You may use them in your browser, but they are usually installed on the host computer for convenience. Zoom usually doesn't work from an encrypted VM (no audio or video) - perhaps it's possible to perform some extra setup steps to make it work, but it's not worth it.
In your company e-mail inbox, you will find a message with an invitation to the Slack team reeftechnologies.slack.com. Right after signing in, remember to fill out the phone number field in your account settings. Remember to add your country-specific prefix number, e.g., Poland uses +48. It's essential, as our members come from many different countries. Also, remember to place your chosen sequence under your picture: "phone -> SMS" or "SMS -> phone".
Replying with a 👍 reaction is better than writing "ok" (especially when there are many acknowledgers on the channel!) - reactions prevent half of the conversation from being filled with meaningless messages like "ok" / "right" / "I see". If you want to quickly acknowledge a Slack message, you can use ctrl+shift+\, 1, enter.
Using the desktop Slack application has a benefit of marking you as "available" on all the Slack servers. If you use a browser, you are only shown as available on the tab that you currently have open on your screen. Therefore, you should use the desktop application, not the browser. This may impact on how the client percives availability of the team (if he never sees us online, it's not so good).
Channels:
#announcements- the general announcement channel, where we mostly welcome new people and announce our vacation periods to others#default- the default channel (if there is no dedicated channel for something, we use this one)management- senior non-technical management discussions (hiring etc)#opensource-candidates- for discussions on what the open-source budget should go to#opensource-operations- the channel for open-source project development#python- where we sometimes discuss things such as the usage of walrus operator (:=) or if it is better to useraiseorraise e(as not everyone speaks Python on #default)#random- all topics not directly related to work. If you read something interesting, don't hesitate to share it with us.#sales- sales team sends notifications there about high quality leads, signed/terminated contracts etc.#security- for things like heartbleed, shellshock, krack, poodle, venom, ghost, meltdown/spectresociocracy- the channel where sociocracy is coordinated (TODO: link to our S3 resources)staff- internal staff channelva- for delegating things to Virtual Assistants#website- discussion about our company website and its development
(private channel names don't start with a #)
The remaining channels are client- or project-specific. Only the people involved in those projects get invited to the channels (for IP compartmentalization).
Slack's 2-step authorization setup
Do not forget to say hello to us on #random :)
Here are some miscellaneous rules to follow that were hard to put in some other categories, so they were all collected here:
- When a meeting starts, decide where to bill it.
- If you are a junior and you get stuck - ask for help. Really, really, really do. Do not spend two days trying to solve something a senior peer could help you go through in 10 minutes. Ask on the project Slack and if that's not possible, use our
#defaultchannel. - If you are a developer, always perform basic functional testing (manually!) of your code and self-review your PR before you give it to a peer for review.
- If there is ever a time when you are working, but for some reason, you are not able to bill it, escalate it immediately. We want to avoid such incidents.
- It is forbidden to transfer any client data through a non-encrypted channel. Use https and ssh tunnels when necessary.
- It is forbidden to store client data on a non-encrypted device. Use fully encrypted systems (or virtual machines with images stored on encrypted partitions, where the host machine has a disabled swap file, or where swap is encrypted).
- Try to avoid task switching, especially project switching. Generally, we do our best to switch only on "breakpoints", which are the moments when you lose concentration on the task at hand, such as the end of the working day, going away for lunch, the end of a task. Thus, if a new task appears on a high priority project, we do not expect you to switch to it immediately, but rather after you finish what you are doing, or first thing next day, etc. Usually, you should have at most one project switch per day.
- Avoid
ssh -A, also calledForwardAgent(except for jb). If we use it on a server owned by a client and it gets hacked, someone could potentially set a trap for us and authorize using our key. The better way is to use deployment keys on the client server to access the repository. - Do not use the company email for RSS, out of work stuff etc. That is to minimize distractions, which is pretty important for us.
- If you issue an invoice to the company, please prefix the name of the file with your surname. This makes things much easier to find for the staff members who are dealing with a few dozen invoices every month.
- If your changes are not ready to be submitted at the end of your work day, make a dirty branch, commit all of your changes to it (typically
git commit -am'WIP') and push it to a remote. This way if your HDD is damaged or something, you will never lose more than a day of work.
If any of the above is not clear, not optimal, or you are curious about the rationale behind a rule, speak up on #default.
If there is a conference that you'd like to attend, and we agree that your attendance would be valuable for the company:
- The company will fund your conference ticket;
- The company will fund your train/bus/airplane ticket;
- The company will fund your stay if the price is reasonable (AirBnB seems to lead here, but we often use a booking.com bed&breakfast option);
- The company will not pay for the time spent at the conference.
Please follow these guidelines when copying code:
- Please mention the license of the source code which is copied
We typically follow the conventions listed below. Not always. The list seems long, but it really isn't.
Why is this list here, you may ask - don't all RT developers follow all of those subconciously? Usually yes, but some of our trial candidates said it would be easier for them if they could look at the list, so we wrote it down out of respect for them.
Described here. We break it when doing advanced indexing, but we adhere to 1NF until we can't get the desired result using basic indexing.
Described here. We adhere to it pretty closely, you won't find much of copied code in our repos (with one notable exception, it's a long story).
Described here. We follow the first 5, not sure about the others.
Described here. Not as well known as the others.
Described here. There are many such conventions, but this is the one we use. It's pretty straightforward.
https://blog.cloudflare.com/pipefail-how-a-missing-shell-option-slowed-cloudflare-down/
Because we want an option to switch to 3.9-nogil. This can be dropped very easily, but please mention it beforehand.
Described here
Described here
Described here. We try to use it at least for all new public functions.
As above - it should be possible to use stuff without reading its code.
https://peps.python.org/pep-0008/
See here. We skip it after **kwargs as no argument will ever follow it.
https://sipb.mit.edu/doc/safe-shell/
See the next section
Whenever someone would like to use a pattern listed below, we have decided that they will get an opinion from a design reviewer before writing the code. The restricted technologies are:
- Django GFK (generic foreign key)
- Django signals (please note that
transaction.on_commit()hook is NOT a signal) - Writing to
self.__class__ atexit.register()(usetry: ... finally: ...instead)- Defaults for environment variables in
settings.py(all defaults should be defined indev/.env.templateandprod/.env.template) - By default, one should always use
BIGINTfor primary key field, unless there are special reasons to use other type.
The reasoning behind this is that we usually prefer for the code to be structured differently and it's better to discuss this before implementation and not after. All of those technologies have their uses in good cases, but what we found is that often the alternative is more elegant, so in order to limit the amount of rewritten code, in those cases we choose to review the design before implementation. Design review is generally welcome and can save a lot of time, but in this case we have unanimously agreed it will be mandatory.
See also: https://github.com/reef-technologies/python-review-zoo/
Whenever you're taking some days off, it's important to let other team members know, so that work can be planned and client expectations managed.
- You should mark days when you won't be working in GSheet 'Work planning' as soon as you know about it.
- If you need time off urgently because of something unexpected, please let others know in Slack in
#annoucementschannel right away, but ignore it completely if it's a life-and-death situation. Don't worry, we'll manage. Family first 👪 - If it's some time you're planning to take off in the future, please mention that on a status call.
The "srm" tool which securely deletes data. We use it to wipe the repos (despite encryption).
apt-get install secure-deleteYou can use following command to delete directory:
srm -fllz -r -v <directory>
(you can skip -r for single file or -v if you don't care about verbosity - -fllz is the fastest possible way to run srm and it is safe due to encrypted drive and also modern ways of storing data in hard drives - default full Gutmann method is not needed)
To remove the docker containers created while working on a project, please use the following command (get "dockerkill.sh" from the bin directory of this repo):
./dockerkill.sh <container-name>It's like an office manager for a company that doesn't have an office.
Typically github actions.
In case you ever bill the time worked to the wrong project, here is a step-by-step guide on how to fix it.
Pawel: Let me tell you a story. There was a Python office in Warsaw where most employees were from Poland, but eventually, the company started hiring foreigners, too. They could not understand the kitchen conversations, which was awkward for both sides, so a new rule was introduced. Everyone was supposed to switch to English as soon as a foreigner entered the room.
One day, a foreigner walked through the corridor and overheard laughter in the kitchen. As soon as he entered the room, however, everyone went silent. Turns out that switching the language mid-conversation is not an effortless task. In that company, foreigners suffered from discrimination every day. They were excluded from gossip, and whenever they entered the room, any conversation was likely to come to a halt.
The first time we had a foreigner join us for a few days, we switched to English and just haven't switched back. If we did, the next foreigner joining the company could be a source of resentment. There would also be a problem with chat history. One of the things we proudly offer to our staff members is respect. I like to think that by keeping communications in English, we show respect to the person that will join the company at some time in the future. We want as little friction as possible.
UPDATE: We now have several staff members who don't know a word of Polish, so the story above is no longer relevant for explaining why we communicate in English... but I am leaving it here because it shows a part of our culture: it's ok for all of us to be slightly inconvenienced to make sure that we properly respect another staff member (even when he or she does not exist yet). I wish I snapped a photo of our CFO when I told her why we logged the time for internal activities in quite a lot of detail for the last 5 years. We knew a day will come when someone will try to analyze how internal company operations evolved over time. It was for her.
If you find that some key knowledge (not covered by the NDA) that might useful for the next candidate is missing from this document, please create a pull request. Log the time spend on this to RT / other internal development.
You've done all the things you need to get started. Good luck!
Now head on to training!
from __future__ import annotations
from dataclasses import dataclass
from typing import Optional
@dataclass
class Benefit:
brief_description: str
extended_description: Optional[str] = None
def __str__(self) -> str:
if self.extended_description is not None:
return f'{self.brief_description}: {self.extended_description}'
return self.brief_description
@dataclass
class Project:
__slots__ = ('brief_description', 'location')
brief_description: str
location: str
def __str__(self) -> str:
return f'{self.brief_description} from {self.location}'
@dataclass
class Dev:
name: str
years_of_programming: int = 7
loves_python: bool = True
def __str__(self) -> str:
return self.name
@dataclass
class Company:
name: str
info: dict[str, str]
benefits: list[Benefit]
projects: list[Project]
job_ad: str
def invite(self, dev: Dev) -> None:
print('#' * 40)
print(f"We'd love to see you work here at {self.name}, {dev}!")
for what in ('benefits', 'projects'):
self.brief(what)
print(f'\nPlease join us at: {self.job_ad}\n')
def brief(self, what: str) -> None:
print(f'\nHere are the example {what} of working at {self.name}:')
for idx, benefit in enumerate(getattr(self, what), start=1):
print(f'{idx}. {benefit}')
if __name__ == '__main__':
INFO = {
'industry': 'IT',
'field': 'backend',
'language': 'python',
'work_model': 'fully remote',
'level': 'senior only',
'hiring': 'yes',
}
BENEFITS = [
Benefit('remote work'),
Benefit('asynchronicity', 'work whenever you like'),
Benefit('coworking cost support'),
Benefit('hardware cost support'),
Benefit('private assistant'),
Benefit('budget for tools'),
Benefit('sociocracy', 'we make decisions together'),
Benefit('no calls on Mondays'),
]
PROJECTS = [
Project('sales data analysis tool for a fintech company', 'Chicago, IL'),
Project('paper product level tracker for toilet cleaners', 'Canada'),
Project('AI video content analyzer/searcher for drone pilots', 'Detroit, MI'),
Project('two e-commerce applications for a customer', 'Washington, DC'),
Project('hydrant certification report generator', 'Australian plumbers'),
]
reef_technologies = Company(
name='Reef Technologies',
info=INFO,
benefits=BENEFITS,
projects=PROJECTS,
job_ad='https://careers.reef.pl',
)
name = input('Your Name: ')
years_of_programming = int(input('Years of Programming Experience: '))
loves_python = input('Do you love Python? (yes/no): ').lower() == 'yes'
you = Dev(
name=name,
years_of_programming=years_of_programming,
loves_python=loves_python,
)
MIN_EXP = 5
if you.years_of_programming >= MIN_EXP and you.loves_python:
reef_technologies.invite(you)
else:
print(
f'Our job requires at least {MIN_EXP} years of programming experience and some python love'
)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent