Who we are
- People, not processes nor code, are the most important thing in software engineering.
- The client should always be aware of what is happening, be it good or bad.
- There is no such thing as the best language or an only way to do things. Each project is unique, and requires its own tools.
- Code should be clean and tested so programmers feel happy and confident to work on it.
- Refactoring is a recurrent need and should be regarded as any feature in the backlog.
- Because of the above, automated tests are a must. As long as you write them, choose whatever process you like the most.
- Code should be deployed early and often.
- Simple beats complex.
- However complex it is, there is always a simple way to explain it so everyone can understand.
- Community is one of the most important features of a programming language, keep this in mind when choosing one.
- Open source is tremendous. Make the most of it and remember to give it back whenever possible.
- To keep a welcoming, safe, and healthy workplace so we all exchange experiences.
- To fight for mutual respect among everyone in the company regardless of gender, political position, sexual orientation, religious choice and race, so we all see one another as equals.
- To aid anyone to approve talks and attend conferences, so we all share what we’ve come to learn.
- To encourage open source contributions, so everyone, regardless if we know them or not, grows together.
- To provide tooling and an environment that fosters growth and sharing.
- A humble attitude to recognize failures, and the will to improve when they happen.
- Tolerance towards failure and sustained improvement.
- Open mindedness for learning and self-improvement.
Things we will not tolerate
- Any kind of racism.
- Any kind of sexism.
- Any kind of prejudice.
At Vinta, we value good work-life balance for everyone. This means work should happen within working hours and when it's over, we should disconnect from work-related duties and focus on ourselves and the ones we love. The only exceptions are on-call ours that are negotiated beforehand, and rare emergencies. Turning off from work is essential for good work. We produce our best when we are relaxed and well-rested. Designing and programming software are both highly technical and creative activities. A stressed mind does not produce good creative work. It will also fail to assess risk and correctly apply the techniques required for a well-thought product.
We are a team of elite consultants. We do highly specialized work. We are always pushing ourselves to improve our processes, software, and design practices. We are continuously questioning everything we do. We will not settle for average work. We will take all information in our hands and produce great software that best suits our customers' needs. We will proudly sign every screen mockup and every HTML tag sent to peoples' web browser.
We are accountable for the software we deliver. We will be transparent and warn about risks. We will communicate clearly. And if something breaks, we will provide the best possible support experience to our customers. We will assess the issue and provide a timely fix. We will report what went wrong, learn from each experience, and take measures to ensure we don't fall for the same errors again.
One might think that it's impossible to provide this kind of exceptional support and ensure everyone has a good work-life balance. After all, if we need to fix things when they break, it means that we might need to work during the weekend. Well, yes, that's true. But the reason for that is that we are accountable for the work we do, and the work we do goes far beyond the features users interact with. Design decisions, architecture decisions, code quality, quality assurance, integration tests, unit tests, manual tests, active monitoring, user docs, software docs, design docs, process docs, logging, metrics, infrastructure monitoring, feature toggles, code review, agile methodologies. Those are the things that will allow us to be highly accountable for our products while maintaining a good work-life balance.
But beyond all of that, this is not just about one's well-being. Every time you are forgiving while reviewing a pull request, every test you don't do because it's time-consuming, every piece of doc you don't write, and every technical debt you let go, you are risking your teammates' work-life balance. We never know what or where things will break, and we never know who will be the person that will need to say “excuse me” to friends/family and investigate what is going on.
Vinta cares about everyone's well being, and we expect that everyone is also looking out for each other. We founded Vinta because we validated it’s possible to make great software with work-life balance. That’s why we’ll always be very vocal about the importance of the consultant posture and all quality-related processes we have. Make sure that your work will allow you and your teammates to have a good work-life balance. The great news is that, by doing this, you will automatically be doing an elite level job and ensuring happy customers.
One of the main value propositions Vinta has for employees is an environment that seeks constant improvement. This means that the company is always questioning the way we do things and looking for where things can be done better or more efficiently. But it also means we are continually pushing everyone to grow. A business can only be as good as the collective sum of the people that makes it. This is especially true for a consultancy business, and it's particularly crucial to Vinta because our goal is to be a team of experts that values communication and transparency with our customers.
Some of the tools we have to help us in this process of growing people are: our mentoring program, our internship program, our feedback culture, our processes and documentation, career plans, internal talks, the references channel, our playbook, and our pairing culture. Those are all extremely important and have helped us a lot along the way. But helping people to grow in their career is something that traces back to the very beginning of the company, before we even had any of the tools mentioned above. How did we do it?
Above any process or tool, the thing that in our experience is most effective in taking people to the next level is the psychological safety to learn from mistakes. Vinta was founded by people almost straight out of college and with very little market experience. Everything we did was a combination of studying and a process of trial and error. That's how we learned how to make sales, hire people, and build great products. This is the same principle we employed to train the first people in the company. Whenever someone faced a new challenge, we enabled the tools people needed to gain the knowledge required for the task and did our best to assess risk and set up safety nets for the case of failure.
We believe in learning by doing.
Book knowledge is fundamental, but it's only effective if combined with practical exercising. That's why we are continually looking for opportunities to expose people to things they are not yet experienced with. The fastest-growing people in the company did it by seeking these opportunities and using them in their favor.
We know this is hard.
We understand that each person has a different learning pace and that some are less averse to risk than others. And this is fine. It's ok to go in the speed you are comfortable with. At the same time that we want everyone to grow as fast as possible, we also want to make sure this happens sustainably. It's not beneficial for the person or the company if they burn out in the process of going beyond of what they can handle. As usual, the best way to make this work is through communication. We will always be clear about our expectations, and we want to hear from people if these expectations are reasonable or if there's some other path they rather try.
Summing this all up:
Leaders: we expect you to build safe environments where people can get exposed to experiences they are not yet used to. And we expect you to do everything in your hands to provide a safety net for when things don't go according to the plan. The key here is to allow people to fly by themselves while constantly assessing risk.
Everyone: we expect you to look for challenges that will allow you to gain experience and grow and that you will be vocal about the things you want to learn so that we can do our best to create opportunities for you. We also expect you to communicate with your leaders whenever you are not feeling comfortable with the pace things are going or the level of the challenges you are being exposed to.
"One of our difficulties will be the maintenance of an appropriate discipline so that we do not lose track of what we are doing." - Alan Turing, 1947, talking about the ACE computer in a lecture to the London Mathematical Society.
The routine of a small restaurant chef might look something like this:
- Wake up early in the morning and go to the market to handpick the freshest available ingredients.
- Spend the afternoon washing vegetables, cutting the ingredients, and making sure everything is ready for the day.
- In the evening, before customers arrive, she probably inspects the table setups to make sure everything looks beautiful and clean. She also makes sure all the knives and pans are ready for when she starts cooking.
- As customers arrive, she cooks ingredients in a particular order and quantity, waiting the appropriate amount of time to extract the maximum flavor and the correct texture.
- She finishes each meal by assembling everything in a pleasantly looking way.
- At the end of the day, she ensures everything is cleaned up and ready for the next day.
Now, what happens if the chef wakes up late and all the fresh vegetables are already sold out? Would she still be able to cook? What if the table cloths are a bit dirty? Would customers notice? Would it hurt if she didn’t invest that much in making the dishes looking beautiful? In case any part of her routine goes bad, would she still be a chef? Yes, of course! Would customers have the same restaurant experience? I’m sure they wouldn’t!
Every profession has a set of practices that, although not mandatory, are extremely important if you want to ensure exceptional results. Could a surgeon perform surgery if she was not extremely careful with asepsis? At the risk of contaminating her patient, she sure would be able to perform her job. And even if she never washed her hands there’s a reasonable [but low] chance that she performs surgeries for her whole life and never harms a patient.
The same applies to software products. It’s possible to develop software that works (just like an ugly meal would still feed you) but if you want to build great design and write great software there are some practices that will set you up for success. These practices are often referred to as discipline.
Technique vs. Process vs. Discipline
Technique describes how to execute an activity given a certain set of constraints (such as the available tools). Eg.: how to cut tomatoes using a chef’s knife. Process defines a plan on how and when things are going to get executed. It might or might not give away what are the techniques that are expected to be employed. While process and technique are often enforced, discipline needs to be nurtured from within us. It’s possible to assess that a meal tastes delicious but it’s [the cook’s] discipline that ensures vegetables were cleaned before they were cooked.
Discipline are practices that are often hard to acquire. Until you haven’t got used to and made them part of your day to day, they will seem like a burden. They will require an active effort to change your modus operandi and you will often only recognize the benefits of them once they’ve become natural.
Ownership, Risk, and Professionalism
Something that is commonly misunderstood is who is accountable for the discipline and Robert Martin reasons clearly about it:
You cannot go to the business and say: "Can we write tests?". […] Because when you do that, you are trying to shed the risk. You are not willing to take the risk, [so] you put it on the business and the business cannot evaluate that and take the risk, so of course they will deny it.
And he goes on:
The risk, frankly, is our to take, we own that risk, that is us. We are the ones who know that things need to be tested, we are the ones who know that things need to be refactored, we are the ones who know how to get software done so we have to take the risk as part on our normal professional operation.
Applying this to our previous examples, you will notice that although it’s up to the hospital managers and the restaurant owner to set up the appropriate tooling and work environment, there are many parts of the job of the surgeon and the chef that the business either don’t know about or cannot enforce. It’s up to each individual (each professional if you may) to execute them. Discipline implies professionalism.
Some examples of things related to building software products fall into this "discipline" umbrela: testing (and TDD), documentation, refactoring, quality.
Underlying Benefits of Software Discipline
Allowing software to be … software
The very nature of software is to be changed. Changing is the reason why it was created, that’s why we call it soft-ware. Change is what differs it from hard-ware. If we build software that is hard to change we are defeating its purpose! That’s why we need well-thought architecture, that’s why we need tests and TDD! We need to feel safe to change things without risking (or at least with the least possible risk of) breaking things. If this is not baked in how we perform our work there’s no way we can consistently deliver changeable software (good software!).
Discipline enables software that is more reliable, has fewer bugs, is easier to change and that is more pleasant to work with. In the long run, this will all allow us to deliver repeatedly and consistently.
Discipline enables trust. If people know that you apply good practices and deliver consistently, they will trust you even when you eventually fail. They will know that it was probably due to something that you could not control and are more likely to empathize with you. This applies to our customers, our users, our teammates, and also to your individual careers.
The Agile Manifesto
Last but not least, it’s important to highlight that the Agile Manifesto is all about discipline. While Scrum and Kanban are processes (they document step by step what to do and how to do it), notice how the Agile Manifesto sounds more like a list of oaths, a pact we make with ourselves and our peers:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation;
- Responding to change over following a plan;
The only way to learn discipline is by doing it. Practice it over and over until it’s naturally part of your routine. Talk to your project leaders and mentors, they will be able to help you. And remember there’s no finish line, there’s always something to learn or to improve. Discipline yourself to keep growing!
Mentorship is a big investment but it pays off! We do it because we want to create long-lasting relationships and because we want people to stay in the company for a long time. Mentorship programs are one of the many ways we have to connect people and provide structured guidelines, align expectations and boost career growth. Even tiny gains someone gets from investing time on mentorship compound and produce great improvements in the long run!
- Accelerate career growth;
- Provide a more human interface to bring people closer to the company;
- Guide people through company structure and culture;
- Collect feedback, discontentment, and suggestions;
The first meeting
Use the first meeting you have with a mentee/mentor to do a quick presentation to each other about yourself, your career, your experience with Vinta, and the things you like and dislike. It’s important that mentor and mentee create a connection and a relationship of trust.
Make it recurrent by default
It’s a good idea to schedule periodic recurrent meetings. Do not rely on someone having to book a meeting when they feel it’s time. Pick a day and make the event recurrent. It’s OK if you have to reschedule or even cancel a meeting, but it should be an “opt-out” action. The minimum frequency should be once per month and the maximum once every two weeks.
Have a rolling agenda
It’s a good idea to have a shared document between mentor and mentee in which both track what was discussed during the meetings and also add topics to be discussed in the next one. Both mentee and mentor should create the habit of adding topics to the agenda as soon as they think about them. But the mentee is the one responsible for maintaining and proposing the main topics to discuss, as mentorship is not management.
Bring your experiences
Mentees need to develop autonomy and bring their experiences to be discussed as a meeting agenda. But sometimes it's hard for the person to understand what that means in practice. In these cases, the mentors should bring their own experiences. People need to be taught autonomy, not only blamed for the lack of it.
One of the main benefits of mentoring is that you get to be personal. At that moment you are not trying to solve problems for a group of people (which is often the case in our day-to-day project activities), you can concentrate and provide advice and solutions for that single person in a very particular context. Be creative and craft one-of solutions.
Help mentees navigating the company
As a mentor, you should help your mentee navigate the company processes, practices, departments, etc., especially if they are new hires. When the mentee discusses a problem or an expectation, don’t immediately address it. Instead, try to foster proactivity on the mentee to use existing processes to look for the solution or to provide feedback, by doing for example:
- Contact with POPs;
- Scheduling office hours or a skip-level meeting with one of the leaders, Managers, CSO, CTO, CEO, etc;
- Checking existing feedback or request forms;
- Checking existing processes.
- Prefer written over verbal communication;
- If you need speed, consider talking to people;
- If written communication is generating misalignment or provoking excessive back and forth, consider calling a meeting;
- Slack should be used for sync communication and information there should be treated as volatile;
- All decisions taken over Slack or meetings should be consolidated in a written, long lasting form (Confluence, Asana, …);
- On Slack, consider the content of the message and the channel you are sending it to avoid generating noise;
- When it makes sense, consider creating a separate group channel with only the people that should receive the message;
- For longer discussions, prefer using threads;
- It’s expected that you respond to Slack messages within 30 minutes during business hours. If you’re in meetings it’s comprehensible that you take longer than 30 minutes to respond;
- The expected response time on async tools such as Confluence and Asana is 24h;
- If you feel that you’re technically blocked for more than one hour, ask for help. Check the Team Profiles page to find who can help you best. If you still don’t know who to ask for help, ask your project’s TL;
- If you need help on a task schedule a pairing session with anyone on the team. Remember to look at their calendar for availability. Send a heads-up on Slack after scheduling;
- Your project leaders are available to help you with your tasks, but also for career advising and to solve conflicts, do reach them;
Security is not something you can do every once in a while, it's a mindset that needs to be baked into your day to day job. It's impossible to ensure a system or an organization has zero risk of having a security flaw, so the best way to reduce the odds of having an issue is to educate ourselves on how security works, what are the risks and how to defend ourselves and our applications from attacks. Here is an overview of these topics for you to start thinking about security.
A system is as secure as its weakest component
Attackers often don't need a big flaw in the main system in order to gain access to critical resources of the system. In reality these attacks often start from less important side components of the system exactly because they are often not monitored and carelessly designed. But starting from these seemingly unimportant components attackers can pave their way to the core of application.
Security flaws often don't come from software, sometimes the weakest component in the system are the people working on it. Attackers might use email messages and even call people in the organization impersonating employees or even saying that they are doing something for someone you know from the company. This is one of the hardest threats to defend from because it's impossible to predict all the ways a social engineering attack can be crafted. The only way to protect yourself from these is to keep constantly suspicious of the messages you receive. Always double check via phone or a different communication medium than the one you got the message before responding to unusual or potentially critical requests.
Phishing is a cybercrime in which a target or targets are contacted by email, telephone or text message by someone posing as a legitimate institution to lure individuals into providing sensitive data such as personally identifiable information, banking and credit card details, and passwords. - What is phishing
Phishing are most commonly email messages that appear to have a trusted source but in reality have fake links. These links often take you to a page that also looks official but will actually collect any information you input and use it for malicious purposes or exploit flaws on user's devices. The only way to overcome it is to always be suspicious of the messages you receive and double check everything before answering or clicking anything in it. Here are a few practices that will reduce your chances of getting hacked by a phishing attack:
- Check who is the sender of the email, specially if it's from outside of the organization;
- Confirm the email address is from a domain you trust (beware of domain name phishing, eg.: phishng.com instead of http://phishing.com);
- Never click on any links, always copy paste it on the browser and double check the domain;
Another common attack are messages from people that claim to possess some personal or company information and threaten to leak it in case you don't pay a certain amount of money. Although it's possible that the leak is true, most often those are fake claims from people trying to make a quick buck from a leaked email list. In case you receive a message like this, make sure you report it to the company leadership so actions can be taken on a per case basis.
Work equipment is one of the main targets for attackers looking for a breach. Project source code, communication tools and infrastructure access keys are all stored in these machines making them very attractive to hackers. With access to these things it's much easier to pave the way for critical components of the system so we need to be extremely careful with work related machines. Here are some guidelines to follow:
- Never login using work credentials in any browser, phone, computer that is not work designated;
- Never login/use work applications (Slack, Asana, Google Workspace suit, ...) in a personal device;
- Never install/login/use your password manager work account in a personal device;
- You may choose to use a personal tablet computer to do work related activities but by doing so you are turning it into a work device and therefore all the rules apply as such; The tablet will remain under these rules until you completely wipe any work related information from it;
- Never access or download work-related files, software, etc. on a non work computer;
- Computer hard drives must be fully encrypted;
- Under no circumstances install pirate software or software from untrustworthy sources;
- Lock devices before leaving them unassisted.
- Configure devices so they lock automatically after 5 minutes of inactivity;
- Never leave work devices unassisted in a public or private place where it can be stolen or people could have access to it;
- Delete all code and assets after off-boarding a project;
Messaging and communication
As mentioned before there are many ways to exploit communication tools in attacks. The best way to protect yourself is to apply basic practices and checking to email, be suspicious of unusual requests and double check before doing anything. Here are the guidelines you should apply to any work related communication tool:
- Never pass any work related information in a non official work communication tool; that includes forwarding work emails to a personal account;
- Never use your work email in non work related websites/activities;
- Never receive work related emails from applications in your personal account;
- Be very careful when forwarding messages, check no sensitive information is being passed, double-check for collapsed previous messages, and never forward to personal email accounts;
- Always double check the sender email address and ensure you identify it and that it comes from a know domain address;
- Never directly click or download anything before checking the sender;
- Always copy and paste links to the browser checking if the address matches instead of directly clicking;
- For highly sensitive information (such as passwords and server keys) consider using GPG;
Weak passwords are another easy way for hackers to exploit systems. The good practices here are well established and more straightforward than other security measures:
- Set up Two Factor Authentication (2FA) to all of your accounts when available;
- Give preference to QR Code based 2FA over SMS and store it in the password manager authenticator app (and password/fingerprint lock it);
- You may choose any of the well known/trusted 2FA applications available, such as Google Authenticator, LastPass Authenticator or Authy to store 2FA codes (it should not be in your work computer);
- When you activate 2FA in a service you will receive "backup codes". Those are to be used to unlock your account in case you don't have access to your primary 2FA app or in case you lose it. These codes must be written in a paper sheet and stored in a safe place in your home;
- Never reuse passwords;
- Only store passwords in the company password manager account;
- Always generate random passwords with the length of at least 16 characters using the password manager;
- In case you need to share a password, revoke and modify it as soon as possible;
- Never send username and password in the same medium;
- If possible, avoid sharing user accounts as it makes it harder to trace breaches;
- Passwords must be changed at least once every 180 days;
Built at Vinta
CDRF is a web-based documentation with flattened information about Django REST Framework's class-based views and serializers. It's heavily based on Classy Class-based View.
We love checklists. That's why we created a bunch of great checklists to guide developers on how to deliver the best possible software. Here are some examples of the content you'll find there:
- Receiving Feedback
- Giving Feedback
- Asking for Feedback
- User Documentation
- Critical Incidents
- A/B Testing
- Landing Optimization
- Production Launch
- Django Apps
- Python API
- Celery tasks
Community is not only about producing open-source software (and playbooks), conferences are part of it as well. People are encouraged to give back as much as they can. With the interest of developing further exchange with other professionals, Vinta will buy tickets for any technical conferences deemed worthy by the employees, and if one of ours approves a talk in a conference, whether it's local or international, they are granted a bonus for their further collaboration in sustaining the community we are a part of. Keeping an eye on conference's submission deadlines helps everyone in doing so.
We keep our blog updated. It helps twofold, we train people on how to write passing on what they've learned, and people from the community see Vinta as a reference, checking us for tips often. That's why whoever learns anything gets incentives to write it down. We count on everyone to keep an eye and say: "I think that's worth a blogpost!" whether in our day-to-day or in a weekly meeting.
We are community people, open source contributions are wonderful and everyone is encouraged to do some. Since a lot of our coding uses open-source tools, maintaining our own open-source projects seems reasonable. So we encourage people to contribute as projects demands. We find that is one way to leave our company's mark in the community as well is to always fork using Vinta's Github account. Here are some of the projects that we maintain:
It's a customizable boilerplate that comprises Vinta's main tech stack. Here's a list of what we deemed necessary and the technologies chosen to address those needs.
- Backend Framework (Django and Django.js)
- Email Sending (Sendgrid)
- Responsive Styling (Bootstrap)
- Periodic Jobs (Redis and Celery)
- Interactive UI (React)
- Continuous Integration (CircleCI)
- Handling Static Assets (Webpack)
- Static Files Serving (WhiteNoise)
- Database (PostgreSQL)
- Easy Deployments (Heroku Button)
- Logging (Papertrail)
- Automated Quality Assurance (Prospector and ESLint with pre-commit)
It's a Django module to easily send templated emails. It allows you to send templated HTML or plaintext e-mails using Django template language, with all the available template tags and filters to easily build your e-mail templates.
Entity Embed allows you to transform entities like companies, products, etc. into vectors to support scalable Record Linkage / Entity Resolution using Approximate Nearest Neighbors.
Tapioca is an API wrapper maker. It provides an easy way to make explorable python API wrappers. APIs wrapped by Tapioca follow a simple interaction pattern that works uniformly, so developers don't need to learn how to use a new coding interface/style for each service API. You can find a full list of available API packages made with tapioca here.
For more detailed information, check this blogpost about Tapioca.
We use Celery to deal with tasks in a queue-based fashion. It receives tasks from our Django application, and it runs them in the background. Periodic tasks are scheduled by Celery Beat, which runs them at regular intervals. Django Celerybeat Status is a library that integrates with django admin and displays in a simple GUI when your periodic tasks are going to run next.
It's an app for role based permissions. It's built on top of Django's
Permission functionalities and does not add any other models to your project.
A small Django library that provides generic views, viewsets and mixins that extend the Django REST Framework ones, adding separate serializers for read and write operations.
Microblog app used to share quick knowledge. This code powers Vinta's "Lessons Learned", running at http://www.vinta.com.br/lessons-learned/.
The posts are created via slack using a custom command and are automatically posted on Twitter.
A curated list made for the DjangoCon US talk Preventing headaches with linters and automated checks by Flávio Juvenal.