Como ser o pior front-end da empresa e estragar sua carreira

O primeiro passo para ser o pior front-end da empresa é não estudar.

Por falar nisso, porque você está aqui lendo esse blog? Pare já!

O pior front-end nunca estuda

Você já deve ter ouvido falar que a prática vale mais do que a teoria. Só não te contaram que ela é a única que vale.

Mas se algum dia você quiser estudar, faça o seguinte...

Estude React, Javascript, CSS e HTML (nessa ordem)

O motivo é muito simples, compare a média salarial de desenvolvedores React com desenvolvedores HTML. E agora responda: qual ganha mais?

Invista seu tempo apenas naquilo que traz um retorno financeiro maior.

Após estudar de forma geral essas tecnologias (até porque especialista não está com nada), mantenha esse conhecimento com você.

Não compartilhe conhecimento

É muito contraditório gastar dinheiro com faculdade, para depois ensinar os outros de graça. Nunca faça isso, mesmo que você reclame do preço da faculdade sem ter feito uma.

Mas tome cuidado! Quando te pedirem ajuda, nunca diga não de forma direta. Caso contrário, as pessoas não irão querer te ajudar no futuro

Peça a solução pronta

O pior front-end não precisa entender como as coisas funcionam.

Se um dia você precisar da ajuda de alguém (o que dificilmente vai acontecer), seja o mais direto possível. Copie a descrição da tarefa no Jira, cole no Slack, e aguarde seu colega responder com o código pronto.

Caso seja difícil conseguir o que queria, existem algumas frases chave para mandar:

• "Não está funcionando" (sem mais detalhes)

• "Deu erro" (essa é ótima)

• "Será que não existe outra forma de fazer isso?"

E a minha preferida:

• "Não quer me mostrar em uma video chamada?"

Nunca falha.

Caso peçam para ver seu código sem ser em uma vídeo chamada, você já sabe...

O pior front-end nunca usa Git

Git é confuso demais:

• O repositório existe de forma local no computador e remoto na nuvem

• Cada branch também, mas se for remota, chamam ela de origin

• Pull é puxar, mas push é empurrar

• Pushar (com "sh") é diferente de puxar (com "x"), e é o mesmo que push (que é empurrar)

• Se algum engraçadinho altera minha linha, tenho que resolver conflito (e claro que sempre mantenho meu código em cima dos outros)

Existe uma forma muito mais prática de fazer isso, e precisa de apenas 2 passos:

1. Compactar a pasta do repositório local

2. Enviar por e-mail ou subir no FTP

Se responderem seu e-mail com qualquer sugestão que não seja o que você pediu, ignore.

Nunca peça codereview

Por que você deveria pedir aprovação de um trabalho? Se a empresa te contratou, é porque confia em você.

Jogue tudo direto na branch main. Caso a branch principal seja a master, troque seu nome para main. Ninguém vai perceber.

Não importa se o time trabalha com um Git Flow estruturado. Outras branchs como develop, feature ou release devem ser ignoradas. O quanto antes você colocar em produção, mais pontos você entrega na sprint.

Da mesma forma, ignore pedidos de codereview. Apenas aprove e já faça o merge você mesmo. Assim, talvez ganhe mais pontos ainda.

Nunca use libs externas

Reinvente a roda.

O pior front-end não confia na comunidade open source. Usa o VS Code, Github e Stackoverflow, mas são exceções.

• Faça carrosséis na mão

• Construa sua própria SPA

• E se o tempo colaborar, adapte o Web Assembly para rodar sua própria linguagem de programação

Esqueça a refatoração

Por último, mas não menos importante, nunca refatore.

Funcionou? Partiu próxima task.

Até porque tempo é dinheiro, e o Jira não irá fazer suas tarefas sozinho.

Vamos celebrar o horror

De tudo isso - com festa, velório e caixão

Está tudo morto e enterrado agora

Já que também podemos celebrar

A estupidez de quem cantou esta canção