O que um gestor de projetos espera de um programador iniciante — Parte 1
Abro este texto já explicando: não sou um programador. Trabalho com desenvolvimento, mas não propriamente como desenvolvedor. O que apresento é um colegiado de princípios que parecem ser basais para um bom ambiente de trabalho, sadio e eficiente, mas que devem, como todas as boas práticas, serem aplicados durante o aprendizado.
O que escrevo aqui é um conjunto de instruções iniciais para aqueles que desejam iniciar no mundo da programação. É muito fácil olhar a tela e procurar, em dois ou três cliques, uma vídeo-aula, um curso, um artigo nos numerosos fóruns sobre os mais diversos assuntos. Mas esta, talvez, não seja a melhor maneira de se iniciar nesse mundo — principalmente porque pode não te entregar um conjunto importante de ideais que são essenciais ao trabalho.
Espero que seja proveitoso ou, no mínimo, interessante.
Comece pelo começo
É sério, parece besta, mas é bastante sério. Não adianta abocanhar o mundo ou segurar os céus sob os ombros (tal qual um Atlas moderno). Há uma infinidade de caminhos. C#, C, C++, Java, JavaScript, Python, Ruby, R, React, Flutter, PHP, CSS, HTML, Swift. São gigantescas as possibilidades de aprendizado. Cada um destes é (ou aparenta ser) mais ideal para determinados assuntos. Python para Machine Learning ou Data Science (R para este último também), CSS e HTML para interfaces (não?), Ruby, não sei, web? Flutter para aplicativos mobile e por aí vai.
Procure algo que gosta de fazer, que sente vontade e gana de conseguir. Qualquer coisa. Não importa o quê. Pode ser sites (acho incríveis sites como o próprio medium, que parecem tão simples mas carregam tanto poder), aplicativos, softwares, Data Science, estatística (!!!). O que for. A internet, muito provavelmente, te dá vontade de algo, se não você não estaria querendo começar nada. Sabendo o que te dá vontade você tem condições de iniciar.
E o ideal, o mais tranquilo, é que o início seja lento, demorado. Como um infante, que se aventura pela primeira vez por uma sala de jantar, conhecendo as maravilhas do que é aquela estrutura quadrúpede, madeirada, com um retirado aconchegante e quente — também conhecido como cadeira — você dará os primeiros passos por esse mundo. As coisas mais simples, como saber onde você vai escrever os códigos, baixar a linguagem (ou seja lá como isso se chama), serão desafiadores e precisam ser desafiadores. Entenda como tudo isso funciona, já que vai facilitar sua vida no futuro. Entenda como a linguagem funciona, como ela atua, como ela age e de que maneira ela gera os resultados esperados. Foque nela o quanto for preciso até ter confiança em fazer o que gostaria de fazer.
Não, não precisa de haver dois monitores, ou três. Não há necessidade de já se tornar proficiente em duas ou três linguagens. Não precisa produzir nada que seja excessivamente complicado. Aprenda tranquilamente, no seu ritmo (se você já não trabalha e não possui nenhum deadline). Mas aprenda constantemente. Não pare. Estude todos os dias, tenha disciplina e continue. O esforço não trai.
Leia a Documentação
Muito do que você não entende ou que esta falhando pode ser corrigido procurando na internet. Há excelentes sites para tal (o mais famoso o StackOverflow, creio). E muitas vezes eles podem te responder qual o problema com seu código. Contudo, muitas vezes, os problemas são contextuais e as respostas também.
Sabe onde as respostas são as mais generalistas possíveis? Na documentação original. Claro, talvez o que esta escrito será bem mais dificultoso do que a resposta de um usuário (e comentarei disso depois), mas quase sempre possui o que é necessário para matar sua dúvida. Não deixe de ler a documentação.
A similaridade da ciência historiográfica, é melhor perquirir nas fontes primárias de solução do que nas interpretações e contextualizações de outros indivíduos que, invariavelmente, estão recontando a documentação pelas suas óticas e metodologias. Vá na fonte e beba o máximo possível.
Não existe gambiarra
Ao longo dos anos, se criou uma cultura neste ecossistema da programação de se utilizar do mais brasileiro dos artifícios: a gambiarra. As vezes, quando o código falha, se faz uma ou duas alterações, se coloca uma ou duas variáveis aqui e ali e pronto, tudo volta a pegar — artificialmente.
Serei bem enfático: não existe gambiarra. Esqueça essa ideia. Não trabalhe se apoiando nesses artifícios do código. A gambiarra tem um nome dentro do ambiente de trabalho, das equipes de desenvolvimento. Tem um nome muito claro dentro do ambiente em que atuo: preguiça. De maneira mais formal, o correto seria débito técnico — você fica devendo trabalho que terá de ser reposto quando sua gambiarra não atender todo o necessário.
Faça o correto, da maneira mais otimizada possível. Parece bobo dizer, mas quando não se faz o melhor possível, o código esta fadado a erros. E os erros, as vezes, acontecem no pior momento possível. A título de exemplo, o aplicativo para votação do PSDB não funcionou para o acesso dos 45k de filiados do partido. Um erro deste não pode ocorrer num momento como este. E a gambiarra é o progenitor do erro.
Estes foram três pequenas dicas que fariam a minha vida como gestor mais fácil e que fariam a vida dos programadores mais eficiente, produtiva e tranquila. Por obviedade, há um caráter subjetivo colossal: é a visão de uma pessoa, a partir do que encontra no cotidiano de trabalho.
Haverá uma segunda parte, logo logo. Enquanto isso, deixo como recomendação um pequeno canal, que imagino ser bem didático e, pela experiência do apresentador, bastante competente no que faz.
Até a próxima o//
