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

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,

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.

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

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.

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

"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.

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.

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?"

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.

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!

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

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.

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.

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

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?

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.

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

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

Emacs

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.

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.

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

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.

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

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.

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.

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.

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.

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

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?

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).