Um bom programador é calmo e decisivo sob pressão.

Pressão é algo que você sente quando não sabe o que está fazendo.

Ravi Shankar Rajan Blocked Desbloquear Seguir Seguindo 5 de janeiro Créditos da Imagem: unsplash.com Jacob Townsend

De muitas maneiras, escrever código é quase como realizar uma cirurgia.

O cirurgião está tentando salvar sua vida, mas ele está operando dentro de um prazo, um prazo que não é negociável. Ele está sob intensa pressão.

Como você quer que o médico se comporte? Você quer que ele pareça calmo e colecionado? Você quer que ele faça ordens claras e precisas para sua equipe de suporte? Você o quer seguindo seu treinamento e aderindo às suas disciplinas?

Ou você o quer suando e jurando? Você gostaria que ele quebrasse sob pressão e fizesse atividades irracionais? Você confiaria em sua vida com tal médico?

Um bom programador simplesmente não se torna bom porque ele escreve um código incrível. Ele se torna bom porque permanece calmo e decidido em situações de pressão. À medida que a pressão cresce, ele adere ao seu treinamento e disciplina, sabendo que eles são a melhor maneira de cumprir os prazos e compromissos que estão pressionando-o.

Em suma, ele faz e continua fazendo a coisa certa que deve ser feita, independentemente dos prazos que se aproximam dele.

E esta não é uma tarefa fácil de fazer, dia após dia. O desafio é manter a calma o suficiente para lidar com a pressão no momento, para que você possa ter sucesso no futuro.

E aqui estão algumas das maneiras pelas quais os bons programadores lidam com a pressão.

Não honre os compromissos não feitos por você

Como programador, você sempre tem duas opções – seu compromisso versus seu medo.

Seu compromisso é a data e o prazo dado por você para concluir seu trabalho. E quando você faz isso, a coisa mais importante que você tem com você é sua palavra, sua confiança. Você tem que fazer acontecer, aconteça o que acontecer. É aí que você ganha seu respeito.

Você sente medo é quando alguém faz um compromisso em seu nome.

Sim, isso acontece. Às vezes, compromissos são feitos por nós. Às vezes, descobrimos que nosso negócio fez promessas aos clientes sem nos consultar. No entanto, não somos obrigados pela honra a aceitar os compromissos.

A diferença entre compromissos é importante.

Os profissionais sempre ajudarão a empresa a encontrar uma maneira de atingir seus objetivos. Mas os profissionais não aceitam necessariamente os compromissos assumidos por eles pelo negócio. No final, se não conseguirmos encontrar uma maneira de cumprir as promessas feitas pela empresa, as pessoas que fizeram as promessas devem aceitar a responsabilidade.

Isso não é fácil. A pressão atinge todos quando os compromissos não são cumpridos. Mas, pelo menos, se você se comportou profissionalmente, pode manter a cabeça erguida e manter seu apoio.

E se ninguém estiver disposto a entender seu ponto de vista, é hora de deixar seu emprego.

Não corte cantos.

Não há nada chamado “ código Qick e Dirty ”. Código sujo é um código ruim. Período. Nunca corte cantos ou aceite qualquer coisa que seja de segunda ordem.

Seu verdadeiro teste como um bom programador está sob crise. Se o seu comportamento mudar durante uma crise, então você não é um bom programador. Por exemplo, se você seguir a disciplina do Desenvolvimento Orientado a Testes em tempos sem crise, mas abandoná-lo durante uma crise, então não confia realmente que o TDD seja útil. Se você mantiver seu código limpo durante os tempos normais, mas fizer bagunça em uma crise, então você realmente não acredita que a bagunça o atrapalha.

Nunca negligencie as pequenas coisas. Nunca economize esse esforço extra, que alguns minutos adicionais, essa entrega do melhor que você pode fazer. Não importa o que os outros pensam, é de suma importância, no entanto, o que você pensa sobre você. Lembre-se sempre de que cortar cantos irá assombrá-lo, se não agora mais tarde.

E programadores profissionais nunca pegam o caminho fácil e criam códigos confusos para se mover rapidamente. Eles fazem o melhor trabalho possível e fornecem a saída mais limpa possível, aconteça o que acontecer.

Comunique-se, comunique-se e comunique-se.

Comunicação. É sobre honestidade. Trata-se de tratar as pessoas da organização como merecedoras de conhecer os fatos. Você não tenta dar a metade da história. Você não tenta esconder a história. Você os trata como … como verdadeiros iguais, e você se comunica e se comunica e se comunica.

Se você tem informações importantes para compartilhar com seu chefe, colegas, fornecedores – mesmo que não sejam ótimas notícias – não espere. Se você adiar o fornecimento de informações acionáveis até que seja tarde demais para agir, suas notícias nunca serão bem recebidas, seja ela boa ou ruim.

Em quase todos os cenários concebíveis, é vantajoso para você se comunicar o mais rápido possível, permitindo que todos os envolvidos entendam e digeram as informações, formular uma reação apropriada e responder adequadamente. Se for uma má notícia, seu aviso prévio pode permitir um planejamento suficiente para minimizar os danos.

Acima de tudo, mantenha-se profissional, educado, direto e claro – todas as características que irão mover sua comunicação na direção certa durante seu tempo em seu atual local de trabalho.

E, finalmente, obter ajuda quando o que for fica difícil

Par! Quando o calor estiver ligado, encontre um associado que esteja disposto a parear o programa com você. Você será feito mais rápido, com menos defeitos. Seu par parceiro irá ajudá-lo a manter suas disciplinas e evitar que entre em pânico.

O rápido tempo de desenvolvimento do par geralmente vem de um foco maior. Emparelhar-se literalmente é ter outra pessoa olhando por cima do seu ombro o tempo todo. As pessoas que participam ativamente no emparelhamento têm menos probabilidade de se distrair com interrupções ( por exemplo, verificar e-mail, vagar por tarefas não relacionadas ou olhar fixamente para a tela por minutos a fio ).

Mesmo tarefas secundárias relacionadas podem ser bloqueadas. A pessoa no teclado pode se concentrar em apenas batendo o código, enquanto o parceiro pode se preocupar a legibilidade, testabilidade, robustez, a migração de upgrade do usuário, e outros “big picture” questões relacionadas com o novo código. Trabalhar com um par fornece pressão positiva para permanecer na tarefa.

O período de adaptação da programação solo à programação colaborativa é como comer uma pimenta. A primeira vez que você tentar, você pode não gostar porque você não está acostumado com isso. No entanto, quanto mais você come, mais você gosta.