Você não é pago para migrar de tecnologia

Vou começar pelo tweet em questão:

Não imaginava que isso geraria polêmica. Mas como gerou, vou tentar ao máximo explicar o que quis dizer, porque acredito que esse seja um conceito fundamental. Principalmente na evolução de pleno para sênior.

A equipe de software

É bem provável, que no seu trabalho, você faça parte de uma equipe. E se você faz, é também provável que a sua equipe seja composta mais ou menos por:

  • Front-end engineer
  • Back-end engineer
  • Designer
  • QA
  • Scrum Master
  • PO
  • PM

Em startups (ou até mesmo em empresas mais maduras) é possível não encontrar alguns desses, ou algumas pessoas fazem múltiplos papéis. É normal.

Equipe de software

O meu ponto é: existem diversas pessoas na sua equipe, com background diferentes e, principalmente, um foco de atuação distinto.

O Designer, por exemplo, pode ser enviesado para soluções mais belas e - muito - difíceis de implementar. Já o Scrum Master, pode ter um viés no processo em si. O PM por outro lado, tem que saber unificar todas as visões distintas e analisar o trade-off entre elas pra que um grupo de pessoas saia ganhando: os usuários finais.

O nosso viés

Bem, se você está lendo esse post, existe uma alta possibilidade que você seja - ou queira ser - um desenvolvedor (ou desenvolvedora) de software. E nós também temos, assim como as outras pessoas da equipe, o nosso viés. E ele geralmente é a própria tecnologia.

Explico: queremos porque queremos migrar para TypeScript, ou para React, ou fazer tudo usando uma arquitetura de Micro Frontends.

E isso é ótimo! Mostra que não paramos no tempo e que ainda gostamos do que fazemos a ponto de querer reescrever tudo novamente numa tecnologia nova.

Mas é também seu papel - principalmente dos leads - se questionar: o investimento vale a pena? Qual valor que essa migração vai acrescentar pro usuário final?

Um exemplo real

Aqui na Carta temos um grande legado em Knockout. A maioria dos colaboradores da empresa - independentemente da área de atuação - já entendeu que devemos migrar todo esse legado pra React o mais rápido possível. E sabe porque todos estão na mesma página? Porque PMs, Designers, e até mesmo a área de suporte, já aprendeu que uma página feita em React que levaria 2 dias pra um desenvolvedor construir, em Knockout pode levar 5x mais tempo. E com muito mais bugs.

Isso porque nem falei sobre a questão da performance, e o fato de que todas as páginas em Knockout não conseguem usar a biblioteca de Design Systems da empresa (que é feita em React).

Tudo isso é valor que deixa de ir pro usuário final e é perdido em tempo de implementação (ou conserto de bugs).

O jeito certo de migrar

No final do dia você não é pago para migrar por apenas migrar - por mais legal que isso seja - de tecnologia. Porque é um tempo de investimento que você poderia estar adicionando novas features, ou corrigindo bugs. E isso sim adicionaria valor pro usuário final.

Mas como citei, existem casos que fazem 100% de sentido uma migração. E pra esses casos é o seu trabalho não só identificar esse gargalo tecnológico, mas também convencer PMs, gerentes, ou seja lá quem toma as decisões na sua empresa.