4 grandes mentiras que são contadas para programadores iniciantes

Quando você é criança ouve-se muitas coisas que depois descobre serem mentiras absolutas. A questão é que esse processo se repete: o que pode ser verdade na sua infância não se aplica na faculdade, e muitas coisas que podem ser verdade na faculdade podem ser descartadas quando você “vira profissional”. Equívocos sobre vários aspectos da vida de programador acabam sendo muito difíceis de identificar e espero que este artigo, baseado principalmente em minha própria experiência, forneça alguns insights úteis.

1. Se funcionar, não toque Ou o ditado mais comum: “Se não está quebrado, não conserte”.

Isso pode acontecer quando você quebra algo enquanto faz algo considerado insignificante ou quando sugere uma melhoria. Como você provavelmente já ouviu falar em seu próprio trabalho, sugerir melhorias é uma coisa boa. Mas, na prática, na maioria das vezes, sua idéia não será aceita no início. Além disso, muitas vezes você pode sentir que é punido por boas ideias. Não deixe isso te desanimar!
“Não está quebrado”. Isso é uma mentira, ou uma desculpa ridícula. De um modo geral, nenhum código é intocável. Embora existam muitas metáforas para o processo de desenvolvimento de software, todas elas descrevem um processo. Não importa quão bom o programa tenha planejado, na vida real ele evolui e muda. Desde refatorar um design ruim, até remover código inúteis e adicionar ou atualizar comentários. Faz parte de sua vida saudável, caso contrário o “jardim” se torna insalubre, feio e, eventualmente morto.
Ao contrário dos projetos na universidade, nada é realmente “feito”. Portanto, não, o fato de o código funcionar não é desculpa para não fazer alterações, mesmo que sejam inúteis em termos de funcionalidade.

2. Conhecimento não compartilhado é segurança no trabalho Ou: Código complexo é segurança de trabalho.

Esse é muitas vezes contado como uma piada, mas, infelizmente, para alguns desenvolvedores, é na verdade uma estratégia bastante não oficial para… segurança do trabalho. Em nenhum lugar (que eu saiba) você encontrará isso como uma sugestão real, mas a ideia está fixa na mente de muitos programadores.
Então, em primeiro lugar, a segurança no emprego é uma mentira e as empresas não mantêm alguém por perto apenas porque são especialistas em algum projeto obscuro de legado de vodu que todo mundo tem medo. Simplificando, nenhuma pessoa é insubstituível e, se for o caso, nenhum módulo também é.
Mas mesmo que fosse verdade, não é como se você não estivesse pagando um preço por sua “segurança” se você seguir esse caminho. Na verdade, você está perdendo muito. Se você tem a intenção de crescer e avançar, em sua empresa e profissionalmente em geral, um dos elementos mais produtivos (e divertidos) do seu trabalho será compartilhar conhecimento. É o que torna sua equipe eficaz, geralmente é como você obtém informações valiosas sobre seu próprio trabalho, inspira e se inspira, e é parte do que pode eventualmente irá torná-lo a pessoa mais importante.
Agora de volta ao ponto de segurança. Você ainda pode perguntar, e é daí que vem a afirmação: “Mas se eu passar tudo o que sei, por que me manter aqui?” Porque você é bom em seu trabalho e, como acabei de explicar, compartilhar conhecimento faz parte de se tornar bom. Na verdade, confie em mim: você sabe mais do que pensa, mesmo que esteja longe de ser o cara mais experiente da empresa. Em algum momento, simplesmente não há tempo suficiente para compartilhar tópicos importantes, mesmo da maneira mais concisa.
Além disso, seu empregador sempre valorizará suas iniciativas para compartilhar conhecimento, pois é um problema notoriamente difícil fazer com que as pessoas o façam mais (não apenas no mundo do software). Vamos colocar desta forma: A pergunta que você realmente deve fazer é: “Mas se eu passar tudo o que sei, por que não me promover?”

3. Você não está em posição de desafiar X

“Você” como iniciante e “X” sendo uma pessoa, uma ideia, uma política, decisão de produto e assim por diante. Outra maneira de colocar isso é: “Não seja o encrenqueiro”. Spoiler: é mentira.
Provavelmente ninguém nunca disse isso para você. Mas, especialmente como um júnior, você terá uma noção dessa resistência a qualquer entrada que possa oferecer, desde pequenos detalhes de implementação até “como as coisas estão aqui”.
É importante observar que o nível e a natureza dessa resistência variam muito entre as organizações e entre as equipes. Mas, está sempre lá, e sempre estará. Aceite-o e aprenda a trabalhar com ele. Como eu disse anteriormente, não deixe isso te desencorajar. Mesmo que pareça pessoal (o que provavelmente não é).
A ideia de que você não está em posição de desafiar, questionar, oferecer ou liderar uma mudança é uma mentira na sua cabeça. É claro que há uma quantidade saudável de humildade que todos devemos ter, como este post enfatiza lindamente. Impulsionar a mudança, grande ou pequena, é, antes de tudo, falar com as pessoas. As pessoas sempre sabem ou veem algo de forma diferente, então há muito a dizer sobre como fazê-lo. Mas se há uma regra que sempre tive em relação a falar o que penso é esta: seja destemido.
Aceite a possibilidade provável de que você esteja errado e, em caso afirmativo, assuma-o. Isso também é uma grande parte do aprendizado. Você não precisa aceitar nada como evangelho e, ao se manifestar, pode muito bem dizer o que os outros estavam pensando.

4. Um dia de trabalho é um dia de trabalho

Os atrasos são ruins. Para você, sua equipe e sua empresa. No entanto, de alguma forma, nunca os vemos chegando. O que é que transforma algo aparentemente tão previsível em uma eterna surpresa desagradável? Em suma, ingenuidade. Uma mentalidade falsa, que cria um monte de pequenas mentiras, que muitas vezes obscurecem uma verdade simples: tudo leva tempo.

Tudo, neste caso, significa tudo. Cada pequena tarefa, como mudar o foco, compilar, ler e-mails e pedir almoço. Tudo inclui um monte de coisas que você quase nunca considera.

Veja este recurso trivial: você precisa fornecer uma função que execute um script. É isso. Se você acha que é uma coisa de um dia, digamos, sem reuniões e interrupções, tenha paciência:

• 10h: Comece a analisar os “requisito”. O que você faz com os erros? Ou o valor de saída? E se ficarmos presos – há um tempo limite? Um configurável? Você precisa interceptar a saída? E se for enorme? Você entendeu: a primeira questão será obter os requisitos reais. Você provavelmente precisa de pessoas para isso – então você vai procurá-las. Meio dia se foi. Almoço.
• 14:00: Ao discutir os requisitos, acontece que outro projeto precisa usar sua função, então você não pode simplesmente colocá-la em seu projeto. Mais uma hora de debates políticos sobre onde colocá-lo e como, e então realmente fazê-lo. Além de uma pausa para o café.
• 16:00: Finalmente escrevendo algum código. E adivinhe, você termina às 18h! Então, na verdade, foi um recurso de 2 horas, não foi? Agora, no entanto, você precisa de um ambiente de teste. Fim do dia.
• No dia seguinte: você tem seu ambiente de teste às 10h, escreve alguns scripts para testar às 12h, manipula e testa alguns cenários às 14h, testes de unidade (não TDD, mas apenas muda a ordem) até o final do dia.
• Outro dia…: solicitação de pull, revisões, mesclagem e um pequeno documento.

O recurso está disponível após três dias de trabalho ininterrupto, rápido e bastante suave. Você pode imaginar que com interrupções e reuniões são pelo menos quatro, para um recurso supostamente de um dia. Como assim? Bem, tudo leva tempo. O que nós, como programadores, geralmente percebemos como trabalho é muito menos proporcional ao trabalho real do que pensamos, mas nosso ego não nos deixa admitir isso.

Temos que lembrar que a codificação real está longe de ocupar a maior parte do nosso tempo e esforço. Nem deveria. Afinal, a codificação não é o objetivo, não é? Resolver problemas é. Mais uma vez estou pegando emprestado um pouco da sabedoria dos papas da programação. Pode ser mais difícil ver quando você está tão ocupado aprimorando suas habilidades no início de sua carreira e escalando penhascos técnicos íngremes, cinco minutos depois de deixar um ambiente onde você estava sendo medido tão tecnicamente.

As habilidades que mais importam, pelas quais você é avaliado, vão muito além da técnica. A única expressão que consigo pensar, que meio que os descreve, é uma palavra: Profissionalismo . Mas isso não é tudo, pois o objetivo é resolver o problema. A fórmula pode parecer ótima e ainda não funcionar por motivos que ninguém realmente se importa – porque o objetivo é o resultado.

Então, vamos colocar desta forma: você é medido pelo seu profissionalismo e como você o traduz em resultados.

Conclusão

Não faltam ideias extremamente populares que não são baseadas na realidade. Descobrir os menos óbvios, especialmente aqueles que exigem uma mudança em nosso comportamento ou atitude, pode dar algum trabalho. Mas isso faz parte da jornada – e é divertido!