Como se tornar um programador "mais rápido"?

142

Minha última avaliação de trabalho incluiu apenas um ponto fraco: pontualidade. Eu já estou ciente de algumas coisas que posso fazer para melhorar isso, mas o que estou procurando é um pouco mais.

Alguém tem dicas ou conselhos sobre o que eles fazem para aumentar a velocidade de sua produção sem sacrificar sua qualidade?

Como você estima cronogramas e se apega a eles? O que você faz para fazer mais em períodos mais curtos?

Qualquer feedback é muito apreciado, obrigado,

Nick Gotch
fonte
96
Gaste menos tempo com SO no trabalho, se você fizer isso.
San Jacinto
52
Se você está lendo isso, já é tarde demais
32
Eu li "Como se tornar um programador mais gordo". Me fez rir
marcgg
13
Eu faria uma pergunta de acompanhamento. O seu desejo de ser um "programador mais rápido" é resultado de seu próprio desempenho ruim (AKA, você precisa aprimorar suas habilidades, precisa se concentrar e eliminar distrações (como SO), etc.), ou é um planejamento ruim de um desenvolvimento ponto de vista (AKA, você recebeu 1 semana para fazer algo que qualquer pessoa sã saberia que levaria 1 mês). Cada item tem soluções muito diferentes.
3
Não há uma única resposta certa possível, portanto, faça dela uma pergunta do wiki da comunidade ou encerre a pergunta.
Donal Fellows

Respostas:

190

Desligar o computador. Pegue um lápis e um pouco de papel. Faça um esboço do seu design. Revise-o com seus colegas. Então escreva o código.

gatorfax
fonte
9
Ou você pode manter seu computador, e abra ou seja, MS Visio
sshow
208
Lápis e papel ou um quadro branco são mais rápidos que a maioria dos aplicativos que já usei.
Thomas Owens
24
Fazer isso no papel concentra a mente.
100
por que não posso diminuir o voto do comentário do visio? Não usar o visio é uma certa maneira de acelerar o desenvolvimento!
52
Ugh .... Visio. Sempre que me pedem para "usar o Visio no seu documento de design", primeiro o rascunho no papel e depois passo os próximos dois dias lutando para corrigir todas as linhas do Visio.
Robert Fraser
149

Algumas ideias...

  • Evite o revestimento de ouro - faça apenas o que for solicitado (em termos de requisitos)
  • Entenda os requisitos de negócios e faça certo da primeira vez
  • Entenda completamente seu ambiente e ferramentas
  • Torne-se um datilógrafo fantástico, use atalhos de teclado em vez do mouse
  • Adote uma abordagem iterativa e faça verificações de sanidade para garantir que você está no caminho certo
  • Não reinvente a roda, considere reutilizar o trabalho passado e o trabalho de outras pessoas
  • Elimine distrações, não continue verificando e-mails, olhando para fora, conversando com colegas de trabalho etc.
  • Não trabalhe demais - reconheça quando você precisa fazer pausas
maio
fonte
7
+1 por não reinventar a roda. Aprenda a produzir código reutilizável, que pode ser conectado a outro código e trabalhar com nenhum, para reescrever pequeno. (ex .: funções com parâmetros, em vez de codificar)
34
+1 para "evitar chapeamento de ouro" - essa foi a causa de eu perder muitos prazos devido às minhas tendências perfeccionistas / retentivas a anal.
Dinah
7
Digitação - ponto importante. Sempre espantado com o número de codificadores eu encontro que não aprenderam a escrever ...
Paddy
2
+1 eliminando distrações. A meu ver, eles são os principais comedores de tempo.
2
+1 nas dicas para melhorar micro (em vez de macro melhorias em termos de planejamento de projetos).
132

Seu desejo de ser um programador "mais rápido" por si só é louvável. No entanto, o não cumprimento do prazo não significa que você é lento, significa que o projeto foi mal planejado. Ser um programador "mais rápido" não ajudará; significa apenas que você adiará o prazo mais rapidamente.

Você (e sua equipe) estão cometendo um dos seguintes erros (ou todos eles):

  • subestimar o trabalho que precisa ser feito;
  • falta de um grande requisito ou peça de arquitetura durante o planejamento;
  • confundir estimativas de trabalho com estimativas de calendário e não contabilizar coisas como reuniões / telefone / outras despesas gerais;

Existem várias maneiras de abordar qualquer uma das três acima. Mas antes de poder melhorar qualquer um deles, você precisa saber por que as coisas estão indo do jeito que estão. Faça um post - mortem nas estimativas dos últimos dois ou três projetos versus o tempo real gasto e descubra para onde foi o tempo extra.

Vou repetir novamente - ser lento na redação do código não causará a perda do prazo , se você o planejou adequadamente para explicar esse fato.

Franci Penov
fonte
47
Alguns desenvolvedores são realmente muito lentos. Isso pode ser um problema.
12
Sim, isso pode ser um problema, mas é um problema pessoal. Nunca deve se tornar um projeto ou um problema de equipe. Em outras palavras, pode afetar a carreira de alguém, mas nunca deve afetar o cronograma do projeto.
Franci Penov
12
'não entregar no prazo não significa que você é lento, significa que o projeto foi mal planejado' - essa é uma descrição da caixa de texto de um argumento inválido. existem muitas outras razões pelas quais você pode não entregar a tempo, uma das quais pode ser porque você é lento.
carne
15
@ carne - se você sabe que é lento, por que não planejaria sua agenda para explicar esse fato? Em outras palavras, se você sabe que não pode correr tão rápido quanto Usain Bolt, planejaria correr 100m em 9,7s?
Franci Penov
5
@Kibbee - nesta situação, você corta recursos. você não pode prometer fazer certo trabalho em um determinado momento, quando sabe que não pode ser feito e esperar um milagre.
Franci Penov
89

Realmente, realmente aprenda seu editor. Se você usa um IDE, verifique se está usando todos os recursos que ele oferece. Obtenha uma folha de dicas para aprender os atalhos do teclado para o seu editor de sua escolha. Se você estiver usando um shell, configure atalhos para diretórios comumente usados

slashnick
fonte
3
Isso pode, de facto, por vezes, aumentar a produtividade drasticamente
sshow
6
Escrever código real é apenas parte do trabalho de um desenvolvedor. Passar um tempo para aprender o IDE com perfeição é uma otimização de pontos; e você sabe o que eles dizem sobre otimizações, não é? - "Meça primeiro e depois otimize os gargalos".
Franci Penov
1
Eu não vejo isso. Se eu perder 50% do meu tempo de digitação, quanto tempo isso vai me salvar em um dia? Na minha experiência, estou gastando a maior parte do tempo pensando em código / teste / avaliação / modificação leve / etc, em comparação com realmente escrevê-lo, acho que isso acabaria não sendo uma grande vitória.
4
Isso torna a navegação no IDE algo que você faz sem pensar. Qualquer coisa que exija algum esforço consciente, como passar para o pequeno botão cinza marcado com algo ou outro próximo a todos os outros pequenos botões cinza, atrasa você interrompendo seu pensamento. Ter ctrl-n na ponta dos dedos sem movimento é uma grande vitória líquida.
Paul McMillan
5
Na mesma linha: aprenda as teclas de atalho gerais. Por exemplo, em muitos programas do Windows ... Copiar: Ctrl + c Cortar: Ctrl + x (o 'x' parece um par de tesouras abertas) Colar: Ctrl + v (ao lado de 'c' e 'x' acima) Ir para o início da linha: Início Ir para Fim da linha: Fim Mover o cursor por palavra (não caractere): [Shift] + Ctrl + esquerda ou direita Ir para o início do documento: Ctrl + Início Ir para o final do documento: Ctrl + Fim etc #
38

"Alguém tem dicas ou conselhos sobre o que eles fazem para aumentar a velocidade de sua produção sem sacrificar sua qualidade?"

Muitas pessoas se esforçam para obter a qualidade "final" às custas de algo que é (a) simples, (b) confiável e (c) correto.

A maneira mais importante de acelerar seu desenvolvimento é simplificar o que você está fazendo, para que seja absolutamente o mais simples possível.

A maioria das pessoas que têm problemas com a entrega no prazo está entregando demais, demais. E as razões apresentadas são frequentemente tolas. Geralmente, são apenas requisitos percebidos, não requisitos reais.

Já ouvi muitas pessoas me dizerem o que o cliente "espera". Esta é uma política ruim.

Crie a coisa mais simples possível. Se o cliente exigir mais, construa mais. Mas construa a coisa mais simples possível primeiro.

S.Lott
fonte
"Muitas, muitas pessoas lutam pela qualidade" final "à custa de algo que é (a) simples, (b) confiável e (c) correto." Você poderia ter deixado assim e eu teria votado a favor.
Corymathews 11/09/09
"Simplifique, simplifique." ~ Henry David Thoreau
2
Sim ... isso significa abstração prematura também. Se algo tiver apenas uma implementação, não faça dela uma interface.
23420 Robert Fraser
3
Uma das minhas frases favoritas é apropriada nesta situação "fazer algo tão simples quanto possível, mas não mais simples" ~ paráfrase, Albert Einstein
Nemi
Simplifique é o que muitos programadores não conseguem corretamente: eles caem facilmente na armadilha da "otimização prematura é a raiz de todo mal". Normalmente, o programa mais simples é o mais rápido ou o da mais alta qualidade.
32

Evite polir seu código com perfeição, apenas faça-o funcionar. É isso que a empresa espera.

Mas, muitas vezes, aumentar a velocidade implica sacrificar a qualidade.

user8685
fonte
10
Eu sugeriria "fazê-lo funcionar" e, se o tempo permitir, aperfeiçoá-lo!
Preets 11/09/09
28
-1: Não há razão para sacrificar a qualidade. Você sempre pode sacrificar recursos.
S.Lott
6
Eu já vi isso acontecer repetidamente. Os desenvolvedores se desligam dos últimos 1% de um determinado recurso e, em seguida, tentam recuperar o atraso e ficam para trás ao tentar concluir os recursos restantes. Complete o que se espera de você primeiro, depois volte e faça o polimento.
3
Muitas vezes, aumentar a qualidade implica aumentar a velocidade. Se você demorar um pouco para acertar em primeiro lugar, poderá economizar mais tempo em testes e depuração.
David Thornley
2
Se você estiver preso em um recurso, trabalhe em algo diferente.
29

Reutilização - tento fatorar quaisquer bits inteligentes de projetos anteriores, para poder usá-los novamente em empreendimentos futuros. Sempre vale a pena se perguntar "eu poderia usar isso de novo algum dia?"

Phil Jenkins
fonte
Estado mental perfeito para programação mais rápida a longo prazo, embora a princípio possa levar mais tempo.
8
+1: Cuidado, porém, eu me peguei generalizando e abstraindo algo para poder usá-lo novamente outro dia ... e perdi o prazo daquele dia ou dobrou o tempo que o bug deveria ter levado para corrigir ... para que eu pudesse "talvez" economize tempo mais tarde.
Steven Evers
2
Ter um "saco de truques" é fundamental. Se isso estiver se tornando um problema de trabalho para você, vale a pena dedicar um pouco do seu tempo a desenvolver peças reutilizáveis ​​(supondo que o domínio em que você trabalha seja passível de reutilização de código).
24

Mantenha simples.

Se você usa TDD, deve seguir " vermelho, verde, refatorar ":

  1. Escreva um teste com falha ( vermelho ). (Geralmente, para funcionalidade, seu código ainda não possui.)
  2. Cometa crimes horríveis de codificação para que seus testes sejam aprovados ( verde ). Codifique, se necessário.
  3. Refatorar , provavelmente interrompendo os testes por um curto período de tempo, mas, em geral, melhorando o design.
bryanbcook
fonte
3
Ao fazer o TDD, você tem um corredor de teste que produz um relatório vermelho / verde por teste para indicar se eles são aprovados.
2
@ Konstantin: Escrever algum código usando TDD pode levar 20% mais tempo, mas também gera código melhor e, a longo prazo, quando o sistema cresce, a velocidade de fazer alterações permanece a mesma. O TDD ajuda você a evitar dívidas técnicas que o tornam mais lento.
3
Digitar nunca foi a parte mais lenta da programação. Mesmo que você precise digitar mais com o TDD, isso não o torna mais lento. Pode até acelerar você, porque escrever um teste primeiro ajuda você a se concentrar no que é necessário antes de pensar em como implementá-lo.
1
Se a gerência não entender algum conceito-chave, explique-o. Por exemplo, martinfowler.com/bliki/TechnicalDebt.html
3
@ Konstantin, se você considera "desenvolvimento" o ato de escrever a declaração de código, eu concordo com você. No entanto, se você considerar "desenvolvimento" incluir empacotamento, preparar anotações de compilação, implantar, testar, produzir relatórios de defeitos, revisar e priorizar defeitos, atribuição de tarefas, investigação, depuração e correção e iniciar o processo novamente - os 15 minutos seguintes para escrever o teste de unidade supera os dias e a perda de confiança do cliente 1000x acima.
22

Faça o download de toda a documentação de seus idiomas / bibliotecas localmente para o seu computador e desconecte o cabo da rede / desligue o Wi-Fi .

Não tentando ser engraçado aqui. Isso realmente me ajuda!

mcjabberz
fonte
Eu faço o mesmo.
A documentação online e as pesquisas de solução de problemas são superestimadas de qualquer maneira.
Instale um firewall e configurá-lo para bloquear quase todo o acesso web (eu tenho exceções para alguns domínios, por exemplo MSDN)
finnw
Estou realmente pensando em fazer isso (o fato de eu deixar este comentário provas o suficiente)
Ikke
E perder SO? hell no
20

Observe quando você está lendo Stack Overflow por muito tempo. A desculpa "Compilando" funciona apenas por tanto tempo. :)

Matthew Jones
fonte
15
Depende da velocidade do seu compilador. Então talvez a "solução" seja encontrar um compilador mais lento e executá-lo no Pentium 2 com 128 MB de memória? :-)
Franci Penov
@Franci, talvez até colocando espaço de troca em um disquete. Ou dois em RAID.
20

Evite alternar tarefas com muita frequência. Distrações e alternância de tarefas podem matar um dia, mesmo se você usar ferramentas como Mylyn para gerenciar suas tarefas.

Descobrir uma granularidade (por exemplo, 30 minutos) e trabalhar apenas em itens relacionados à tarefa em questão. Qualquer outra coisa (novos relatórios de bugs, e-mails sobre outros problemas, questões processuais não relacionadas) é adiada pelo menos até o "próximo ponto de verificação". Desative a exibição de notificações por e-mail para não ser sugado.

É especialmente eficaz se você tiver um amigo em sua equipe que informará se as coisas realmente derretem e exigem sua atenção imediata.

Uri
fonte
Isso não funcionará se você tiver um chefe que espera respostas a e-mails dentro de 10 minutos.
#
Isso é realmente muito relevante. Tanto quanto for razoavelmente possível, não se permita ser vítima de capturadores egoístas de atenção e cumpra sua tarefa original. Se você se deixar levar por direções diferentes, o resultado final é que você não consegue nada em vez de algo.
AndyUK
14

Faça certo, da melhor maneira, pela primeira vez. Se isso significa que você precisa parar e pensar um pouco antes de começar, faça-o. Funciona 90% do tempo.

ck01
fonte
2
+1 Isso é verdade. Isso não significa que você precisa ser "perfeito"; todos nós cometemos erros. Mas se fizermos as coisas da melhor maneira possível na primeira vez, a conseqüência desses erros será muito menor.
+1 - Lembro-me de ler em algum lugar que a diferença entre bons programadores e maus programadores não está na velocidade. A diferença é que bons programadores manterão mais seu código.
Jason Baker
Esse é o meu lema, faça da maneira certa, da primeira vez. Não adquira o hábito de sempre voltar e corrigir seu código, porque você não fez isso corretamente de acordo com as especificações.
"Se você não tem tempo para fazer o que é certo, como vai ter tempo para fazer isso de novo?"
Alex Feinman
Você pode precisar de experiências com o software real para poder determinar qual é a melhor maneira. Nesse caso, você não pode acertar na primeira vez.
14

Aprenda a digitar o mais rápido possível .

AJ Johnson
fonte
2
Este é um bônus interessante ... mas acho que não terá muito impacto no geral. Digitar código é provavelmente a parte que consome menos tempo. (. Sim, eu segui e ler o link que eu simplesmente não concordar com ele.)
Se o fator limitante da sua codificação é a rapidez com que você digita as coisas, provavelmente está trabalhando no nível errado de abstração.
Pete Kirkham
+1. Um ótimo link, um ótimo artigo para quem o leu até o final;) ​​Eu estava digitando bem, mas me inspirou a mudar para o layout do teclado do programador Dvorak en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard (mas mudei o '"e -_ chaves com Microsoft Keyboard layout Creator), e eu tenho certeza que em breve eu vou estar escrevendo muito mais rápido :) Veja também: typematrix.com/dvorak
Roman Boiko
12

Eu faço isso amanhã .

Fazer as coisas também é imensamente útil.

Eu tenho um curto período de atenção de qualquer maneira, então esses livros me ajudam a manter meu foco ... o que eu estava fazendo de novo?

Matthew Jones
fonte
12

Prática e trabalho duro.

Você precisa dedicar tempo e esforço. À medida que se torna mais confortável e confiante com as ferramentas que seu uso, velocidade e criatividade devem seguir.

Se você deseja aprimorar alguma habilidade específica, também pode ajudar a elaborar exercícios que permitirão que você trabalhe especificamente nisso. Se sua lentidão estiver na fase de design, tente encontrar problemas de design para trabalhar on-line. Refazer o mesmo exercício permitirá concluir mais rápido e praticar velocidade. Pessoalmente, gosto dos exercícios de algoritmo da TopCoder para praticar a pura velocidade de programação. Eles também têm desafios de design, mas eu não os tentei.

DeslocadoAussie
fonte
A prática é frequentemente subestimada na programação. Essa deveria ter sido uma das 5 principais respostas.
Uau. Não tenho certeza por que não é mais alto também. Eu realmente nunca tentei isso. Vou tentar!
David
11

Aprenda sobre o The Zone, aprenda a se envolver e aprenda a reconhecer quando não estiver nele.

Quando estou "na zona", sou extremamente produtivo e o código flui para fora de mim; geralmente, consigo codificar 2 ou 3 dias em 1 dia. Mas acho que muitas vezes é difícil chegar a esse lugar, me vejo procrastinando, sendo distraído por outras coisas (Stack Overflow, por exemplo).

Cite os truques que você usa para se colocar na zona

Dustin Getz
fonte
E pule o almoço se você estiver na zona ... ou fique até tarde ... MMMmm a zona. drool
10

Conhecendo bem o seu IDE e estrutura. Ter que recorrer ao Google para cada pequena coisa leva tempo.

Mike Hall
fonte
Mas também é importante perceber quando você precisa do Google e poder fazê-lo rapidamente.
9

Emacs

ZeroCool
fonte
1
Por favor, edite isso para que eu possa votar novamente, atualmente é "muito antigo".
22410 kmarsh
1
Fortemente dependente do que você precisa para usá-lo.
8

Antes de começar a desenvolver:

  • Sair da sua caixa de correio
  • Desative qualquer cliente de MI
  • Educadamente, peça aos colegas para lhe dar tempo para se concentrar
  • Claro, pare de navegar na Internet

Toda vez que você é interrompido, diminui a velocidade, pois leva tempo para a mente voltar aos trilhos com seus pensamentos. Ouvi números de que para cada interrupção, a mente humana leva de 5 a 10 minutos para voltar ao processo de pensamento que possuía antes da interrupção. Com tanto tempo por interrupção, não leva muito tempo a perder o dia inteiro.

As pessoas de nossa empresa realmente tentaram bloquear o tempo em seus calendários e depois se mudaram para uma sala de conferências vazia por algumas horas por dia.

lavável
fonte
7

Aprenda o seu IDE de desenvolvimento dentro e fora. Aprenda as teclas de atalho. Aprenda a usar menos o mouse. Acho que isso economiza muito tempo para mim.

D3vtr0n
fonte
7

Você é mais lento que seus colegas ou suas estimativas são mais otimistas?

pjc50
fonte
7

Para produzir software mais rapidamente, descobri que a melhor coisa a fazer é aprender a API da sua execução o melhor possível. Não digite a lógica da lista quando uma extensão LINQ funcionar; não crie muitos ouvintes de eventos quando a ligação funcionar, etc.

No que diz respeito à estimativa, isso vem com a experiência. Você pode usar o software de estimativa existente para ajudá-lo a descobrir melhores estimativas.

Pessoalmente, eu encontrei com os desenvolvedores de nível júnior, pegue qualquer estimativa inicial e multiplique por 2, depois duplique. Isso será responsável por todo o aprendizado, reuniões, perda de tempo etc. Os desenvolvedores de nível mais alto tendem a trabalhar com um fator de 2 em relação às suas estimativas.

Muitas vezes, a questão não é se sua estimativa estava errada. Sua estimativa foi responsável por todas as coisas certas? Você está dando suas estimativas e cronogramas em termos de esforço de codificação ou em termos de tempo do calendário? Pense o tempo todo no seu dia e quanto disso é real, codificação produtiva x reuniões, aprendizado, depuração etc.

James Schek
fonte
3
"... multiplique por 2 e depois dobre." Desde que você está interessado em poupar tempo, eu tenho uma dica matemática para você que você pode ser capaz de usar ...
LOL - Eu sei o que você está dizendo. Mas você ficará surpreso com isso muitas vezes passa despercebido, em vez de dizer "multiplique por 4".
7

Duas coisas que podem estar implícitas, mas ainda não vi as respostas aqui que aumentam a produtividade:

  • Use algum tipo de script de construção e implantação. Compilar, implantar, reiniciar o servidor de aplicativos e essas coisas não sugam tempo ou foco, deve ser um tipo de coisa com apenas um clique.

  • Tenha algum tipo de controle de versão. Ter que codificar sem poder reverter uma alteração é como tentar andar sobre os ovos

Buhb
fonte
7

Algumas idéias vêm à mente:

  1. Obtenha outras opiniões sobre suas estimativas - Existem outros desenvolvedores que você pode perguntar algo como "Ei, você acha que pode conseguir esse tipo de recurso nesse período?" A ideia é que a opinião de outras pessoas pode ajudar com precisão em alguns casos, pois alguém pode observar um monte de coisas que você perdeu ao fazer a estimativa.

  2. Aprimore sua habilidade de estimativa - comece a rastrear o quanto você está fora das estimativas e por que você está fora: outros itens de trabalho estão fazendo com que os prazos não sejam cumpridos? Você está constantemente subestimando o quanto algo é complicado? Você está dando uma linha do tempo inteira quando isso não é prático; por exemplo, o que é solicitado é vago o suficiente para que apenas a criação de um protótipo leve semanas e, em seguida, deve haver uma reavaliação do que mais deve ser feito? Fazer isso pode ajudar ao máximo a desenvolver essa habilidade, de modo que, se você disser que algo levará x horas, você pode confiar nisso porque fez isso várias vezes. Uma maneira alternativa de afirmar isso é apenas prática, prática, prática.

É verdade que você provavelmente já considerou isso, mas achei que valeria a pena declarar isso para os outros por aí que podem não ter considerado essas idéias.

JB King
fonte
7
  1. Conheça a tecnologia por dentro e por fora.
  2. Pare! Pensar! Ir!
  3. Arquiteto para o que quer que possa surgir, mas implemente apenas o que realmente é pedido.
  4. BEIJO - mantenha-o simples estúpido
  5. Se estiver ficando muito complexo, provavelmente não será bem pensado. (Volte para 2 e 4)
  6. Não fique preso no 5. Vale a pena começar do zero (volte para 2 e 4)
  7. Volte para 1.
Rui Craveiro
fonte
7

Eu acho que a palavra-chave aqui é "pontualidade". Eles não disseram que você era muito lento, mas que não era oportuno.

No gerenciamento de projetos, é importante que o gerente seja capaz de estimar quando seus itens de trabalho serão concluídos com precisão. Suspeito que a principal razão pela qual seus esforços não foram considerados oportunos é que você frequentemente tinha itens que não foram entregues dentro do prazo e foram entregues muito mais tarde do que o planejado.

Para melhorar sua pontualidade, convém dedicar mais tempo para entender quanto tempo levará para concluir um item de trabalho específico, considerando suas habilidades, experiência e domínio. Isso permitirá que você dê melhores estimativas ao seu gerente de projeto. A chave aqui é "melhor" ... você pode entregar a tempo com mais frequência preenchendo tudo com um fator de falsificação, mas o que você realmente deseja buscar é uma estimativa mais precisa.

Eu discutiria isso com seu gerente para ver se esse é realmente o problema. Caso contrário, você pode acabar programando duas vezes mais rápido, prometendo coisas na metade do tempo que costumava e ainda sendo criticado por sua pontualidade, porque suas estimativas ainda terão o mesmo fator de erro.

Larry Watanabe
fonte
"... Gaste mais tempo compreendendo quanto tempo levará para concluir um item de trabalho específico, considerando suas habilidades, experiência e domínio." -> Certo, e isso também irá ajudá-lo a cortar o escopo e economizar ainda mais tempo.
Jim G.
Isso também ajudará seu gerente a ficar bem com as pessoas ao seu redor - também permite que materiais de suporte, como marketing, sejam concluídos em sincronia com seu projeto.
Tom leys 29/09/09
7

Fique estável, fique estável.

Crie algo que implemente um pouco da funcionalidade e verifique se ela funciona de ponta a ponta. Em seguida, mantenha-o funcionando enquanto adiciona novos bits de funcionalidade. Sim, isso é parcialmente uma prática de TDD, mas faz sentido mesmo que você não faça TDD.

A lógica é que toda vez que vejo alguém com 2 semanas de código que nunca foi estável, sempre leva mais duas semanas para ficar estável.

Se você permanecer estável, elimina essa incerteza e também oferece a si próprio uma maneira de reduzir o alcance próximo ao prazo, se necessário.

O contra-argumento óbvio é que isso levará mais tempo do que apenas escrevê-lo uma vez, pois você fará um trabalho extra para estabilizar o código não final. Eu não compro isso por um segundo. Quando você tem um código que funciona , você altera 5 linhas e algo quebra, você sabe exatamente onde a interrupção deve ter acontecido.

Se você possui 10.000 linhas de código que nunca funcionaram e precisa encontrar uma pausa, você tem uma tonelada de código para pesquisar.

Pequenas mudanças incrementais em um sistema que é consistentemente estável FTW. Vá devagar para ir rápido.

kyoryu
fonte
7

Para mim, obter boa produtividade é ter uma ideia clara sobre o que você está tentando alcançar e como vai chegar lá.

mdma
fonte
1
Minha viagem de bicicleta de 30 minutos para trabalhar no interior da Noruega também é muito boa para limpar a mente e dar andamento aos processos criativos.
6

Praticamente todas as respostas foram ditas até a morte em vários lugares aqui e em outros lugares. Ou, pelo menos, eu ouvi isso até a morte. Aprenda seu IDE, aprenda a digitar mais rápido, use estruturas, use geração de código etc. etc. Sim, é claro que essas coisas ajudarão e duvido que existam muitos programadores que são mestres em todas elas. Mas, sendo o tipo de programador que faz essas perguntas e frequenta sites como o Stack Overflow, você já sabia disso . Você apenas queria repeti-los aqui ou apenas desabafar um pouco?

Mas e se pudéssemos chegar a esse estado? Quero dizer, dominar todas essas sugestões? O que aconteceria então? Bem. Eu acho que os prazos serão reduzidos ainda mais. E, novamente, voltaremos a uma percepção de qualidade. Quero dizer, nosso ofício definitivamente progrediu e se tornou cada vez mais produtivo ao longo das décadas. Mas a qualidade aumentou durante esse período (excluindo os primeiros anos, é claro)?

Minha resposta é simples: software de qualidade leva tempo ! Você pode trocar apenas um pelo outro (qualidade / velocidade). Mas sim, todos nós sabemos que, no entanto, não somos honestos sobre o grau em que esse trade-off geralmente termina na velocidade final da escala. E somos mentirosos ainda maiores desde o início dos projetos!

Eu digo que você não tem culpa aqui. O problema é a percepção que as pessoas têm de quanto tempo o software de qualidade deve levar. Enganamo-nos ao acreditar que somos capazes de criar software de qualidade com os tipos de prazos que nossos gerentes ou até estimamos. Não fabricamos software de qualidade . Escrevemos software que funciona, mas às vezes com lampejos de qualidade em certos cantos de um aplicativo.

Então, o que nós podemos fazer sobre isso? Não podemos simplesmente convencer nossos chefes de que precisamos dobrar ou triplicar o investimento em cada um de nossos projetos. Eu digo liderar pelo exemplo. Crie um software realmente excelente como um projeto paralelo. Coloque seu próprio tempo nisso e não se comprometa. Preste atenção o tempo todo ao progresso. Anote as tarefas aparentemente não relacionadas em que você teve que gastar um tempo inesperado e veja se pode justificá-lo. Compare isso com todos os outros projetos em que você trabalhou. Seja brutalmente honestoconsigo mesmo e com todos os aspectos desta análise. As coisas extras que você fez com seu software de qualidade podem ser negligenciadas em projetos "reais" no trabalho? Mas talvez sua tentativa tenha falhado. Qual foi a razão? Você ficou entediado e se apressou para concluir os principais recursos? Eu ainda tenho que fazer algo assim, e é por isso que encerro esse pensamento com algumas dúvidas - mas pretendo tentar de verdade. Vou mantê-lo informado :).

Finalmente, acho que a maioria (se não todas) as avaliações de desempenho são distorcidas e extraordinariamente manipuladoras. Você não pode diminuir a qualidade e a velocidade em 100%. Seu chefe deve pontuar você contra um padrão definido pela organização. O padrão da organização no compromisso entre qualidade e velocidade. Vamos imaginar que a OrangeSoft Inc. espera 33% de qualidade e 66% de velocidade. Portanto, se você estiver escrevendo um código que tenha talvez um terço dos testes de unidade, deve fazê-lo com velocidade e tempo de entrega reduzido, você deve pontuar perto de 100% em sua análise! (Essas são analogias bastante grosseiras, mas você entendeu). Mas, em vez disso, o que acontece é que Bob escreve código extremamente rápido, mas que é notoriamente incorreto. Portanto, em sua avaliação de desempenho, ele pontua 3/5 em qualidade e 5/5 em velocidade. Carol, por outro lado, escreve código muito mais devagar, mas produz significativamente menos erros. Ela pontua 5/5 em qualidade, mas 3/5 em velocidade. De qualquer maneira, Bob e Carol ficam atracados no aumento. É possível para qualquer funcionário obter uma pontuação perfeita? Isso é justo?

Thiru
fonte
5

A técnica que eu uso é a prototipagem evolutiva

Você pode pesquisar no Google para obter mais informações - mas se a necessidade é produzir algo rapidamente, é o único caminho a percorrer. Além disso, tem o benefício de que, quando os usuários disserem que ele gosta, você estará pronto (... e poderá começar a fazer a documentação).

slashmais
fonte