Quais estressores os programadores encontram no trabalho e como você lida com eles? [fechadas]

Aprender a gerenciar o estresse é vital para se manter saudável enquanto trabalha em qualquer trabalho. Uma subtarefa necessária é aprender a reconhecer e limitar as fontes de estresse.

Mas, no meio da rotina diária, pode ser difícil reconhecer fontes de estresse (especialmente para uma pessoa intensa e focada, como um programador).

Que tipos de estressores os programadores devem procurar e como podem ser gerenciados?

Aqui estão as coisas que acho mais estressantes para mim e para os desenvolvedores ao meu redor:

1. Ambiguidade : metas, requisitos ou outras expectativas declaradas de maneira ineficaz. Muitas empresas têm funcionários que têm uma atitude de"I don't know what I want, but I'll know it when I see it. Oh, and by the way I need it tomorrow."
2. Prazos inadequados : a maioria dos prazos é definida pelo negócio, não pelos recursos realistas dos desenvolvedores na equipe. Além disso, as expectativas para o requisito aumentam, mas o orçamento / recursos não.
3. Más premissas / expectativas : os programadores tendem a ter uma alta opinião de suas capacidades (não uma característica não aprendida) e, por isso, esperam que outras pessoas possam corresponder às suas capacidades, compreensão e expectativas. Freqüentemente, é assumido que algo é "common knowledge"semelhante, e isso pode ser catastrófico na categoria de estresse. Agora, o especialista em negócios não apenas não atendeu às expectativas do programador, como é um completo incompetente para inicializar. Por outro lado, se o programador não atender às expectativas da empresa, ele fica frustrado porque não recebeu as informações necessárias para prosseguir.
4. Falta de respeito : muitas pessoas tendem a acreditar que só porque alguém é fraco em sua disciplina, isso significa que eles são fracos na deles. Há uma razão pela qual todos temos diferentes empregos / capacidades / expectativas, e é importante respeitar que a outra pessoa é muito provavelmente muito capaz nas tarefas que são solicitadas a fazer. Só porque alguém não tem suas capacidades não significa que seja incompetente ou incapaz.
5. Falta de autocontrole : isso pode se manifestar em muitas coisas. Talvez você seja um trabalhador que se recusa a fazer as pausas adequadas. Isso leva ao aumento do estresse e é ruim. Talvez você seja um bebedor de Jolt Cola que bebe mais cafeína do que deveria quando o estresse se acumula. Isso faz mal à sua saúde e piora sua resposta ao estresse. Você precisa conhecer seus limites, saber o que desencadeia suas respostas específicas ao estresse e, o mais importante, saber como aliviar essa resposta ao estresse. Não é apropriado retirá-lo de colegas de trabalho ou colegas e servirá apenas para aumentar o estresse.
6. Falta de habilidade de comunicação : geralmente não falamos o mesmo idioma e não estou falando de inglês, alemão ou indiano. Estamos usando as mesmas palavras, mas não estamos dizendo as mesmas coisas. As pessoas precisam ser específicas e abertas sobre coisas que não entendem. Mesmo se você acha que entende, não custa nada esclarecer. Lembre-se de que uma métrica comercial pode significar algo diferente para diferentes departamentos de uma organização.
7. Sangramento de limites : mantenha o trabalho no trabalho e em casa em casa. Só porque sua criança de 7 anos está deixando os sapatos no meio do chão e não limpando o banheiro depois do café da manhã não significa que você precisa retirar Tiffany da contabilidade de uma nova porque ela não lhe forneceu a planilha de requisitos de cobrança . O mesmo motivo, só porque Tiffany está fracassando com a planilha não significa que sua esposa merece ser maltratada no trajeto para casa. (Aliás, a pobre Tiffany também não merece esse tratamento)

Eu acho que o maior estressor para qualquer programador é a falta de confiança .

Sim, muitas reuniões (certamente não reuniões propriamente ditas) são desnecessárias, mas há muito que eu, como programador, posso fazer sobre isso. Se eu tiver que participar regularmente de reuniões que - na minha opinião - não são necessárias, é minha responsabilidade me levantar e dizer "ei, não preciso estar nessa reunião - posso gastar meu tempo de forma mais produtiva".

O mesmo vale para interrupções: Sim, isso é um aborrecimento. Eu já vi isso em várias empresas. No entanto, muitas vezes, mais uma vez, há várias coisas que podem ser feitas. Um programador não precisa verificar sua conta de email a cada cinco minutos e responder a todos os emails instantaneamente. Da mesma forma, se eu não quiser ser incomodado por um certo período de tempo, desligo meu messenger instantâneo e encaminhar meu telefone.

Estes são apenas dois exemplos - há muito mais. Sim, às vezes as coisas ficam difíceis. Mas na maioria das vezes, os problemas de que estamos falando podem ser resolvidos facilmente com um pouco mais de confiança. Diga às pessoas do outro lado do ciclo de comunicação "sim, eu ouvi você e recebi sua mensagem, mas chegarei a isso mais tarde".

Os maiores problemas são aqueles que estamos criando! ;-)

Bugs de componentes de terceiros

Pode ser extremamente estressante quando você recebe uma atualização sobre algum componente de terceiros que quebra alguma coisa. Você não tem o código-fonte para depurar ou modificar, mas se o seu sistema depende dele, pode ser bastante assustador. Entrar em uma manhã para descobrir que o servidor de controle de origem está executando inesperadamente e você pode perder duas semanas de check-ins pode fornecer um pouco de estresse. Essa é basicamente a idéia de uma camada de abstração com vazamento, quando você não está preparado para isso. Dê uma olhada nos tickets de bugs abertos em qualquer tecnologia de pilha da Microsoft e os comentários certamente evidenciarão essa variedade de estresse.

Expectativas irrealistas. Eu vejo clientes que esperam que eles possam passar 6 semanas de um período de design de 7 semanas para obter o arquivo que você precisa para começar e me pergunto por que isso não é feito no dia seguinte. Vi pessoas que esperam poder entregar uma nova tarefa às 4h30 da sexta-feira e esperam que você passe o fim de semana inteiro para concluir a apresentação na segunda-feira ao CEO. Vi pessoas que o tiram de uma tarefa de alta prioridade para realizar uma segunda tarefa de alta prioridade e ficam furiosas porque o primeiro não é feito a tempo. Todas essas coisas são estressantes, mesmo quando você se esforça para explicar claramente desde o início por que a expectativa delas é irrealista.

Falta de capacidade de ler mentes. (Vou fazer uma fortuna, já inventei esse módulo de leitura da mente.) É estressante descobrir nos testes dos usuários que o que eles disseram que queriam não era o que realmente queriam.

Muitas dessas respostas são ótimas, especialmente as tensões listadas por Joel e as relacionadas à perda de dinheiro e à administração insistente que não entendem o que estão pedindo.

Alguns dos principais estresses que encontro vêm de

• Inheriting Spaghetti Code

  • Eu tive algumas experiências insanas em que a roda certamente precisava ser reinventada. Imagine ser contratado depois que outro desenvolvedor construiu sozinho uma base de código por mais de um ano, apenas para descobrir que eles não tinham ideia do que estavam fazendo, falham miseravelmente e são demitidos. Ao chegar, você será informado de que seu trabalho é "fazer esse trabalho". É claro que há cerca de uma linha de notas por 4000 linhas de código. Extrema falta de modularidade e pouca ou nenhuma direção. Acima de tudo, tudo está muito além de ter nomes "peculiares" (que são compreensíveis e, às vezes, ótimos) em simples "wth-ness"
  • Você deveria ter dois sub-pontos: P (o código do espaguete é ruim, ok?)

• Há um erro. Você SABE pelo fato absoluto de que deve ser do tipo que envolva uma ou duas pequenas alterações de personagem. O prazo é amanhã, você tem três recursos para concluir. Esse bug leva 5 horas para ser encontrado e você não pode ignorá-lo. ; (Ai lol.

• Tentando explicar o anterior

• Ficar preso em uma mesa devido a restrições de negócios; se você pudesse dar uma hora a pé em um parque e voltar, teria um código de ouro esperando para saltar da ponta dos dedos. Meu pior pessoal, tenho que ver algumas árvores e o céu, se você quiser que eu faça um bom código e progrida rapidamente. Afinal, pelo menos metade da programação é uma arte. Encontre inspiração.

• Não ficar preso em uma mesa quando você precisa ir para casa por causa de restrições comerciais e não pode trabalhar apenas 20 horas hoje enquanto está na zona. Às vezes eu clique com o que estou fazendo e se eu não posso puxar uma noitada bem, então , não é a mesma coisa no dia seguinte .. eu vou lembrar mais do mesmo, mas isso vai demorar três vezes mais tempo para obtê-lo para baixo e não ser tão bom assim mesmo.

• Às vezes, café / outros consumíveis pioram e meu cérebro simplesmente não escuta minha mente como eu quero. =)

• Intervalos de 15 minutos. Apenas o suficiente para me jogar fora, não o suficiente para renovar o cérebro. Boooooo.

• Houve momentos em que eu estava escolhendo uma nova biblioteca ou ... piorando ... uma nova estrutura. Essa foi uma das tarefas mais surpreendentemente estressantes que encontrei. Quando dá certo ou até certo, é adorável. De vez em quando quando fica ruim ... oh garoto. Você pode ficar sentado, tentando fazer testes intermináveis ​​de estilos diferentes e encher a cabeça de tantas interfaces que partes da minha mente simplesmente começam a se desligar e dizer "não, não ... eu não farei isso. Também ruim. Vá embora. " Apenas para ser forçado a vencê-los na submissão. Le suspiro.

• O tipo ruim de erros do vinculador. Não sei como descrevê-los.

• Importando grandes quantidades de dados de um formato de arquivo irritante para seus objetos. Às vezes, isso é muito divertido e muitas vezes o queima muito rápido quando não é. Lembro-me de trabalhar com esse antigo formato excel que tinha um horror de personagem de fuga muito muito complicado e não documentado. Isso ao lado do fato de que as informações na coluna real que estávamos extraindo estavam cheias de personagens descolados, ... ainda me assombra. Fiquei pensando "aha funciona agora !! ....! ............ oh ... deixa pra lá .."

Eu acho que muito do estresse é resultado das seguintes premissas:

1. Bons programadores geralmente são as pessoas que podem realizar alguma tarefa que não seja de programação (suporte à produção / solução de problemas, documentação, responder perguntas da empresa ou de outros membros da equipe, oferecer opiniões técnicas sobre orientações futuras) com mais eficiência.
2. A programação é uma atividade que é melhor executada em longos períodos de tempo ininterrupto.
3. Compreensão da premissa nº 1 >> Compreensão da premissa nº 2.

Como resultado, os programadores costumam fazer várias coisas diferentes, o que diminui a produtividade e a qualidade do trabalho no trabalho escolhido. O gerente que faz essa chamada vê isso como uma "vitória", porque o problema agudo foi resolvido com rapidez e eficiência, e o custo não é imediatamente aparente.

Existem algumas estratégias para gerenciá-lo, com várias vantagens e desvantagens.

1. Gerenciamento de tempo - dedique parte do seu dia à programação e outra parte do seu dia a outros trabalhos, e seja disciplinado. Uma desvantagem disso é que acabei deixando o trabalho de não-programação ocupar todo o meu tempo entre 8 e 5 anos, e fiz o meu trabalho de programação à noite, o que é ruim para o equilíbrio entre vida pessoal e pessoal.
2. Educação - É aqui que pessoas como Joel estão fazendo o trabalho de yeoman - divulgando que o custo de uma interrupção de 15 minutos pode ser muito maior que 15 minutos. (por exemplo, http://www.joelonsoftware.com/articles/fog0000000022.html )
3. Desenvolvimento da equipe, documentação - Garanta que você não seja a única fonte de conhecimento para peças críticas da tecnologia da sua empresa.
4. Personalidade desagradável - estou apenas brincando. Se você desenvolver a reputação de responder com um grunhido a interrupções, as pessoas tenderão a encontrar outras maneiras de fazer algo. É melhor você ser realmente bom em fazer isso, no entanto.

O principal estressor que encontro é o que gosto de chamar de " Síndrome de Mort". Basicamente, é a atitude de alguns desenvolvedores de que a mediocridade é boa, e não há necessidade de melhorar ou fazer as coisas de maneira diferente. Como alguém que passa algum tempo fora do trabalho lendo blogs e livros, ouvindo podcasts e assistindo a vídeos de maneiras melhores de fazer as coisas profissionalmente, acho que isso realmente me estressa, porque 95% das vezes sou a única pessoa na equipe, se não em toda a empresa, que entende por que, por exemplo, escrever testes de unidade é bom ou por que é é ruim ter milhares de linhas de código em uma única classe (ou classes que fazem meia dúzia de coisas diferentes) e tentar educar meus colegas de trabalho resulta em olhares em branco, desculpas de "Não temos tempo para consertar isso "," Nunca usaremos porque nunca o usamos antes. "Ou" Isso 'não é como fazemos as coisas ", ou, na pior das hipóteses, eu sendo mostrada a porta e demitida por tentar mudar as coisas para melhor.

Seria difícil obter uma resposta geral para essa pergunta. As pessoas prosperam sob diferentes condições.

1. muito trabalho em muito pouco tempo
2. muito pouco feedback dos usuários
3. culpar a cultura
4. falta de atmosfera de confiança.

Costumo achar que o trabalho é a menor causa de estresse para a maioria das pessoas, não para os programadores em particular. São os itens estranhos, como cultura da empresa, ambiente da unidade, problemas de comunicação que causam mais estresse para a maioria das pessoas. Não é que eles não possam lidar com o trabalho; é que eles não conseguem lidar com a atmosfera da cozinha, se quiser.

Uma discussão mais útil pode se concentrar mais em soluções para os problemas mencionados.

"Outras tarefas conforme atribuídas".

Eu tive que atender telefones. Eu tive que trabalhar no armazém. Eu tive que fazer inventário. Eu estive em reuniões da empresa durante todo o dia. Eu até tive que sair e fazer manutenção limitada no gramado.

Não sei se algum dia vou aceitar outro emprego que tenha isso como parte da descrição.

Má administração. Não posso contar quantas histórias eu já experimentei ou vi de gerentes (especialmente gerentes seniores e altos executivos da empresa) tomando decisões ultrajantes sem consultar alguém que realmente saiba alguma coisa sobre a área em que decidiram ou que não consultam notas de reuniões anteriores antes de avançar na direção oposta, como foi decidido.