ti-enxame.com

O que pode atrasar um desenvolvedor?

O que tende a atrasar um desenvolvedor?

Tente evitar postar respostas que:

12
Tamara Wijsman

Oh, esses fáceis:

  1. Encontros
  2. Mais reuniões
  3. Reuniões sobre a última reunião
  4. Reuniões para se preparar para a próxima reunião
  5. Desenvolvendo uma apresentação em power point para uma reunião
  6. Desenvolvendo uma apresentação em power point para uma reunião discutindo recursos que não foram implementados, não deveriam ser implementados e, por qualquer motivo, aquele cara de vendas vai pular. Não consigo prever qual documento você deseja exibir no aplicativo com base em sua localização atual, sem uma conexão com a Internet ou acesso ao seu disco rígido. Não, só desista de pedir também.
49
wheaties
44
TheLQ

Qualquer coisa que cause mudança de contexto .

27
Rydell

StackOverflow, programmers.stackexchange.com, etc. :)

25
Ryan Rinaldi

Eu diria esgotamento.

17
Maniero

Qualquer tentativa de seguir um processo que não é adequado para a tarefa em questão.

Isso pode ser todo tipo de coisa, mas as comuns que vejo incluem:

  • metodologias de teste que não se enquadram no código que está sendo testado
  • processos que são dramaticamente mais ágeis ou tradicionais do que o (s) produto (s) garantido (s)
  • diretrizes que se destinam a um conjunto de ferramentas diferente do conjunto de ferramentas selecionado
  • princípios de design que estão fora de escala com as necessidades do projeto
  • usando um conjunto de ferramentas que não é adequado para a tarefa

Todas essas coisas podem valer imensamente a pena em alguns projetos ou em algumas situações, mas algumas organizações tentam fazer tudo de uma maneira e isso leva a um ajuste inadequado em outros projetos, o que geralmente é a morte da produtividade.

15
Bill

Política

por exemplo: Quando mais de uma pessoa possui os requisitos (ou pior, dois interesses investidos diferentes) e eles fazem mudanças concorrentes e conflitantes nos requisitos enquanto o desenvolvimento está em andamento.

13
Chris Buckett

Conversas de outros

e ruído em geral

Muitas respostas falam sobre mudança de contexto e como sair da zona, e ruído, especialmente conversa, é uma daquelas coisas que me leva a isso.

No meu cubeworld, estou cercado por barulho e conversas por todos os lados. Uma linha depois, a equipe de mainframe mantém reuniões de planejamento constantes na linha do cubo. Às vezes, eles se encontram com os consultores em um escritório ao longo da parede, e isso tende a levar a gritos, berros e risos altos e eu tenho que ir até eles e pedir que fechem as portas.

Por outro lado, a mesa de conferência da equipe da web está do outro lado da minha parede do cubo oeste, então eu participo de todas as reuniões, goste ou não. Há também uma impressora do outro lado da parede do cubo sul, e isso é sempre bom para bate-papo de pessoas esperando por suas impressões.

A resposta imediata e óbvia de " Você não pode simplesmente obter fones de ouvido com cancelamento de ruído" não ajuda quando o que você quer é silêncio.

Às vezes, para revisar o código, levo minha pilha de papéis para o refeitório (fora do horário de almoço, é claro), mas há uma TV lá que geralmente está tocando. Vou desligar se ninguém estiver olhando. Caso contrário, irei encontrar um cubo vazio em outro departamento em outra parte do prédio.

Se você deseja que seus programadores façam o trabalho de que precisam, que é predominantemente pensar, ponderar e considerar, eles precisam de um ambiente onde possam fazê-lo.

9
Andy Lester

Escrever muitas linhas de código sem testes adequados.

8
Fortyrunner

tendo que fazer estimativas perfeitas que não devem ser alteradas uma vez que o desenvolvimento começa, é um cenário de ovo de galinha na minha opinião

5
MetaGuru

Falta de café de alta qualidade.

5
Robert Harvey

Consertando a construção quebrada de outra pessoa

5
rwong

Evite tudo que o tira da "zona". Isso significa sua caixa de entrada de e-mail, seu aplicativo pop-up do Twitter, seu bate-papo corporativo, etc.

Ter um condição de trabalho silenciosa significa evitar o ruído da área de trabalho também.

4
GmonC

Reuniões sem agenda.

Uma máquina lenta.

Falta de um segundo monitor.

Um rato antigo que tem uma bola em vez dos Bonitos novos.

Falta de acesso à Internet na máquina, tornando a consulta do MSDN/stackoverflow/etc um pouco dolorosa.

4
ist_lion

Gastou muito tempo programando

Mesmo se você realmente gosta de programação, gastar muito tempo nisso acabará por esgotá-lo ...

4
nanda

Código ruim.

Ter que reescrever a parte de outra pessoa que poderia ter feito o trabalho direito é a maior perda de tempo que posso imaginar.

3
n1ckp

Qualquer solicitação de mudança que teria sido mais fácil de implementar se você soubesse de antemão.

3
JeffO

Responder a perguntas em stackexchange.com, como esta.

2
tactoth

Mesmo que você tenha pedido para não listar as distrações, elas podem ser um grande fator. Observe o ambiente de trabalho deles, verifique se eles estão sendo interrompidos com frequência ou solicitados a fazer outras coisas não relacionadas ao projeto.

Às vezes, um desenvolvedor pode travar porque está fazendo algo que nunca fez antes e não sabe onde procurar ajuda. Se for uma equipe pequena ou individual, pode ser ainda mais difícil. Tendemos a ser um tanto orgulhosos e não gostamos de admitir quando não sabemos fazer as coisas. Além disso, não gostamos de pedir ajuda aos outros. Não há uma maneira fácil de fazer um desenvolvedor admitir isso, exceto talvez perguntando se ele pode cumprir o prazo ou o que precisa para cumpri-lo e, então, esperar que seja honesto. Você pode precisar se oferecer para trazer outra ajuda ou encontrar alguém que possa ajudá-los.

Falta de requisitos claramente definidos, o que os leva a ter que descobrir coisas ou tomar decisões.

2
user6061

O que te deixa lento é um bom post para isso.

...

Muitos projetos repetem os recursos básicos de nível de infraestrutura indefinidamente, tornando os negócios mais lentos na entrega de recursos que os diferenciam de seus concorrentes.

...

É inevitável que produtos e inovações ajudem a reduzir o tempo que os desenvolvedores gastam em tarefas não diferenciadoras. A questão é que forma esses serviços e ferramentas irão assumir.

...

2
Tamara Wijsman
  • Falta de documentação (Sistema, Empresa, etc.)
  • Falta de código comentado
  • Uma compreensão incompleta do sistema
  • Política (ou seja, reuniões desnecessárias, papelada, obstáculos da administração ...)
  • Documentação de requisitos incompleta
  • Facebook!
  • Muito sono?
2
soran awla

Bem, ultimamente a maior desaceleração é porque estamos desenvolvendo várias coisas simultaneamente que deveriam ter sido feitas em uma ordem específica. Então, estou esperando até que (nomes mudados para proteger os inocentes) John termine seu componente que eu preciso para meu pacote SSIS e Harry fique lento esperando que eu importe registros porque ele precisa de alguns dados para ver para testar sua exportação (sempre tente escrever um relatório de exportação complexo quando não há dados em nenhuma das tabelas?) e todo mundo fica lento porque o design não foi feito e as tabelas de banco de dados que precisamos para fazer nossas tarefas ainda não foram criadas e podem nem mesmo terminar sendo o que eles disseram que seriam, etc.

2
HLGEM
  • Ter que esperar cerca de 15 minutos para o PC inicializar em um estado utilizável
  • Esperando que o PC troque os aplicativos
  • Ser a única pessoa no escritório que tem que fazer seu próprio chá/café.
  • Um teclado quebrado (consertado!)
  • Trabalhar fora do escritório do Diretor Executivo (CEO dos EUA) (e não em um escritório, também), com apenas uma divisão entre eles (especialmente quando há uma reunião)
  • O chefe só pode ser acessado por e-mail, mas todos os outros estão no prédio
  • Não ter permissão para usar um VCS - aparentemente, deveria estar no meu cérebro
  • Tela pequena
  • Não dando tempo para intervalos além do almoço
  • Ter que fazer backups de servidor remoto, apesar de ter um administrador de sistema no prédio
  • Sendo instruído a fazer os backups manualmente.
  • Ser forçado a usar um sistema de gerenciamento de tempo estúpido que é desnecessariamente complicado
  • Apenas tendo uma vaga ideia dos requisitos após dois meses de trabalho

Eu poderia continuar, mas é sexta-feira e quero esquecer o trabalho.

2
Alan Pearce

Muitas pessoas no projeto.

Já vi várias vezes em que a gerência decide, com base em nenhum dado real, que precisa adicionar mais pessoas ao projeto. Isso acaba nas pessoas que sabem o que está acontecendo precisando parar tudo para segurar nas mãos de pessoas que sabem pouco sobre o que está acontecendo. Já vi mais de um projeto de cogumelo em tamanho e depois ir ao banheiro rapidamente a partir daí, enquanto antes estava indo bem, embora talvez um pouco lento.

Então você vai de estar um mês atrasado por causa da velocidade insuficiente/muito o que fazer para não entregar porque você estourou totalmente o orçamento de todas aquelas pessoas extras.

1
MIA

Além das coisas mencionadas por outros, o longo caminho entre decidir compilar e executar seu código e obter um resultado positivo/negativo . Idealmente, este RTT seria apenas um segundo, mas eu vi um exemplo de horas. BTW, o teste de unidade tenta lidar com esse problema.

Outro relacionado é uma latência geral de seu ambiente de trabalho. Imagine que você precise trabalhar em uma conexão de área de trabalho remota com o computador do outro lado do mundo, em uma conexão assustadora. Eu estive lá. Eu odiei isso.

0
Ilia K.
  • Excesso de papelada

  • Ter uma dependência de alguém que nunca está por perto (como seu chefe - se você precisar fazer uma pergunta, mas ele está sempre em reuniões)

  • Ferramentas e equipamentos inadequados.

  • Pessoas empurrando seus remos sem motivo (qualquer mudança visível na IU está sujeita a isso) ou apenas discutindo sobre coisas triviais.

  • Cafeteira quebrada

  • Recebendo as tarefas erradas

0
JohnL

O ar condicionado não funciona.

Portanto, a temperatura no escritório chega a 40 graus no verão de -5 no inverno.

O -5 não é bom para digitar, pois não posso usar luvas e digitar. Os 40, apenas retarda meu pensamento.

0
Mumbles

Esta é uma opinião altamente pessoal e talvez controversa, mas planejando e pensando muito sobre o design antecipado ou escrever código de "qualidade" o tempo todo. Há um ditado que diz que "semanas de codificação podem economizar horas de planejamento" que pode ser verdade em alguns casos.

No entanto, freqüentemente vejo programadores tentando esboçar um bom design antes de começar a codificar. Eu acho que é mais fácil apenas "começar", à medida que você programa, você aprenderá mais sobre seu problema e solução, o que permitirá que você refatore sua solução rapidamente em um bom design. A maioria dos problemas que surgem são praticamente desconhecidos no início da codificação (pelo menos para minha mente débil), então perder muito tempo projetando com antecedência é apenas uma perda de tempo.

É também por isso que não gosto de TDD, você perde muito tempo escrevendo testes, o que torna menos provável a refatoração ou leva muito tempo para reescrever os testes. Os testes de unidade são ótimos para alguns casos e algumas etapas de um projeto, mas o início de um não é um deles IMHO :)

Faça algo funcionar rapidamente e melhore-o.

0
Homde

Bloco do programador: Ao contrário de outros abrandamentos, este é mais difícil de resolver.

0
Darknight