Como ser um desenvolvedor incrível de 50 anos

A verdadeira velhice começa quando se olha para trás e não para a frente.

O machado caiu sobre mim quando eu menos esperava; no final de mais uma sexta-feira à noite.

“Jack”, meu chefe começou a falar em um tom incomumente subjugado.

“Como você sabe, os negócios estão lentos há algum tempo e a organização precisa tomar algumas medidas difíceis agora para sobreviver a essa fase. Portanto, decidimos diminuir o tamanho de nossa força de trabalho e seu papel não seria mais necessário como parte dessa reestruturação. Sinto muito.”

Eu tinha 50 anos e estava trabalhando como parte da mesma organização nos últimos 20 anos. A vida tinha sido legal e eu me estabeleci em uma vida de conforto, complacência e trabalho “ rotineiro ” operacional.

Uma onda de indignação tomou conta de mim, seguida de desgosto, depois raiva e, finalmente, acabou com o medo que corroía constantemente. Nenhuma palavra saiu da minha boca enquanto eu ouvia mais.

“No entanto”, ele continuou, parando por um minuto que parecia uma eternidade para mim.

“A organização gostaria de lhe dar outra chance, considerando seu longo tempo conosco. Precisamos de outro desenvolvedor para o projeto clarus que acabamos de ganhar. Se você acha que pode melhorar suas habilidades de codificação e chegar à velocidade nos próximos 3 meses, podemos considerá-lo para esse papel. Lembre-se de que este é um projeto de alto nível e não podemos permitir nenhum link fraco. A escolha é sua .

Eu desenvolvi meu último código há 15 anos e desde então meu trabalho tinha sido apenas questões operacionais e de gerenciamento de recursos. A possibilidade de eu ” codificar ” de novo era tão distante quanto chegar a Timbuktu. As probabilidades, incluindo a minha idade, estavam fortemente empilhadas contra mim.

Demorei um dia e pensei muito em dizer “ sim ”.

E já se passaram seis meses desde então.

Em seis meses eu me tornei um desenvolvedor incrível.

Em seis meses, tornei-me inestimável e indispensável.

E aqui está como eu fiz isso …

Seja o mestre de apenas um comércio de cada vez. É isso!

Epicteto disse corretamente.

“Nenhum homem é livre quem não é dono de si mesmo. “

“Ben é um especialista em SAP BADIs.Eu preciso ser como ele.”

“Tom finaliza rapidamente os testes de negócios, identificando as áreas certas. Eu preciso bater isso.

“Susie cria ótimos relatórios de ALV. Eu preciso dominar isso.

Estes foram alguns dos pensamentos que passaram pela minha cabeça, mas eu os bani rapidamente.

Eu percebi que eu preciso ser um mestre de mim mesmo. Eu não posso me tornar o mestre competindo com a expertise e a velocidade dos “ outros ”. Isso só levará a mais frustração e desmoralização. Eu preciso encontrar rapidamente a minha área de nicho e excel nele.

No projeto Clarus, muitos SAP Smarforms foram necessários com diferentes graus de personalização. Formas eram uma área que nenhum desenvolvedor seria “profundamente” interessado, dada a sua natureza complicada do trabalho e “paciência” necessária para criar a forma correta com o alinhamento perfeito. Eu fiz o ” domínio ” sobre as formas, meu objetivo final para os próximos três meses.

Foi uma situação ganha-ganha. A equipe estava feliz e recebi meu Mojo de volta.

Saiba o que desmarcar.

Larry Niven acerta a cabeça quando ela diz.

“Metade da sabedoria é aprender o que desaprender.”

Como a tecnologia marcha implacavelmente, as coisas que costumavam ser de suma importância caem do caminho. Não apenas se tornam inúteis, mas também reduzem nossa eficácia.

Por exemplo, quando eu estava programando pela primeira vez, as sobreposições de memória eram um grande problema. O programa inteiro não caberia na memória principal, então eu costumava dividi-lo em pedaços e trocar os pedaços para dentro e para fora. Isso exigiu um design e um estilo de codificação diferentes.

Agora a limitação de memória não é um problema na maioria dos casos.

Mas os velhos hábitos são difíceis de quebrar e ainda mais difíceis de perceber. O primeiro passo para desaprender é “ perceber ” que você está usando uma abordagem desatualizada e o segundo passo é deixá-lo “ ir ”.

Não completamente embora !!!

Você ainda precisa usar a lógica antiga no contexto certo e tirar todos os dendritos do corpo. Por exemplo, eu trabalhei no SAP Script, que é uma versão muito mais antiga do desenvolvimento de formulários. A lógica das formas permanece a mesma, eu apenas substitui e dominei o novo IDE e as funcionalidades que vieram com o Smartforms.

Em palavras simples, descartei as antigas ferramentas de linguagem e criei “ novos ” hábitos e associações com as novas ferramentas. A transição tornou-se muito mais fácil assim.

Pergunta até você entender

Indira Gandhi acerta quando diz.

“O poder de questionar é a base de todo progresso humano.”

Considere como um médico trabalha. Quando você não está bem, o médico lhe faz várias perguntas – seus hábitos, o que você comeu, onde dói, que medicação está tomando e assim por diante. O corpo humano é complexo e muitas coisas podem afetá-lo. E a menos que o médico seja persistente, ele errará completamente os sintomas.

Qualquer software funciona da mesma maneira. Eu sou o médico neste caso e meu código é o paciente. Eu preciso deixar o meu ” ego ” e chegar ao jeito ” certo ” de fazer as coisas. Preciso me graduar de ” fazer ” para ” por que estou fazendo isso ” para chegar à raiz do problema.

É minha responsabilidade pedir aos outros que me suportem – tenham paciência – enquanto continuo fazendo perguntas que podem ser relevantes às vezes e, às vezes, francamente bobas.

Meu questionamento funcionou e, em muitos casos, muitos casos deram uma nova perspectiva à equipe para resolver um problema.

Como Richard Feynman disse corretamente.

“Eu prefiro ter perguntas que não podem ser respondidas do que respostas que não podem ser questionadas.”

Código em incrementos

Confúcio disse com razão.

“O homem que move uma montanha começa levando pequenas pedras.”

O que você faz quando vai em uma longa viagem?

Você apenas senta-se firmemente em uma posição, olha para frente e para o chão?

Claro que não.

Você tem que dirigir. Você precisa verificar o tráfego e também precisa parar conforme necessário para comida e combustível. Só então a sua longa jornada chega a um final bem-sucedido.

A codificação funciona da mesma maneira, especialmente depois de um longo intervalo.

Não codifique por horas sem parar sem parar. Em vez disso, codifique em incrementos curtos. Codificar em incrementos ajuda não apenas a estruturar seu código corretamente, mas também oferece a chance de fazer testes unitários abrangentes em pequenos blocos de código.

Você deve avaliar constantemente como o código está se configurando. Você também notará que fazer pequenos ajustes são muito mais eficazes do que fazer alterações longas no final.

A chave é continuar fazendo algo pequeno e útil e anotar as vitórias “ pequenas ”, em vez de economizar para uma longa sessão de codificação.

Obtenha feedbacks frequentes e aja no mesmo

Robert Allen disse corretamente.

“Não há falha. Apenas feedback.

Qual é a palavra mais curta na língua inglesa que contém alfabetos abcdef ?

É FEEDBACK.

E é a arma mais importante no arsenal de qualquer desenvolvedor, seja experiente ou novato.

Muito raramente nos deparamos com situações em que temos especificações funcionais ou técnicas “ totalmente congeladas ” expressas em pedra. A única coisa que qualquer desenvolvedor precisa fazer é ler os requisitos e iniciar a codificação.

Não funciona assim no mundo real.

No mundo real, os requisitos são tão fluidos quanto a tinta e estão em constante evolução. Se você tentar congelar os requisitos, você acabará congelando os errados.

É por isso que o feedback frequente é tão importante; de seus colegas, de seus clientes e até mesmo de seus fornecedores terceirizados com quem seu código foi integrado.

Por exemplo, quando comecei a criar formulários SAP, agendava sessões de feedback frequentes com meus colegas e meus usuários finais em intervalos regulares. Isso não apenas melhorou minha confiança e minha posição, mas eliminou todas as minhas lacunas de compreensão de uma forma muito concisa. Raramente me encontrei em situações em que precisei ” retrabalhar ” o código novamente.

Obtenha feedback com frequência e mantenha a frequência como semanal ou quinzenal. Isso mantém o aplicativo à vista durante o desenvolvimento e leva à colaboração coletiva.

Meça o progresso real

Dag Hammarskjold disse corretamente.

“Nunca meça a altura de uma montanha até chegar ao topo. Então você verá o quão baixo foi.

Meu primeiro desenvolvimento de formulário quase me levou 5 semanas para completar (inclusive fins de semana também !!)

Minha segunda forma levou 3 semanas.

Meu terceiro formulário foi concluído em apenas 10 dias até o final.

Quando você finalmente terminar uma tarefa, acompanhe o tempo que realmente demorou para ser concluído. As probabilidades são, levaria muito mais tempo do que o estimado, especialmente quando você está apenas começando. A chave é fatorar e adicionar os dados reais ao próximo desenvolvimento, para que você se aproxime o máximo possível da realidade.

Você vai zigue-zaguear por um tempo, às vezes superestimando, às vezes subestimando, mas mais cedo ou mais tarde você se tornará um profissional e terá uma noção melhor de quanto tempo leva para completar um determinado desenvolvimento.

Um lado vantagem de estimativas precisas é que você melhora a sua posição entre os seus pares e o cliente começa a ” acreditar ” em você. Isso age como um catalisador para aumentar sua auto-estima e faz maravilhas em seus níveis de confiança.

Mantenha todos informados

Seth Godin disse corretamente.

“Quanto menos as pessoas sabem, mais elas gritam.”

Ao aceitar uma tarefa, você concordou em entregá-la a tempo. Mas nos deparamos com problemas e lacunas além do nosso controle. Imagine uma situação quando você chega em uma reunião de ” demonstração ” e informa tudo o que você ainda não concluiu o código? Qual é a imagem que você está transmitindo aos outros sobre você?

Faltar o prazo não é apenas embaraçoso, mas também dá aos outros a oportunidade de ” microgerenciar ” o seu trabalho. Todo mundo vai começar a verificar com você várias vezes ao dia para ter certeza de que você não perderá o prazo novamente. Isso é prejudicial para qualquer desenvolvedor seja novo como eu ou os experientes.

Ao manter os outros informados, você elimina surpresas e eles ficam confortáveis ??quando conhecem seu progresso. Eles sabem quando ajudá-lo e você acaba ganhando a confiança deles .

A chave é “ sempre sob compromisso, mas entregar mais ”. Esse mantra sempre funciona.

Juntando tudo

Em última análise, tudo está na mente. A vida me deu duas escolhas; quer me reinventar e fazer algo novo ou entrar em um lamaçal interminável de autopiedade e inutilidade. Eu escolhi o primeiro e o resto foi história.

Como Satchel Paige disse corretamente:

Em seis meses, tornei-me inestimável e indispensável.

0

Em seis meses, tornei-me inestimável e indispensável.

1

Em seis meses, tornei-me inestimável e indispensável.

2

 

Texto original em inglês.