“The only thing we have is one another. The only competitive advantage we have is the culture and values of the company." Howard Schultz said it about Starbucks and we unreservedly agree. Here at Vinta we care a lot about having an ever-improving environment to work on. Check our guidelines so you can also go forward and create your own!
Vinta is a software consultancy focused on web projects. We like to work with Python and JavaScript tools, but we have an open mind to experiment and play with other languages and tools. Django and React are our specialties and we love working with APIs.
- Programmers, not processes nor code, are the most important thing in software engineering.
- The client should be always aware of what is happening, be it good or bad.
- There is no such a 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.
- 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 then, 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 both we all and those we don't know grow together.
- To provide technical courses for everyone, either in-person or online, so we all see no barriers to learning more.
- To buy any technical book wanted/needed, so we all keep reading even outside the company.
- To offer as much coffee and tea as people wish, so we all work in our best.
- 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.
- Any kind of racism.
- Any kind of sexism.
- Any kind of prejudice.
Even though we don't live in an English-speaking country, all company’s communication is done in English. Regardless if it's a private slack chat or a large Basecamp discussion, We believe that's a necessity in order to better communicate with our offshore clients. Every mistake is a learning opportunity, so feedbacks to improve each other's English skills are very much welcomed.
For us, it's very important to acknowledge where our ideas came from. First, because we don't want to take credit from things that we didn't do and Second, because it helps to emphasize that everyone is free to learn, copy, and improve on what we are doing. Most of our references come from books we read, Startups and bright people from the developer’s community that have inspired us.
-
Rework - Rework is our Bible here, we believe Basecamp has it spot-on regarding where we want to be as a company. It taught us to question growth and see it as a tool to increase value delivered to the customer, not as a necessity. Here, we’ve also learned that meetings are toxic, and much more. Ultimately, it gave us the faith that we can create a company different from the status-quo and still be successful and relevant.
-
The Lean Startup and The Four Steps to the Epiphany - We are not a Startup, but it doesn't stop us from thinking like one. We use the lean build-measure-learn cycle on everything we do. We are always revisiting our processes and iterating them. For us the key take is: validation. Be it something we want to experiment outside the company or inside with our employees, nothing is set in stone, everything needs to be validated.
-
Two Scoops of Django - “Write code that you are proud of”. It is Vinta’s main statement. In this direction: Two Scoops of Django, from our friends PyDanny and Audrey Greenfield, helps us a lot to fuel our discussions regarding our Django Code.
-
Real-Life Responsive Web Design - The way our web projects interact with users fascinates us. We focus on making users awesome with our deliveries, and the fact that we can do that with small alterations in how they use our software is great . Smashing Magazine sets great example by continuously introducing new discussions regarding user interaction and HTML/CSS good practices.
These books taught us something that lives on in our culture. Sometimes bringing us things we haven’t ever heard of, and other times just by asserting things we already had stumbled upon in our practice and use frequently in our day-to-day.
To us going #noestimates was a decision made early on. Mostly because we believe estimating is bad for both sides (the contractor and the client). To better exemplify that, here is how people think a fixed bid project works:
‘’’Project estimate -> internal development of the estimated features -> delivery to the client’’’
This sounds good in theory, but none of those parts happen as smoothly as they are supposed to. Psychology tells us that we are way less analytical than we think when it comes to making predictions. We tend to overestimate our abilities to deliver and to see everything in hindsight as ‘perfectly predictable’. That might be ok for short estimations, but when we are talking about projects that last more than 3 months and many layers of complexity, it becomes quite hard to accurately deliver a working schedule. Every programmer knows that when you are developing a feature, lots of things can happen. It usually takes some time to study how to fill requirements, bugs might take longer than expected to be corrected and integrations are never as smooth as predicted. Some people say, as you can check here and here, that these problems can be corrected with a better risk management or an improved estimation method. But even with those corrections we believe that in environments with more uncertainty, these methods are not enough to tackle the whole issue. Anything from the client changing his mind, the customers validating the feature out, or even a new and urgent feature popping up are not only possible to happen, but absolutely common to do so. And these are only some of the different turns that might come up. There is just no getting ready for them in advance, you have to answer them and it’s more workable if you are not bound by contract to deliver something that is not in the best interest of your client (as it has just been perceived or decided) anymore.
Instead, when we talk about no estimates, we charge and agree on contracts based on hours worked, not features delivered. That means a project is never finished until the client is satisfied or the budget for that project ends. Although scary at first (the client won’t know exactly when the project will end, or how much will it cost), there are a lot of benefits that come from it: we don’t need to estimate, since we saw it’s difficult and error prone, and that’s a big relief. everything takes the time it should take to be done, that means more testing, more studying and more time invested in quality, which leads to better code and increased maintainability. the client doesn’t need to waste time thinking/predicting every single need she/he might have. Also, she/he is forced to stay engaged to the project and receives more deliveries according to what she/he wanted, instead of waiting a long period of time to see something that isn’t exactly right.