O que pode atrasar um desenvolvedor? [fechadas]

12

Que coisas tendem a atrasar um desenvolvedor?

Tente não publicar respostas que:

são lentos agora, mas úteis no recurso. (TDD, refatoração, ...)
listar uma distração .

productivity organization

— Tom Wijsman
fonte

@ Mark Trapp: Hein ?! Isso não é uma duplicata em tudo ...: S

— Tamara Wijsman

1

Se a pergunta não for útil, eu a removerei em um futuro próximo, as pessoas estão listando distrações que já estão cobertas por outra pergunta minha. Por isso, tenho a tendência de procurar coisas não perturbadoras ... TheLQ e Bill são bons exemplos de respostas.

— Tamara Wijsman

A URL foi mutilada. A duplicata é: Que distrações podem acontecer durante a programação?

Escolhido para deixar a pergunta em aberto, porque trata-se de coisas que não são distrações ...

— Tamara Wijsman

11

Stackoverflow, SuperUser, programadores ... Sim, basicamente sites como este :)

— Bedwyr

49

Oh, este é fácil:

Encontros
Mais Reuniões
Reuniões sobre a última reunião
Reuniões para se preparar para a próxima reunião
Desenvolvendo uma apresentação em power point para uma reunião
Desenvolver uma apresentação em power point para uma reunião discutindo recursos que não foram implementados, não deve ser implementado, e por qualquer motivo esse cara de vendas saltará por toda parte. Não posso prever qual documento você deseja exibir no aplicativo com base na sua localização atual sem uma conexão com a Internet ou acesso ao seu disco rígido. Não, na verdade, desista de pedir também.

— wheaties
fonte

4

em suma: gestão? ; o)

— n1ckp

11

@ n1ck Não, não. Um bom gerenciamento pode acelerar um desenvolvedor. O mau agendamento dos horários de um programador (isto é, um aspecto de ser gerente) pode realmente atrasar o desenvolvimento.

— wheaties 22/10/10

3

o que me mata é quando minha empresa faz isso: Reuniões, Mais reuniões, Reuniões sobre a última reunião, Reunião para preparar, Reunião para discutir por que não conseguimos realizar nada. Por que não conseguimos algo realizado? Você tem quarenta desenvolvedores sentados em uma sala ouvindo você !!

— Mike M.

2

Observe que essa resposta quase caberia em um slide do Powerpoint.

44

Um computador lento

— TheLQ
fonte

Mesmo problema aqui

— pramodc84

1

Eu comprava um laptop o mais rápido possível e trabalhava nisso se estivesse nessa situação, supondo que a empresa o permitisse.

— Adamk

Computadores lentos tendem a ser a causa raiz de uma distração. Sempre que o programador espera, ele pode entrar no modo de distração e não voltará ao programa até algum tempo depois.

— EdA-qa mort-ora-y

Eles substituíram meu computador há algumas semanas. É menos poderoso que o de 4 anos que ele substitui. Agradável.

— MetalMikester 23/11

27

Qualquer coisa que cause mudança de contexto .

— Rydell
fonte

Gosta de digitar no teclado?

25

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

— Ryan Rinaldi
fonte

4

Discordo! O StackOverflow ajuda a resolver problemas, agilizando o desenvolvimento!

— Wizard

3

Bobagem ofensiva. A cada minuto que eu 'desperdicei' no SO, ele me comprou de volta 20.

— MIA

11

+1. não é ofensivo. SO é muito bom para procrastinação. É o meu novo facebook. :)

— back2dos 22/10/10

@ back2dos Por favor, não compare a grandiosidade do SO com o pedaço de .. que é o facebook.

— adamk

17

Eu diria esgotado.

— Maniero
fonte

15

Qualquer tentativa de seguir um processo que não seja adequado à tarefa em questão.

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

metodologias de teste que não se encaixam no código que está sendo testado
processos dramaticamente mais ágeis ou tradicionais do que o (s) produto (s) justificado (s)
diretrizes destinadas 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 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, que geralmente é a morte da produtividade.

— Conta
fonte

13

Política

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

— Chris Buckett
fonte

9

Conversas de outras pessoas

e barulho em geral

Muitas respostas falam sobre alternância de contexto e sair da zona, e o ruído, especialmente a conversa, é uma daquelas coisas que me levam a isso.

No meu mundo de cubos, estou cercado por barulho e conversa por todos os lados. Uma linha acima, a equipe de mainframe realiza reuniões de planejamento constantes na linha do cubo. Às vezes, eles se encontram com consultores em um escritório ao longo da parede, e isso tende a fazer barulho alto, gritar e rir e eu tenho que ir até lá e pedir que eles fechem as portas.

Por outro lado, a mesa de conferência da equipe da web fica do outro lado da parede do cubo oeste, então faço parte de todas as reuniões, gostemos ou não. Há também uma impressora do outro lado da parede do cubo sul, e isso sempre é bom para bate-papo com pessoas que ficam esperando 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 revisões de código, levo minha pilha de papéis para o refeitório (em horários que não são do almoço, é claro), mas há uma TV lá que geralmente é alta. Vou desligar se ninguém estiver assistindo. Caso contrário, vou encontrar um cubo vazio em outro departamento em outra parte do edifício.

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

— Andy Lester
fonte

Às vezes fica muito quieto onde estou. Começo a focar nos cliques do mouse de todos e nas pessoas que respiram pesadamente, etc. É como deitar na cama e ouvir um grilo.

— precisa saber é o seguinte

8

Escrevendo muitas linhas de código sem testes adequados.

— Fortyrunner
fonte

Essa é a causa número um de coisas que pararam na minha experiência.

— Paddyslacker 19/09/10

1

@ Paddyslacker: mais teste = mais produtivo? Hã? Somente para pessoas que não deveriam estar em programação em primeiro lugar. O teste pode ser útil, mas "a causa número um de coisas parando"? Você está falando sério?

— N1ckp 22/10/10

1

@ n1ck: Sim, estou falando sério. O código entra em um estado impossível de manter e a falta de testes e testabilidade da base de código significa que cada novo recurso se torna cada vez mais difícil de adicionar. Acho divertido que você ache que as pessoas que escrevem mais testes "não deveriam estar na programação em primeiro lugar". Então Roy Osherove, Michael Feathers, tio Bob, Kent Beck etc. não deveriam estar na programação então?

— 22410 Paddyslacker

@ Paddyslacker: Eu não sei. Nunca os vi codificar. Talvez eles devam ser melhores em gerenciamento de sua descrição? E por que o código se mantém inalterável devido à falta de teste exatamente? Teste fazer código ruim ótimo por algum tipo de mágica, talvez?

— N1ckp 22/10/10

1

@ n1ck, os testes não valem a pena ao escrever o código inicialmente, mas fazem muita diferença quando é necessário manter o código posteriormente.

5

Falta de café de alta qualidade.

— Robert Harvey
fonte

Ou falta de bom refrigerante. Eu sinto falta de tanta coca-cola de dieta descafeinada! No meu país, eu posso obter apenas coca-cola diet, ou cocaína descafeinada e nem coca-cola :-(

— Wizard

1

@Wizard - Eu costumava trabalhar para uma empresa que fornecia Diet Cherry Coke. Não sei por que saí. Se sentir sua dor.

— JeffO

2

@ Wizard: basta comprar um pote de cerejas marasquino e adicionar um pouco de xarope à sua bebida. Agora você pode torná-lo tão forte como você gosta ... (o mesmo truque para baunilha: verdadeiro coque de baunilha é muito superior ao material pré-misturados)

— Shog9

@Senhor. C: O problema é que eu preciso de dieta + coca-cola descafeinado, uma combinação que não está disponível no meu país.

— Wizard

5

ter que fazer estimativas perfeitas que não devem ser desviadas desde o início do desenvolvimento, é um cenário de ovo de galinha na minha opinião

— MetaGuru
fonte

Se você se deparar com isso muito, sugiro que dedique algum tempo não trivial estudando as estimativas. Então você pode responder "se for uma estimativa, por definição, não é a quantidade de tempo que realmente levará".

— MIA

oh, eu já usei isso antes, a resposta é sempre que sou péssima em estimar, se não puder ser dividida em tarefas visíveis de 2 a 4 horas, então estou fazendo algo errado aparentemente

— MetaGuru

5

Corrigindo a compilação quebrada de outra pessoa

— rwong
fonte

Parece que alguém não está orientando bem seu colega de trabalho.

— Exibir nome

@ negrito: isso pode acontecer naturalmente a partir de assincronicidade. Digamos que o tempo de corte diário da compilação seja 5 da manhã e faça o check-out da versão mais recente às 9 da manhã. (Em outras palavras, você não pode impedir as pessoas de chegar ao trabalho mais cedo.)

— rwong

4

Reuniões sem agenda.

Uma máquina lenta.

Falta de um segundo monitor.

Um rato velho que tem uma bola em vez dos bons novos.

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

— ist_lion
fonte

Relacionado à reunião sem agenda, está o seqüestrador de reuniões. Você sabe ... você o coloca no calendário por uma hora, mas mesmo que o tópico seja encerrado em 20 minutos, esse cara continua a encontrar outros tópicos para preencher os 20 minutos. Eu votaria em você, mas então eu teria que votá-lo na "falta de um segundo monitor" como uma desaceleração. É conveniente, mas não tê-lo de vez em quando não me atrasou.

— MIA

4

Passei muito tempo programando

Mesmo se você realmente gosta de programar, gastar muito tempo com isso acabará queimando você ...

— Nanda
fonte

4

Evite tudo o que você tira da "zona". Isso significa sua caixa de entrada de email, seu aplicativo pop-up do twitter, seu bate-papo corporativo etc.

Ter uma condição de trabalho silenciosa significa também evitar esse ruído na área de trabalho .

— GmonC
fonte

3

Qualquer solicitação de mudança que seria mais fácil de implementar se você soubesse disso antes.

— JeffO
fonte

"Andar na água e desenvolver software a partir de uma especificação são fáceis se ambos estiverem congelados"

— back2dos

1

Citação boba. Andar no gelo nem sempre é fácil.

— Peter Boughton

1

@ Peter Boughton: Se escolhermos uma escala, onde o desenvolvimento de software a partir de especificações flutuantes é difícil e o de congelados é fácil, é fácil caminhar no gelo. Você pode ensinar uma criança de 6 anos a fazer isso. Mas suponho que você saiba disso, apenas se delicia com a avaliação inteligente.

— Back2dos

E você pode ensinar uma criança de seis anos a trabalhar com especificações flutuantes também. Não está sendo esperto, é irritação pelo uso excessivo de citações como essa, que não são úteis. Não é fácil desenvolver especificações congeladas se estiverem erradas (uma vez que não podem ser corrigidas), e alterar as especificações é bom se você souber com antecedência quais partes estão em fluxo (como você pode atender).

— Peter Boughton

3

Código ruim.

Ter que reescrever a parte de outra pessoa que poderia ter feito o trabalho corretamente em primeiro lugar é o maior tempo que eu posso imaginar.

— n1ckp
fonte

2

O que mais atrasa você é um bom post para isso.

...

Muitos projetos repetem os principais recursos no nível da infraestrutura repetidamente, diminuindo a velocidade dos negócios ao fornecer recursos que diferenciam os negócios dos 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 é de que forma esses serviços e ferramentas assumirão.

...

— Tamara Wijsman
fonte

+1: Ótima resposta. Deixei um emprego porque a empresa não estava disposta a dedicar tempo para reduzir a dívida técnica. Os desenvolvedores foram forçados a "repetir os principais recursos no nível da infra-estrutura repetidamente".

— Jim G.

2

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

— HLGEM
fonte

1

Parece que você está falando de gargalos causados por espalhar muito pouco trabalho entre os membros da equipe.

— MIA

1

Não é tanto a equipe se espalhar pouco, mas a gerência não pensou em dependências na atribuição de projetos. E algumas coisas que supostamente estavam prontas no ponto em que as outras pessoas foram designadas para o projeto não eram uma vez que as pessoas tentavam realmente usá-las.

— HLGEM

2

Respondendo perguntas no stackexchange.com, como este.

— tactoth
fonte

Você pode melhorar suas habilidades de digitação por toque.

2

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

Às vezes, um desenvolvedor pode ficar parado porque está fazendo algo que nunca havia feito antes e não sabe onde procurar ajuda. Se for uma equipe ou indivíduo pequeno, pode ser ainda mais difícil. Nós tendemos a ser um pouco orgulhosos e não gostamos de admitir quando não sabemos como fazer as coisas. Além disso, não gostamos de pedir ajuda aos outros. Não há uma maneira fácil de conseguir que um desenvolvedor admita isso, exceto talvez perguntar se eles podem cumprir o prazo, ou o que eles precisam para cumprir o prazo, e depois esperar que sejam honestos. Você pode precisar oferecer outra ajuda ou encontrar alguém que possa ajudá-los.

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

— user6061
fonte

2

Ter que esperar cerca de 15 minutos para o PC inicializar em um estado utilizável
Aguardando o PC alternar entre aplicativos
Sendo a única pessoa no escritório que precisa fazer seu próprio chá / café.
Um teclado quebrado (fixo!)
Trabalhando fora do escritório do diretor administrativo (CEO dos EUA) (e também não em um escritório), com apenas uma partição intermediária (especialmente quando há uma reunião)
O chefe só pode ser acessado por e-mail, mas todo mundo está no prédio
Não poder usar um VCS - aparentemente deveria estar no meu cérebro
Tela pequena
Não permitindo 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
Ser informado para fazer os backups manualmente.
Ser forçado a usar um sistema estúpido de gerenciamento de tempo que é desnecessariamente complicado
Apenas tendo uma vaga idéia dos requisitos após dois meses de trabalho

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

— Alan Pearce
fonte

Parece que você precisa sair de lá!

— adamk

2

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!
Dormir demais?

— soran awla
fonte

1

Muitas pessoas no projeto.

Visto várias vezes em que o gerenciamento decide, com base em dados reais, que eles precisam adicionar mais pessoas ao projeto. Isso acaba nas pessoas que sabem o que está acontecendo, precisando parar tudo para segurar as mãos de pessoas que sabem pouco sobre o que está acontecendo. Eu já vi mais de um projeto crescer em tamanho e depois ir ao banheiro rapidamente de lá, enquanto antes ele estava indo bem, embora talvez um pouco lento.

Então você deixa de estar um mês atrasado por causa da velocidade insuficiente / muito a fazer para não entregar, porque gasta totalmente o orçamento em todas essas pessoas extras.

— MIA
fonte

0

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, esse RTT seria apenas um segundo, mas vi um exemplo de horas. BTW, o teste de unidade tenta lidar com esse problema.

Outro aspecto relacionado é a latência geral do seu ambiente de trabalho. Imagine que você precisaria 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.

— Ilia K.
fonte

0

Papelada em excesso
Ter uma dependência de alguém que nunca está por perto (como seu chefe - se você precisar fazer uma pergunta, mas ele sempre está em reuniões)
Ferramentas e equipamentos inadequados.
Pessoas empurrando o remo sem motivo (qualquer alteração visível na interface do usuário está sujeita a isso) ou apenas discutindo sobre coisas triviais.
Máquina de café quebrada
Sendo atribuído as tarefas erradas

— JohnL
fonte

0

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 diminuem o meu pensamento.

— Mumbles
fonte

0

Essa é uma opinião altamente pessoal e talvez controversa, mas planejar e pensar muito em criar antecipadamente ou escrever código de "qualidade" o tempo todo. Há um ditado que diz que "semanas de codificação podem economizar horas de planejamento", o que pode ser verdade em alguns casos.

No entanto, muitas vezes vejo programadores tentando esboçar um bom design antes de iniciar a codificação. Acho que é mais fácil "continuar", enquanto você programa, você aprenderá mais sobre seu problema e solução, o que permitirá refatorar sua solução rapidamente para um bom design. A maioria dos problemas que surgem é praticamente desconhecida no início da codificação (pelo menos para minha mente fraca), portanto, perder muito tempo projetando antecipadamente é apenas uma perda de tempo.

É também por isso que eu 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.

— Homde
fonte

-1 Eu posso entender o seu pensamento, mas o objetivo do estágio de design é limitar a necessidade de refatorar. Também facilita o teste de unidade, o que é ótimo o tempo todo para garantir que algo que estava funcionando não seja quebrado e liberado. Se você não fizer nenhum planejamento, tornará mais difícil o trabalho de todos quando tiver que tentar manter o que inevitavelmente será um código mal arquitetado.

— adamk

Quem disse que será mal arquitetado? Estou apenas dizendo que você não deseja uma fase de design excessiva e precisa refatorar e re-arquitetar bastante durante um projeto para obter um código de qualidade. Por outro lado, para que isso funcione, é necessário ter responsabilidades de código claramente delineadas, onde pessoas diferentes não estão mexendo no código uma da outra.

— Homde 6/01/11

A experiência diz que terá uma arquitetura ruim. Voar pela calça e codificar cowboys são provavelmente as piores coisas que você pode fazer durante o desenvolvimento. Ter uma fase de design que durará uma semana, poupará meses de programação e levará a um código que faz o que deveria pela primeira vez. A idéia por trás do TDD é que você não mude os testes. Esses testes visam emular a usabilidade no mundo real e, se o seu código não puder concluir o teste, ele estará errado.

— Mike S

Minha experiência diz o contrário, mas acho que depende do vaqueiro e da equipe :) Aprendi mais de uma semana de codificação e fiz um código para mostrar isso. É claro que você terá uma arquitetura ruim se não fizer refatoração extrema e contínua e tiver um time / cowboy que seja ágil o suficiente para acompanhar. Pensando que você pode fazer uma "fase de design", aprender tudo e fazer certo da primeira vez é simplesmente ingênuo. O valor real de um protótipo são as lições que você aprende, o que você joga fora e faz o que é certo. Faça isso várias vezes e rápido :)

— Homde

0

Bloqueio do programador : Diferentemente de outras lentidões, este é mais difícil de resolver.

— Darknight
fonte