Dicas para ser um “Full” developer

E aí pessoas, resolvi falar sobre um tema que veio me perseguindo nos últimos dias e que me fez pensar muito, logo, se tornou elegível para um post. Nesse post em seu blog, a Netflix conta um pouco da sua história de evolução de 2012 até 2018 e apresenta um “novo” conceito, que o mercado já está todo ouriçado se preparando para começar a explorar e vender curso a rodo para os desavisados e que tende a ser a mais nova buzzword do próximo ciclo de modinha no desenvolvimento de software, que é o “Full Cycle Developer”.

Sim, se você comprou cursos para se tornar um full stack ou devops nos últimos 2 anos, esqueça, o cara agora é o “full cycle”. Brincadeirinha, você ainda precisará dos conceitos ensinados neles e eu vou logo logo explicar porque.

O que é um Developer?

Simplificando tudo, pra explicar a vocês da forma mais simples possível, acho que primeiro temos que explorar um pouco o conceito do que é ser um desenvolvedor de software e como ele se encaixa no conceito criado pela Netflix. Sem ciência e sem ir “muito” no passado, vou lhes contar o que eu já vi e vivi nos últimos 19 anos desde que tive meu primeiro contato com computadores e softwares a fim de tentar explorar o conceito.

Nesse último post que eu escrevi, conto um pouco do início de minha história desenvolvendo software e como isso influenciou minha visão sobre a indústria. Apesar de no caminho muita coisa ter se deturpado, nos últimos anos (sim pode ser a tal crise da meia idade) muita coisa tem voltado a mente fazendo com que, quase sempre, eu me arrependa de ter mudado certas formas de enxergar relações de trabalho pra me adequar ao tal mercado. Teria muita coisa pra escrever, mas hoje pretendo me concentrar apenas na mudança na maneira de pensar meu fluxo de trabalho pra entregar software.

Logo que eu cheguei ao mercado de trabalho (de carteira assinada, já que já trabalhava desenvolvendo sistemas antes disso) trabalhei em uma empresa onde eu era, adivinhem?, “Full Cycle” Developer, claro, dada as devidas proporções. Desenvolvíamos um sistema de escola que atendia escolas na região de minha cidade e éramos responsáveis pela aplicação no ar, pelos novos projetos, correções de bug, infraestrutura, banco de dados e build. As maiores escolas tinham um time de TI que cuidava da rede e isso era o máximo do que não fazíamos para implantar nosso Sistema lá.

Fazer isso me ensinou muito de comunicação com o cliente e trato com pessoas para resolver problemas, me ensinou um MUITO dos conceitos e configurações de rede, aprendi como funcionava um banco de dados DBF (e a importância de um backup para os mesmos) e a me preocupar com versionamento de código como nunca antes, já que antes de entrar na empresa e começar a trabalhar em time, meus sistemas eram alterados apenas por uma única pessoa: EU.

Lembro-me de que nessa época isso era bastante natural para mim e até mesmo lógico, já que eu nunca tinha conhecido o mundo “dos grandes”.

Foi quando chegou o ano de 2008 e com o falecimento do meu pai, eu abandonei de vez meu sistema de representação (mencionado no post linkado no início deste) e segui de vez com a mente aberta para o tal do “ambiente corporativo”. Era um mundo novo onde a palavra de ordem era a divisão do trabalho por responsabilidades. Era uma filosofia “dividir para conquistar”. Cada pessoa no seu quadrado era responsável por definir pedaços específicos do ciclo de desenvolvimento e essa pessoa seria cobrada apenas por isso.

Logo o analista de requisitos apenas analisava e passava uma documentação para o desenvolvedor que então construía o código com base no que estava definido entre a área de requisitos e a área de negócios.

Mais “lindo” ainda, nada de definir relacionamentos dos dados, já que tínhamos os feras DBAs que cuidavam apenas da saúde dos dados e de garantir que ninguém não autorizado fosse meter a mão nos dados de produção, que são a jóia da coroa das empresas.

Acima de toda essa gente lá estavam os GPs, cuidando da saúde da equipe e de que todos esses pontos de comunicação se interligassem de forma bonita e saudável. Tudo dividido, cada um com sua responsabilidade, fazendo apenas seu pedacinho da obra, formando uma grande colméia para um objetivo em comum, certo?

Errado, se esse era o objetivo, o que se via era exatamente o contrário, não pretendo me alongar nesse assunto, pois se você se identificou com o ambiente que eu descrevi aí atrás, já entendeu exatamente e consegue visualizar vividamente na sua cabeça o cenário real dessa grande e desorganizada corporação.

Netflix e outras mais…

Enquanto isso (em algum lugar do mundo) alguns malucos já vinham há alguns anos conversando sobre um tal de ágil. Piada em grandes corporações com dizeres do tipo “isso aí não funciona no mundo real” ou “quando as coisas apertam o dinheiro fala mais alto”, o tal do ágil foi ao longo dos anos provando que veio exatamente para fazer o dinheiro falar mais alto, para entregar mais valor, para diminuir barreiras de comunicação, para fazer o cliente do projeto (e não PDFs escritos por terceiros e assinados por alguns) ditar as regras. O “software certo” voltou a ser o ator principal dentro dessas organizações e por consequência o dinheiro também, já que os clientes se encantavam com as soluções desenvolvidas.

Essas empresas se permitiam errar e se permitiam errar rápido. Todo aquele emaranhado de gente separada em quadradinhos agora trabalhavam juntas em uma única sintonia e com um único objetivo, que era por a solução proposta no ar o mais rapidamente possível, pois quanto mais rápido errassem, mais rápido também podiam ajustar, realinhar e acertar. Ciclos de anos para um projeto começaram a se transformar em ciclos de meses, semanas e agora mais recente até mesmo horas.

Software nasce rápido, time erra rápido, conserta rápido e está pronto pra um novo ciclo de feedback. Tudo RÁPIDO.

Empresas abraçaram a falha como parte do processo de aprendizado e perderam o medo de falhar e de errar. Aprenderam que quanto mais rápido erram, menos dinheiro perdem. Ciclos curtos de feedbacks dados por quem de fato usa o sistema e paga por ele, faz com que os acertos sejam rápidos e precisos para atender necessidades reais.

Essas empresas realmente foram capazes de quebrar o sistema vigente, simplesmente se tocando que precisavam fazer diferente e se focar no que importava, que era entregar soluções que encantavam seus clientes. Rápido.

Nesse processo áreas nasceram e outras se foram, seguindo o ciclo natural da vida, mas uma coisa nunca mais voltou nessas empresas: a régua alta da burocracia para colocar software no ar. Com poucos (em alguns casos até mesmo nenhum) nível de autorização um código desenvolvido a 10 minutos atrás já está no ar pronto pra ser utilizado.

E onde ficou nisso tudo o desenvolvedor?

Simples, em todo lugar. O developer, que até aquele momento terminava seu código, subia no repositório e já pegava outra tarefa, agora é o responsável também por colocar aquele código em produção, acompanhar o andamento daquela demanda, acompanhar o feedback da funcionalidade e atuar o quanto antes em cima de defeitos e das melhorias.

O tal do deploy, que antes era um poço de burocracia preparada para achar culpados por problemas em produção, agora está apenas a um clique de um botão.

Claro que pra garantir toda essa automatização e essa segurança (já que falhar rápido é diferente de falhar propositalmente) outras técnicas de desenvolvimento foram nascendo. Testes automatizados de software não são mais opcionais, mas agora são primários. E quem faz esses testes? Os developers.

Percebam que o developer passou a ser a figura central dentro dessas empresas. A figura do apertador de parafuso que terminava sua demanda e já pegava a próxima sumiu e a do cara que é responsável full pelo software que desenvolve, apareceu.

Agora o desenvolvedor conversa com a equipe inteira, entende o negócio do que está desenvolvendo, dá ideias de melhoria (afinal ele também é um ser humano usuário de sistemas e não apenas um macaco codificador) e é responsável por manter a tecnologia funcionando e não mais apenas o código no repositório. E aqui, quem virou devops ou fullstack fique tranquilo, seu conhecimento muito provavelmente será BEM requisitado no “time de software da década de 20 do século XXI”.

Esse aí é o Developer e suas responsabilidades.

Como dizia a sua mãe: “Você não é a Netflix…”

Percebam, a Netfix não fez por mal, assim como o spotify também não (se quiser saber do que estou falando segue link), mas é que os oportunistas de plantão ouvem o novo termo modinha, que o autor do tópico original não cunhou por maldade, e começam a brilhar os olhos com cifras sabendo que vão se fazer vendendo curso e dando consultorias.

Na verdade, os autores que cunham os termos originalmente, quase nunca se importam com eles futuramente, já que os mesmos foram apenas anedotas para explicar algo muito mais impactante.

Quando a Netflix cunhou o termo “Full Cycle Developer” eles não estavam realmente preocupados com esse nome, foi um exemplo, foi uma forma de dizer algo que é bem mais simples, mas que mesmo sendo mais simples, foi desenvolvido e testado a longo de anos de experiência.

Sendo assim, quando lhe disse acima que sua mãe estava certa quando ela lhe disse que “você não é a Netflix”, é porque a Netflix evoluiu para esse modelo passando por etapas da sua vida. Ela não contratou Full Cycles, ela os criou e os moldou, com demandas específicas e objetivos específicos.

A Netflix, tirou do seu caminho quase todas as barreiras de comunicação entre níveis de responsabilidades e, diferentes da separação de times por cargos, a Netflix funciona com times multidisciplinares que cuidam de uma parte do negócio. Isso permite que os desenvolvedores não encontrem barreiras de comunicação, burocracias de decisão e que possam fazer rapidamente suas entregas percorrendo todo o ciclo de desenvolvimento que envolve, definição, desenvolvimento, deploy e validação.

Você é a Netflix? Você consegue enxergar hoje na sua empresa a capacidade de alterar um trecho de código e em pouco tempo vê-lo em produção com a segurança dos testes, com o deploy automatizado e com as ferramentas necessárias para validar o feedback dos clientes?

Perceba que nas perguntas acima, estamos falando de 2 grandes pontos que você precisa adequar para, assim como a Netflix você formar seus próprios Full Cycles:

1- Você está pronto pra ser um Full Cycle se:

• já entendeu que testes automatizados não são “frescura” ou “perda de tempo” e são essenciais para assegurar o mínimo de consistência de funcionalidades do seu sistema.
• entendeu que deploy deve ser [commit -> produção] sem medo de subir seu código e pronto para arcar com as consequências tendo a capacidade de responder rapidamente a problemas.
• adquiriu a skill da comunicação, sendo capaz de fluir de negócio para tecnologia de forma natural fazendo as perguntas que importam e sabendo responder as dúvidas das outras áreas de forma correta e segura, afinal problemas agora não são granulados em diversos setores da empresa e hão de cair direto no seu colo.
• já tem autonomia e maturidade de saber lidar com conflitos e comunicar necessidades de mudanças que você acha que podem impactar positivamente para sua liderança, já que o Cycle é mutante e vivo, ou seja, não existe um Cycle fixo que vai durar pra sempre.

2- Sua empresa está pronta para ter times/developers “Full Cycles” se:

• entende que burocracia tem custos, ou seja, níveis hierárquicos e burocráticos atrapalham entregas e ciclos curtos de feedback.
• está em busca de “abraçar” a possibilidade de erros, entende que níveis hierárquicos e burocráticos são necessários para dirimir erros e agir em pontos focais de falhas e gargalos enquanto busca “virar a chave”. Ter burocracia não é necessariamente ruim dependendo da cultura empresarial arraigada. Mudanças custam tempo e não ocorrem da noite para o dia.
• trabalha melhorias contínuas em tecnologias e pessoas, de forma que elimina toda e qualquer resistência a mudança e evolui a diminuição do tempo de resposta pra ter software em produção.

A Netflix desenvolveu as habilidades de seus Full Cycles. Os desenvolvedores que lá estavam, tinham (ou desenvolveram) todas as habilidades comentadas anteriormente e algumas outras.

Ser Full Cycle vai requerer de você experiência. Trabalhar bastante e desenvolver a skill de comunicação, capacidade de negociação, conhecer as técnicas de testes automatizados, ferramentas de track, build, logs, databases, code quality, conhecer as boas práticas das linguagens/frameworks utilizados na arquitetura, entender de integração entre serviços e camadas arquiteturais de software, etc.

São muitas skills que, nenhum curso ou consultoria nenhuma vai ser capaz de lhe ensinar.

Você vai ter que passar por problemas reais em produção, cargas de usuários simultâneos, problemas de performance, segurança da informação, indisponibilidade de infra e serviços e muitas outras situações que lhe prepararão para encarar o desafio de ser um Full Cycle sem medo.

Então, no final das contas, ser um Full Cycle Developer nada mais é do que ser o desenvolvedor que é capaz de resolver o ciclo completo do desenvolvimento de software, além de ter a capacidade de automatizá-lo a fim de diminuir cada vez mais o ciclo das suas entregas.

Acredite em mim, sem que a sua empresa também tenha um “Full Cycle Team”, é muito provável que ela tenha “Full Cycle Developers” apenas de nome, pois (como a Netflix bem explica em seu post) o time deve entender o ciclo de desenvolvimento e se comprometer com os ciclos de entrega curtos, logo, burocracias devem ser evitadas na medida do extremo e o ator principal da obra deve ser o software em produção.

Recomendo muito a leitura do post para que você entenda exatamente pelo que a Netflix passou para ter seus “Full Cycles”.

É um processo de aprendizado constante que, muito provavelmente, seu time pode alcançar, mas seguindo outro caminho dentro da sua própria realidade, sem receitas mágicas, sem cursos ou consultoria. Muito provavelmente, se você está chegando agora no mercado, você vai precisar de um bom tempo até se tornar um Full Cycle Developer.

Minha opinião? Não tem problema nenhum nisso, é apenas a evolução natural de quem atua com desenvolvimento de software e exatamente por isso que eu não acredito em possíveis futuras formações para “Full Cycles”. Seja o melhor desenvolvedor que você puder e estude sobre todas as estapas do ciclo de desenvolvimento que a sua empresa/seu projeto necessitam e seu título de Full Cycle será natural sem você nunca precisar usá-lo já que, como eu disse lá no início deste post, foi apenas uma forma da Netflix explicar um conceito.

E aí? O que você acha? Comenta aí ;-)