One year ago I joined Plataformatec and today, I’m going to tell you some practices that I have learned while working here during all this year. I hope you’ll find something helpful to improve your team or your company.
Sustainable work hours
Some companies expect their employees to work overtime when a project gets close to the deadline and it’s not finished yet. When I came to Plataformatec, I discovered that the default here is to work in a sustainable way (40 hours/week). There have been a few exceptions, but we are not encouraged to do so, and the extra hours can be compensated as well.
Software development tools and practices
At Plataformatec we choose to start with a small set of basic tools and practices, adapting as we learn about the project and the customer.
One of the practices that I liked the most and had no previous experience with is the retrospective meetings. If you never heard about it, it’s simple! It’s a meeting that we do at the end of an iteration, reviewing everything that happened: not only the good things, but also the ones that we need to make better, so that we can plan actions to continually improve. For me, it is a very pleasant meeting because it’s an opportunity to recognize the good work someone has done or to search for a solution to a recurring problem. One interesting fact is that we also use retrospective meetings internally, for the whole company itself.
We don’t cut corners
We really care about our customer’s products and the code quality. We don’t like adding ineffective, incomprehensible or quick-and-dirty code (also known in Brazil as “gambiarra”), because we know that it may cause problems in the future.
We know that it’s not that easy to avoid bad code and beginners mistakes, but there is no definitive solution for this kind of problem. Here at Plataformatec we use two tools to achieve a greater level of code quality: our guidelines and a simple process called code review via pull request. If you’re going to adopt just one of these practices, choose Code Review.
Every single line of code matters, that’s why it’s better not to put all that responsibility on just one person’s shoulders. The code review process can help with that. When doing code reviews, everyone in the team is accountable for the code that is being shipped, not just the developer that created the pull request.
Before working here, I thought pull requests were only an open source practice, that it didn’t have place in commercial projects. It was really mind blowing to see how it works on a daily basis. We reduce errors, ask for help to an experienced programmer, learn about features of frameworks and languages, discuss algorithms… it is an awesome communication tool, and the best part is, all that communication happens in the context of the source code.
It’s simple: we do software development, we work hard to improve the way we do it and to become one of the best references on it. The whole company works as a team, and everyone shares the same goal. It means that the salespeople close the deals with terms that developers and managers can work in a healthy and challenging environment, and, most importantly, the customers know what to expect from us.
It was a surprise to me when I came here and saw that all of my new coworkers love the programming community and that most of open source work is done during their free time. We are frequently encouraged to contribute to open source, attend to local and international events, write blog posts, present talks and discuss software development subjects on our Hacking Evening every Tuesday. Best of all, you don’t need to do it alone, there is always someone to lend you a hand. Knowing these people and working with them motivates me and help me love more what I do every day.
That’s all I had to say for now. Working at Plataformatec has taught me a lot of good lessons and I know I still have a lot of things to learn. I selected the practices that I liked the most and wanted to share.
Do you have any practice that you appreciate? Tell us about in the comments below!
Em 2009, quando fundamos a Plataformatec, havia muita incerteza e desafios pela frente. Por outro lado havia pontos claros para nós fundadores, principalmente quando o assunto eram as contratações do nosso time. Era unânime que não contrataríamos “recursos” e sim pessoas com as quais nós teríamos prazer e confiança em trabalhar juntos. Afinal de contas, o nosso modelo de negócios sempre foi lastreado na construção da nossa marca através da qualidade dos serviços que prestamos. Sendo assim, faz total sentido investir nossos esforços na retenção e desenvolvimento do nosso time.
Quatro anos depois aqui estamos, com um considerável histórico de projetos bem sucedidos e algo que consideramos muito valioso: o nosso Time. Quem conhece um pouco sobre empresas de “Outsourcing de TI” sabe que o turnover é altíssimo, mais que o triplo da média de outros setores. Honestamente, é uma lógica que nunca entendemos. Aqui na Plataformatec, não tivemos nenhum desligamento em 2012 e em nossos quatro anos de existência, somente um dos nossos engenheiros optou em sair da Plataformatec (aliás, ele é um grande amigo nosso e sempre que está no Brasil aparece para comer uma pizza conosco). Já houve pessoas que nos perguntaram qual é a mágica. A resposta é óbvia: não tem mágica. Nós somente convidamos pessoas a juntarem-se ao nosso time quando sentimos que há um grande fit cultural.
Portanto se você acredita em colaboração, tem alta capacidade de aprendizado e tem vontade de trabalhar com um time com histórico de sucesso comprovado, continue lendo. Você pode ser o próximo integrante do nosso time.
Como participar do processo seletivo
Para participar do processo seletivo visite http://plataformatec.com.br/careers ou também veja http://www.facebook.com/plataformatec.com.br para conhecer mais sobre o nosso time.
Estamos à procura de:
- Desenvolvedores de Software (Ruby e Rails)
- Front-end Developers
- Scrum Masters / Gerente de Projetos
- Business Analysts (extração de requisitos)
Requisitos para candidatar-se (todas as vagas)
Para qualquer uma das vagas:
- Inglês Intermediário
- Local de trabalho: São Paulo, bairro Vila Madalena
- Pelo menos um ano de experiência na sua área
Requisitos complementares para candidatos a Desenvolvedores de Software
- Background em programação orientada a objetos
- Pelo menos um ano de experiência com desenvolvimento de aplicativos web em qualquer linguagem
- Pelo menos seis meses de experiência com Ruby e Rails
- OS Linux ou Mac
Mesmo que você não tenha todos os requisitos acima, mas realmente quer trabalhar conosco e ama programação, você está convidado a participar do nosso processo seletivo.
Estamos esperando por você!
[curiosidade] No blog post de dois anos atrás ainda dava para enxergar o sofá nas fotos.
We cannot express how excited we are with such great news. In our last blog post we were celebrating Rafael’s achievement and just a few months later we are celebrating again. Years ago, having three Plataformatec teammates as Rails Core members would be something we’d only dream of, but in 2012 it became reality. I must say that it didn’t happen by chance, not at all.
Carlos has always been an outstanding software developer and a great teammate. He is someone we all deeply trust to solve hard problems and deliver mission critical projects. We’ve always watched Carlos working really hard and we must say that he deserved every bit of such achievement. You can check out his contributions into many other open source projects at http://github.com/carlosantoniodasilva
Kudos to our friend @cantoniodasilva!!!
Last May we happily announced that Rafael França and Carlos Antonio earned commit access to the Ruby on Rails repository – it was a great accomplishment that deserved its own blog post. Today, we have some great news and we want to share with our readers. Just a few days ago, our team mate Rafael França (@rafaelfranca) received an invitation to join the Rails Core Team. And, of course, he accepted!
Rafael contributed to different features coming up in the next Rails 4 release and worked extensively with other Rails contributors to smash bugs and provide many improvements to the framework. I am personally happy to have a friend joining me in the Rails Core Team.
Furthermore, Rafael França’s contributions go beyond Rails. Lately he has also contributed to many other open source projects, like Mongoid, Janky and Dalli besides Plataformatec’s own projects like Devise, Simple Form and Elixir.
From all your friends at Plataformatec.
It is no secret that our team has a great passion for contributing to the open source community and once in a while we receive compliments – it is great to have our work recognized; thank you all for always being supportive. =D
We’d proudly like to announce that, due to their contributions, two specific members of our team were recently awarded by the Ruby on Rails community (by the Rails Core Team, to be more precise).
Guys, congratulations! \o/
We are all very happy for this great achievement. Great work!
From your friends at Plataformatec.
[as some of you might have noticed, I accidentally clicked on "Publish" on my draft version, here is the full version of the post. Sorry about that]
A year ago I was writing about a few uncertainties that we faced while starting up Plataforma Tec and how we dealt with them. We know that we still have a lot to learn, but now that another 12 months have passed by we are feeling much more solid and confident about what we’re building.
As last year’s post, this will also be about sharing our thoughts and a few practices that have been helping us a lot in creating a company culture and leveraging our team into its best. I hope you enjoy and find them useful!
We believe that (…)
1)… mastering our work IS our work
We constantly tell people and customers “hire us only if you need a well developed application” (for example: a web application that will provide a revenue stream or will constantly have new features). This is one of our main assets and our main differentiation in this price competitive industry. Frankly, this strategy has been working fine for us but in order to keep it running this way, we are constantly looking for mastering our work all the time. Otherwise, if we don’t, there will be a great chance of losing our competitive edge.
2)… responsibility comes along with autonomy
In last year’s post we mentioned that we only hire professionals that we feel comfortable giving autonomy, but it’s important to remember that it must be used very carefully. So, although autonomy makes a great pair with the constant search for mastery, don’t forget to be very cautious when dealing with decisions that might have a great impact in your company. We usually handle this kind of situation with two simple practices:
- we show our team, in a very explicitly way, the goals and guidelines that should de followed;
- and we constantly gather the team to discuss important issues (see the item below).
3)… gathering the team to discuss problems is a great way to find solutions
Once in a while we face situations that are a bit more risky or complicated to be solved by our selves alone. They can be technical or design problems, a project management issue or even a simple warm-up for a business meeting. For all this we usually gather two or three team mates to ask for their opinion and discuss about the options that we might have.
4)… projects managers shouldn’t delegate work or establish random deadlines. They should serve and protect the team from undesired noise.
In our company, projects managers, salesmen and organization leaders work together with developers and designers. We see it as a system that must work synchronized. Also, the actions of planning, estimating and taking decisions in a project should be made by the whole team (and not only by the manager). We found out that serious problems might arise when this system is desynchronized or made only by one person.
In our opinion, the manager role is to assure that developers and designers have the proper atmosphere to do their best. And by ‘proper atmosphere’ we mean that they have to provide the right tools (hw and sw), proper workplace, avoid useless interruptions and support the team when they get stuck with something.
5)… establishing roles is good and we avoid hierarchy levels
Some managers try to list and predict 100% of the problems that might happen in a project. Here at Plataforma Tec, we assume that it’s impossible to do so. Therefore the big deal is NOT about trying to predict and avoid 100% of the problems. The deal is to BE PREPARED TO REACT when a problem happens and trying to avoid the most obvious problems that could happen.
Ok, but what does it all have to do with Roles vs. Hierarchy?
Check this: if we are prepared to react to a problem, first we must DETECT the problem. Right?
So, that’s where hierarchy kicks in… there is a great chance that creating hierarchy levels will degrade the communication quality in you company. This is one of the reasons we avoid creating different levels here at Plataforma Tec. Instead, we prefer defining roles. Developers should develop, Managers should support, Salesmen should sell (but synced with the whole “system” mentioned in item “4″).
If you’re having trouble understanding the difference between Roles and Hierarchy, take a look at Scrum’s roles (as an example of definition of roles).
6)… business leaders must create the right policies to enable all the items above
All these practices won’t be effective if the organizational leaders don’t believe and provide the right policies to really enable them. Important notice: be careful not to confuse policies from impositions.
Well, this is a list of a few things that we’ve been doing and they have worked fine for us. Also, these six practices will work a lot better if implemented together, since they leverage each other.
I guess that’s it and I hope they’ll be useful or inspiring to others. Also, don’t forget to comment what you think about this small list of practices… Do you think they’ll work in your company?