Definição

Vamos começar com a definição de herói. Fazendo uma tradução livre do conteúdo do blog do Payne, temos que:

O herói é uma pessoa que é capaz de varar noites, trabalhar de fim de semana e fazer plantões enquanto ninguém mais se prontifica.

Então, qual o problema com heróis? Nós dividimos o problema em duas partes: saúde física e saúde do trabalho.

Saúde Física

Bom, nós não somos médicos, mas nos parece que já há informação suficiente por aí sobre os males que trabalhar em excesso pode trazer ao seu corpo.

O problema de saúde, nesse caso, é relacionado às ações que o herói toma para alcançar seus objetivos: geralmente ele(a) dorme pouco e trabalha muito. Existe uma tonelada de informações na internet e até mesmo no meio acadêmico que mostram o que o vício no trabalho e a privação do sono causam ao nosso corpo. Para listar algumas dessas fontes, aqui vai uma pequena lista (em inglês):

• Effects of sleep deprivation on cognitive performance
• Neural basis of alertness and cognitive performance impairments during sleepiness. Effects of 24h of sleep deprivation on waking human regional brain activity
• An overview of sleepiness and accidents
• Why Being A Workaholic Is Awful For You and Everyone Around You

Além desses, o herói pode ainda sofrer por não praticar atividades físicas regulares e por não se alimentar adequadamente.

E se você está pensando “Ah, mas eu bebo café… logo consigo lidar com muitos desses problemas”, aqui vai um material extra sobre os males do excesso de café no nosso organismo:

• Association of Coffee Consumption With All-Cause and Cardiovascular Disease Mortality
• Caffeine and pain

Saúde do trabalho

Então você faz parte da corrente YOLO e não liga para sua saúde física com tanto que valha a pena. Bom, acontece que você não está apenas afetando seu corpo, mas também afetando o projeto/produto/trabalho no qual age como herói.

Primeiramente, heróis não são necessários se o planejamento do projeto é feito corretamente. O que quero dizer é que ninguém planeja no ínicio do projeto que um programador trabalhará 12 horas por dia, sem descanso. Então, o que acontece é que a projeção do esforço e do tempo necessários para realizar o projeto não foi bem calculada. Nós possuímos alguns blog posts falando sobre nossas métricas e como prever o fim de um projeto:

• Why we love metrics? Cumulative flow diagrams
• Why we love metrics? Throughput and Burnup charts
• Why we love metrics? Learning with Lead time
• Forecasting software project’s completion date through Monte Carlo Simulation
• Power of the metrics: Don’t use average to forecast deadlines
• Looking at lead time in a different way

Além disso, quando um time contém um herói, os outros membros da equipe podem seguir dois comportamentos distintos:

• Eles podem achar que o herói vai fazer todo o trabalho árduo e, portanto, eles podem parar de se engajar tanto quanto antes e apenas realizar as tarefas mais simples.
• Eles podem começar a trabalhar como heróis para tentar se igualar ao primeiro, para que suas imagens não sejam ofuscadas pelo brilho do herói.

De qualquer maneira, seu time será afetado de uma maneira negativa. Pode ser que, de início, tudo dê certo e que o time entregue tudo mais rápido. No entanto, após um tempo, a produtividade e/ou qualidade da entrega será afetada e seu time estará pior do que antes pois estará exausto.

Mais ainda, existem outras consequências não comportamentais que podem afetar o seu time:

• Um herói dentro do time gerará mais trabalho para seus colegas. Existirá mais código para ser revisado, mais tarefas para testar e assim por diante. Para resumir: mais WIP (Work In Progress).
  • Pode chegar a um estado insustentável, no qual o sistema esteja sobrecarregado;
  • Os não-heróis podem ser considerados preguiçosos ou não comprometidos, devido às comparações com o herói;
• Dependendo da arquitetura do sistema, o código extra pode impactar o código já existente, ou pull requests ativos.
  • Pode demandar mais trabalho para resolver conflitos;

Além disso, um estudo da London School of Economics juntamente com Harvard, “Innovation in the collective brain“, fala sobre a importância do trabalho coletivo nas grandes ideias inovadoras. Nem pessoas mundialmente reconhecidas como heróis, como Einstein, Steve Jobs e Darwin, trabalharam sozinhas. Um resumo do estudo pode ser encontrado nesse post da Inc: The Heroic Inventor Is a Myth: Great Ideas Are Group Efforts.

Lidando com heróis

Primeiramente, vamos dizer que você já notou que uma pessoa em seu time age como um herói. O que fazer sobre isso? Bom, a primeira coisa a fazer é conversar com seu gestor, ou a pessoa que reconhece os esforços do time, e mostrar a ele(a) o problema. Explicar como isso afeta seu time e tentar encorajá-lo a parar de recompensar tais atos heróicos, e até mesmo proibir horas extras desnecessárias.

Se você não trabalhar com um herói ainda, faça o melhor possível para evitar o surgimento de um e planeje muito bem seu projeto. Faça projeções conscientes, com prazos factíveis. Baseie sua projeção não somente em estimativas cegas, mas em números, simulações e histórico. Se você observar, durante o projeto, que cometeu um erro na sua previsão, pare e adapte seu trabalho ou seu prazo. Nem todos os prazos são imutáveis, e nem todas as demandas são sempre necessárias. Então trabalhe arduamente para garantir que seu time está confortável com o tempo que tem.

O que achou do texto? Você já viu ou foi um herói em um time? Deixe seu comentário abaixo!

The post A síndrome do herói e como lidar com ela first appeared on Plataformatec Blog.

Atenção desenvolvedoras e desenvolvedores, tenho uma ótima notícia. Estamos com vagas abertas na Plataformatec!

Não estamos procurando “ninjas” ou “rockstars”. Procuramos pessoas responsáveis, que busquem sempre melhorar suas habilidades em desenvolvimento e gostem de trabalhar com autonomia.

Para fazer parte do nosso time, você precisará ser aprovado em nosso processo seletivo. Hoje ele é composto por 5 etapas:

No Bate papo inicial, o objetivo é conhecermos melhor os candidatos e apresentarmos quem nós somos; a Entrevista técnica tem por meta avaliar o conhecimento sobre desenvolvimento web (em especial, utilizando Ruby e Rails); já na etapa de Show me the code queremos ver seu código; no Pair programming avaliamos como os candidatos pensam e se portam ao escreverem seu código. E finalmente, com todas essas informações em mãos, conseguimos fazer a Proposta financeira.

O objetivo desse post é dar dicas sobre como ir bem na terceira etapa. Como já mencionado, a etapa Show me the code é o momento que as candidatas ou os candidatos têm para demonstrarem na prática o conhecimento avaliado durante a Entrevista técnica. A pessoa precisará desenvolver um aplicativo web de escopo reduzido que deve ser feito no prazo de uma semana.

Depois de entregue, o aplicativo será revisado por nosso time que buscará as boas práticas de desenvolvimento.

Vou citar algumas dicas que podem te ajudar a escrever um código com mais confiança e atingir um bom resultado:

• Familiarize-se com a ferramenta
• Comunique-se
• Reflita sobre a segurança
• Busque a simplicidade
• Valorize seu frontend
• Dê atenção a usabilidade

Familiarize-se com a ferramenta

Somos uma consultoria de Ruby e Ruby On Rails e esperamos que o candidato tenha familiaridade com a tecnologia. Mesmo que você venha de outra linguagem, esperamos que você saiba desenvolver usando as funcionalidades mais comuns do framework. Recomendo ler Ruby On Rails Guides e fazer o tutorial do livro online Ruby On Rails Tutorial.

Comunique-se

Comunicação é muito importante para o nosso time. Durante o desenvolvimento, pense nas pessoas que vão revisar seu aplicativo e testá-lo. Pense nelas como se elas estivessem trabalhando junto com você. Valorize suas mensagens de commit, diga o quê e o porquê das mudanças. Uma boa ferramenta de consulta é o GitHub, inspire-se em projetos open source que você gosta.

Reflita sobre a segurança

Um app seguro é essencial para os usuários e conta como pontos positivos. Dê uma lida no guide sobre segurança do Ruby on Rails e certifique-se se as actions do seu controller estão com as permissões corretas.

Busque a simplicidade

Sabemos que o tempo para produzir o código para nossa revisão é curto, mas o escopo também não é grande. Portanto, tente não se complicar adicionando muita complexidade. Não deixe de mostrar seus pontos fortes, porém o faça de maneira simples. Por exemplo, se você não domina muito Javascript, não precisa fazer uma single page app, com um framework grande de frontend, integrado com backend Rails conectado em diversos microserviços. Faça o simples que vai dar tudo certo.

Valorize seu frontend

Nosso foco é desenvolvimento web, portanto conhecimento de HTML, CSS e Javascript são muito importantes. Esperamos que o mesmo carinho que você tem no seu código Ruby tenha também no seu código de frontend.

Se você manja de HTML e CSS, aproveite essa chance. Como muitas pessoas acabam escolhendo utilizar Bootstrap, essa é a oportunidade de mostrar seu diferencial.

Dê atenção a Usabilidade

Pense nos usuários que vão usar o aplicativo que você fez. Como a pessoa irá navegar e fazer as tarefas? Está intuitivo? É bom repassar os fluxos da aplicação manualmente para ter certeza de que as pessoas que usarem o aplicativo não irão encontrar erros ou ficarão perdidas.

Vale lembrar ainda que, pelo sim ou pelo não, sempre te daremos um feedback. Se por algum motivo você não for aprovada(o), te enviaremos uma lista com os pontos onde você poderia ter ido melhor e as respectivas recomendações de estudo. Trabalhe esses pontos e, quando julgar que conseguiu evoluir, se candidate novamente no nosso processo seletivo. Por curiosidade, algumas pessoas do nosso time participaram do processo seletivo mais de uma vez. Se você for aprovada(o), prometemos muitos desafios e aprendizado.

Para saber mais como serão seus primeiros meses de trabalho, indico dois posts para você: One year working at plataformatec (escrito também por mim) e What I have learned in my first three months at plataformatec (escrito por Igor Florian).

Espero que tenha gostado dessas dicas. Se você gostou e acha que elas se relacionam com a maneira que você gosta de trabalhar, inscreva-se no nosso processo seletivo.

Para outras dicas de como mandar bem no desenvolvimento de software, recomendo também dar uma olhada nas palestras Learn From My Mistakes da Flavia Fortes e 10 Coisas Que Eu Gostaria de Ter aprendido Mais Cedo do Lucas Mazza.

Espero ver seu código em breve

The post 6 dicas para mandar bem no código do processo seletivo da Plataformatec first appeared on Plataformatec Blog.