Recentemente, recebi um e-mail de um leitor do meu blog que, por um motivo qualquer, me fez pensar. Aqui está o que ele disse:

Oi, Philip, tudo bem em perguntar como se tornar um grande engenheiro front-end?Algum conselho?

Eu tenho que admitir, fiquei surpreso de receber essa pergunta, já que eu realmente nunca pensei em mim como um “grande” engenheiro front-end. Na verdade, os primeiros anos em que trabalhei nessa indústria, eu honestamente não achava que eu estava qualificado para qualquer um dos trabalhos que eu tinha. Eu só me candidatei a eles, porque eu não percebi o quão pouco eu sabia, e só os consegui porque as pessoas que me entrevistaram não sabiam o que perguntar.

Dito isso, eu acabei me dando muito bem em cada uma dessas funções e me tornei um membro valorizado da equipe. Quando eu eventualmente saía (para o próximo desafio para o qual eu também não estava qualificado para fazer), era geralmente encarregado de contratar quem iria me substituir. Olhando para trás agora, sobre a forma como me comportei nessas entrevistas, estou impressionado pela forma como colocava muita ênfase no conhecimento – apesar da falta dele nessa área, quando comecei. Meu eu atual provavelmente não teria contratado meu antigo eu, embora eu sabia por experiência própria que o sucesso era possível.

Quanto mais eu trabalho na web, mais eu percebo que o que separa as pessoas boas das pessoas realmente boas não é o que elas sabem, mas sim como elas pensam. Obviamente conhecimento é importante – fundamental, em alguns casos – mas em um campo que muda tão rapidamente, como você vai adquirir esse conhecimento é sempre mais importante (pelo menos em longo prazo) do que o que você sabe em um determinado momento. E talvez o mais importante de tudo: como você usa esse conhecimento para resolver problemas cotidianos.

Há muitos artigos lá fora que falam sobre linguagens, frameworks e ferramentas que você precisa saber para conseguir um emprego. Eu queria ter uma abordagem diferente. Neste artigo, vou falar sobre a mentalidade de um engenheiro front-end, e espero dar uma resposta mais duradoura para a questão: como você se torna excelente?

Não basta resolver problemas, descubra o que está realmente acontecendo

Muitas pessoas que escrevem CSS e JavaScript fuçam até encontrar algo que funcione, e então elas simplesmente seguem em frente. Eu sei que isso acontece porque eu vejo isso o tempo todo durante as revisões de código.

Eu frequentemente pergunto a alguém: “Por que você adicionou float: left aqui?” ou “Este overflow: hidden é realmente necessário?”, e eles sempre respondem: “Eu não sei, mas se eu remover, para de funcionar”.

O mesmo é verdade para JavaScript. Vou ver um setTimeout sendo usado para evitar um race-condition, ou alguém parar a propagação do evento sem levar em conta como isso afetará outros manipuladores de eventos na página.

Entendo que há momentos em que você precisa que algo funcione, e você precisa disso agora. Mas se você nunca tirar um tempo para compreender a raiz do seu problema, irá se encontrar na mesma situação sempre.

Gastar seu tempo para descobrir por que suas obras de hacker funcionam pode parecer caro agora, mas eu prometo que vai lhe poupar tempo no futuro. Ter uma compreensão mais completa dos sistemas que você está trabalhando no momento significa menos trabalho de experimentar e testar no futuro.

Aprenda a antecipar futuras alterações no mercado de navegadores

Uma das principais diferenças entre código front e back-end é que o código de back-end geralmente é executado em um ambiente que está sob seu controle. O front-end, ao contrário, está completamente fora de seu controle. A plataforma ou o dispositivo que seus usuários têm pode mudar completamente a qualquer momento, e seu código precisa ser capaz de lidar com isso graciosamente.

Me recordo de ler o código-fonte de um código JavaScript popular em 2011 e ver a seguinte linha (alterada para simplificar):

var isIE6 = !isIE7 && !isIE8 && !isIE9;

Nesse caso, o IE6 foi o genérico para versões do IE, presumivelmente para lidar com as versões do IE superiores ao 6. Mas logo que o IE10 saiu, grandes porções da nossa aplicação quebraram completamente.

Eu entendo que no mundo real a detecção de recurso não funciona 100% do tempo, e às vezes você tem que depender de comportamento de erro ou navegadores whitelist cuja característica detecta erroneamente falsos positivos (ou negativos), mas, quando fizer isso, é absolutamente crítico que você antecipe o futuro quase certo no qual esses erros não existem mais.

Para muitos de nós, o código ficará mais tempo do que você no seu trabalho. Parte do código que eu escrevi mais de 8 anos atrás ainda está sendo executada em grandes sites em produção hoje, um pensamento que é ao mesmo tempo gratificante e aterrorizante.

Leia as especificações

Sempre haverá problemas de browsers, mas quando dois navegadores renderizam o mesmo código de forma diferente, as pessoas muitas vezes assumem, sem verificar por si mesmos, que o chamado “bom” navegador está certo e o “mau” navegador está errado. Mas esse nem sempre é o caso, e quando você está errado sobre esse pressuposto, qualquer solução alternativa que você escolher vai quase certamente quebrar no futuro.

Um exemplo oportuno disso é o tamanho mínimo padrão de itens dinâmicos. De acordo com a especificação, o valor inicial min-width e min-height para itens dinâmicos é auto (em vez de 0), o que significa que, por padrão, eles não devem encolher para menos do que o tamanho mínimo do seu conteúdo. Nos últimos 8 meses, o Firefox foi o único navegador que implementou isso corretamente.

Se você encontrou essa incompatibilidade cross-browser e notou que seu site renderizou o mesmo no Chrome, IE, Opera e Safari, mas parecia diferente no Firefox, você provavelmente assumiu que o Firefox estava errado. Na verdade, eu testemunhei isso acontecer muito. Muitos dos problemas relatados no meu projeto Flexbugs eram devido a essa incompatibilidade, e as soluções propostas, se implementadas, teriam falhado quando Chrome 44 foi lançado. Em vez de essas soluções alternativas seguirem a especificação, elas estavam, sem saber, penalizando o bom comportamento.

Quando dois ou mais navegadores processam o mesmo código de maneira diferente, você deve tirar um tempo para descobrir qual deles está correto e escrever seu código com isso em mente. Suas soluções serão muito mais à prova de futuro, como resultado.

Além disso, os chamados “grandes” engenheiros front-end são, muitas vezes, as pessoas na vanguarda da mudança, adotando novas tecnologias antes que elas sejam mainstream e até mesmo contribuindo para o desenvolvimento dessas tecnologias. Se você cultivar a sua capacidade de olhar para uma especificação e imaginar como a tecnologia vai funcionar antes que você possa colocá-la em um navegador, você fará parte de um seleto grupo que é capaz de falar e influenciar o desenvolvimento dessa especificação.

Leia código de outras pessoas

Ler o código de outras pessoas, por diversão, provavelmente não é sua ideia de lazer no sábado à noite, mas é sem dúvida uma das melhores maneiras de se tornar um desenvolvedor melhor.

Resolver problemas por conta própria é uma ótima maneira de aprender, mas se isso é tudo que você faz, você vai ficar estagnado muito rapidamente. Ler código de outras pessoas abre sua mente para novas maneiras de fazer as coisas. E a capacidade de ler e compreender o código que você não escreveu é essencial para trabalhar em uma equipe ou contribuir para projetos de código aberto.

Na verdade, eu acho que um dos maiores erros que as empresas fazem ao contratar novos engenheiros é pedir para escreverem código novo, do zero. Eu nunca estive em uma entrevista onde me pediram para ler algum código existente, encontrar os problemas dele, e em seguida, corrigir esses problemas. É realmente muito ruim, porque a maioria de seu tempo como um engenheiro é gasto adicionando ou alterando uma base de código existente. Raramente você estará construindo algo novo, do zero.

Trabalhe com pessoas mais inteligentes do que você

Tenho a impressão de que há muito mais desenvolvedores front-end que querem ser freelance (ou não trabalhar em tempo integral por si mesmos) do que há desenvolvedores back-end com o mesmo objetivo. Talvez seja porque pessoas de front-end tendem a ser autodidatas e pessoas de back-end tendem a vir da academia.

O problema de ser tanto autodidata e também trabalhar para si mesmo é que você geralmente não recebe o benefício de aprender com as pessoas mais inteligentes do que você. Você não tem ninguém para trocar ideias ou rever o seu código.

Eu recomendo fortemente, pelo menos durante a parte inicial de sua carreira, que você trabalhe em uma equipe, especialmente em uma equipe de pessoas que são mais inteligentes e mais experientes do que você.

Se você acabar trabalhando para si mesmo em algum momento de sua carreira, faça uma promessa de se tornar (ou manter) envolvido em código aberto. Contribuir ativamente para projetos open source te dará muitos dos mesmos benefícios de trabalhar em uma equipe, às vezes até mais.

Reinvente a roda

Reinventar a roda é ruim para os negócios, mas é ótimo para a aprendizagem. Você pode ser tentado a pegar esse typeahead widget ou uma biblioteca event delegation do NPM, mas imagine o quanto você pode aprender, tentando construir essas coisas você mesmo.

Tenho certeza de que algumas pessoas lendo este artigo estão se opondo fortemente a isso agora. Não me interpretem mal. Não estou dizendo que você nunca deve usar o código de terceiros. Usar bibliotecas bem testadas que têm a vantagem de anos de casos de teste e relatórios de erros é quase sempre a coisa inteligente a fazer.

Mas neste artigo eu estou falando sobre como ir de bom a ótimo. A maioria das pessoas que eu considero grande nessa indústria são os criadores ou mantenedores de bibliotecas muito populares que eu uso o tempo todo.

Você provavelmente poderia ter uma carreira de sucesso sem nunca construir a sua própria biblioteca JavaScript, mas provavelmente também nunca trabalharia perto o suficiente do metal realmente sujar suas mãos.

Uma pergunta comum que as pessoas fazem nessa indústria é: o que devo construir na sequência? Se você está fazendo essa pergunta, em vez de tentar aprender uma nova ferramenta ou criar algum novo aplicativo, por que não tentar recriar uma das suas bibliotecas JavaScript favoritas ou framework CSS? A coisa boa de fazer isso é que você nunca ficará preso, o código-fonte da biblioteca existente terá todas as respostas para você.

Escreva sobre o que você aprendeu

Por último, mas certamente não menos importante, você deve escrever sobre aquilo que aprendeu. Há muitas boas razões para fazer isso, mas talvez a melhor é que isso irá te forçar a compreender melhor o tópico. Se você não consegue explicar como algo funciona, há uma boa chance de que você realmente não entendeu o assunto. E muitas vezes você não percebe que você não entendeu até que você tente escrever a respeito.

Na minha experiência, escrever, palestrar e criar demos têm sido uma das melhores maneiras de me forçar a mergulhar e entender completamente alguma coisa, por dentro e por fora. Mesmo que ninguém nunca leia o que você escreve, o processo de fazer é mais do que válido.

***

Philip Walton faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://philipwalton.com/articles/how-to-become-a-great-front-end-engineer/