Superando a resolução lenta de problemas devido ao conhecimento crescente do que pode dar errado [fechado]

Isso está me incomodando há algum tempo, e eu realmente aprecio a contribuição de outros profissionais.

Breve histórico: comecei a programar quando meus pais me compraram meu primeiro computador em 1988 (aos 14 anos, agora tenho 39 anos). Eu segui algumas outras carreiras antes de finalmente me tornar um programador profissional em 1997. Talvez seja tarde demais, mas foi assim. Ainda estou feliz com minha escolha, adoro programar e me considero bom no que faço.

Ultimamente, tenho notado que quanto mais experiência ganho, mais tempo leva para concluir projetos ou determinadas tarefas em um projeto. Ainda não vou senil. É que eu já vi tantas maneiras diferentes pelas quais as coisas podem dar errado. E as armadilhas e truques potenciais que eu conheço e lembro estão ficando cada vez mais.

Exemplo trivial: costumava ser apenas "ok, escreva um arquivo aqui". Agora estou preocupado com permissões, bloqueio, simultaneidade, operações atômicas, indirection / frameworks, diferentes sistemas de arquivos, número de arquivos em um diretório, nomes de arquivos temporários previsíveis, qualidade da aleatoriedade no meu PRNG, falta de energia no meio de qualquer operação, uma API compreensível para o que estou fazendo, documentação adequada, etc etc etc.

Em suma, os problemas já passaram de "como faço isso" para "qual é a melhor / mais segura maneira de fazer isso".

O resultado é que levo mais tempo para concluir um projeto do que um iniciante. Minha versão pode ser sólida e tão impenetrável quanto sei como fazê-la, mas leva mais tempo.

O exemplo "create file" acima foi apenas isso, um exemplo. Tarefas reais são obviamente mais complexas, mas menos adequadas para uma pergunta genérica como esta. Espero que você entenda para onde estou indo com isso. Não tenho problemas em criar algoritmos eficientes, adoro matemática, gosto de assuntos complexos, não tenho dificuldades com a concentração. Acho que tenho um problema com a experiência e, consequentemente, com medo de erros (intrínsecos ou extrínsecos).

Passo quase duas horas por dia lendo sobre novos desenvolvimentos, novas técnicas, idiomas, plataformas, vulnerabilidades de segurança e assim por diante. O enigma é que, quanto mais conhecimento eu ganho, mais lento sou na conclusão de projetos.

Como você lida com isso?

Você não é mais lento na conclusão de projetos. Anteriormente, você pensava que seus projetos iniciantes eram realizados quando realmente não eram. Você deve vender essa qualidade aos clientes.

"Esta empresa pode fazê-lo mais rápido e mais barato, mas é realmente feito? Ou você estará caçando insetos por anos?"

Além disso, você precisa conhecer e aceitar o antigo idioma: "O perfeito é o inimigo do bem".

Parece que é hora de você se juntar ao lado sombrio: gestão.

Não estou sugerindo que você desista da programação e se torne um gerente. Mas parece que toda a experiência que você citou até agora foi de natureza técnica. Na simples operação de escrever um arquivo, você pode pensar em 10 aspectos diferentes que um desenvolvedor menos maduro nunca consideraria. Não necessariamente uma coisa ruim, mas ...

O lado sombrio tem tudo a ver com valor presente. Trata-se de fazer um investimento mínimo para obter o máximo ganho (análise de custo-benefício). Nos negócios, tudo se resume a quanto isso me custará: probabilidade de sucesso, probabilidade de falha, probabilidade de falha espetacular e ganho potencial. Faça as contas; aja de acordo.

Isso funciona tão bem quando você é desenvolvedor: crie um arquivo temporário, ignorando permissões e colisões de nomes - 5 min. Com ganho líquido, o restante da equipe pode começar a trabalhar em qualquer código que dependa da presença desse arquivo. É uma solução perfeita? Absolutamente não. Será que você recebe 99%, 95%, talvez 90%? Sim, provavelmente será.

Outra pergunta a ser feita: como você se sente em relação à dívida técnica? Algumas pessoas pensam que deve ser eliminado. Eu acho que essas pessoas estão erradas. Assim como nos negócios, a dívida técnica permite que você peça emprestado "dinheiro" ou "tempo" para entregar algo mais cedo. O que é melhor: uma solução perfeita em 2 anos ou um hack completo que um cliente pode usar e comprar em 4 meses? Cada situação é diferente, mas em algumas situações, se você esperar 2 anos, seu cliente já se inscreverá na concorrência.

A chave é gerenciar a dívida técnica da mesma maneira que uma empresa bem administrada gerencia a dívida financeira. Se você não assumir o suficiente, não estará obtendo um ótimo retorno do investimento. Se você assumir demais, o interesse o matará.

Portanto, meu conselho: comece a avaliar seu trabalho com base em se você está maximizando seu valor em vez de maximizar sua minúcia. E se você praticar isso, desenvolverá a mesma intuição que já desenvolveu em sua área técnica.

Como observação, comecei recentemente a técnica pomodoro e ajudou muito. Em vez de seguir uma tangente de uma tangente, concentre-se em pequenos intervalos de tempo e aloque pomodoros para trabalhos / pesquisas futuras. É incrível quantas vezes fiz uma anotação para pesquisar um tópico, mas uma hora depois, quando chegou a hora, pensei: "há pelo menos três outras coisas que eu poderia fazer com o meu tempo hoje e que são todas mais valiosas".

Eu tive o (provavelmente) mesmo problema há muitos anos, durou alguns anos e eu o superei. Talvez seja de seu interesse saber como eu consegui isso, mesmo que não tenha certeza de que meu caminho também se aplique a você.

Você também deve dar uma olhada aqui: As sete etapas da especialização em engenharia de software Isso mostra que a produtividade é em grande parte um efeito colateral do nível de habilidade. Pode ser que você ainda esteja em algum momento entre os estágios 3 e 4 da tecnologia que está usando atualmente (a proficiência em habilidades depende da tecnologia, você pode dominar algumas tecnologias enquanto ainda aprende outras).

Agora começo com o testemunho biográfico.

Um pouco de contexto. Tenho 47 anos. Comecei a programar aos 12 nos anos 80. Enquanto estava no ensino médio, também trabalhei como programador profissional de meio período. Basicamente, não me deu tanto dinheiro, apenas o suficiente para comprar hardware, mas eu gostei e aprendi muito. Aos 18 anos, iniciei um aprendizado formal de Ciência da Computação.

Como resultado, quando completei 20 anos, sempre que iniciei uma tarefa de programação, conheci muitas maneiras de resolver os problemas apresentados e estava muito consciente dos muitos parâmetros e armadilhas existentes, além das desvantagens e limites de qualquer método.

Em alguns momentos (digamos, cerca de 26 anos), tornou-se realmente difícil para mim escrever qualquer programa. Havia tantas possibilidades abertas que eu não pude mais escolher entre elas. Por alguns anos (faça 6), parei de programar e me tornei redator técnico de notícias.

Eu nunca parei totalmente de tentar programar, no entanto. E em algum momento voltou. A chave para mim foi a programação extrema, mais especificamente o princípio da simplicidade: "escreva a coisa mais simples que possa funcionar".

Basicamente, me forcei a não me importar com a eficiência do código (esse era o meu principal obstáculo, evitava designs ineficientes), mas seguia o caminho mais fácil. Também me forcei a me importar menos com os erros e atrasar o tratamento dos erros para mais tarde, depois de escrever testes que aumentavam o erro (na verdade, isso é TDD).

Isso é algo que aprendi quando estava escrevendo. Quando não sei o que escrever, ou soube que o que estava escrevendo era ruim . Apenas continue. Na verdade, escreva as coisas ruins. Acabarei corrigindo isso mais tarde. Ou se é realmente tão ruim apagá-lo e reescrevê-lo, mas é mais rápido escrever coisas duas vezes que escrevem algo perfeito da primeira vez.

Realmente, é muito provável que um código que você considere bom na primeira gravação precise de tantas melhorias quanto de um código realmente ruim.

Se você seguir o caminho da Simplicidade, também receberá um bônus adicional. Você aceita facilmente remover / alterar o design / codificação inicial. Você tem uma mente mais flexível.

Também adquiri o hábito de colocar um comentário temporário no código, explicando o que não estava fazendo agora e pretendia fazer mais tarde, quando o código fosse funcional no caso de uso normal.

Também participei de um XP Dojo e pratiquei katas de código com outros programadores para internalizar as práticas do XP. Ajudou. Tornou os métodos formais acima instintivos. A programação em pares também ajudou. Trabalhar com jovens programadores dá um impulso, mas com a experiência, você também vê o que eles não vêem. Por exemplo, no meu caso, muitas vezes os vejo se engajar em projetos excessivamente complicados e conheço o pesadelo que pode levar a isso. Foi assim. Fiz isso. Teve problemas.

O ponto primordial para mim é manter o fluxo. Ser rápido é realmente bem-sucedido em manter o fluxo.

Agora estou de volta como programador profissional e acredito que sou melhor e mais rápido com uma compreensão mais profunda do que estou fazendo. Praticando TDD Eu ainda posso ser um pouco mais lento do que quando eu era um touro jovem (e não testou nada), mas também não tenho medo de refatorar e certamente gasto muito menos tempo depurando (quase sem tempo, diminuindo 10% do tempo) )

Resumindo: superei meu código de bloqueio usando métodos ágeis (XP), buscando simplicidade, refatoração e praticando para tornar isso instintivo. Funcionou para mim. Não tenho certeza se pode ser generalizado para mais ninguém.

Em termos de nível de aquisição de habilidades, aprendi principalmente a aceitar que toda vez que mudar de tecnologia (aprender novo idioma, nova estrutura etc.), passarei por um estágio em que estou desacelerando. Isso é normal e acabará superando isso. Eu também posso compensar isso com boa metodologia e habilidades de programação de uso geral, e isso não será um problema.

Uma parte importante da programação é gerenciar e controlar a complexidade e, para mim, pessoalmente, é um dos principais problemas. Se ignorado, a frequência de deficiências aumenta ou, como no seu caso, a ETA do software final aumenta dramaticamente.

A complexidade do software pode ser controlada e gerenciada de vários níveis e maneiras diferentes, mas uma boa regra geral para se ter uma perspectiva é a seguinte: "A principal prioridade de qualquer projeto de software é a satisfação do cliente, em função de suas expectativas".

Em outras palavras, a complexidade do software depende muito de sua habilidade em controlar as expectativas do seu cliente.

Quando alguém adota essa visão, dois pontos importantes se tornam óbvios:

1. as expectativas do cliente devem ser explicitadas (sob qualquer forma);
2. as expectativas do cliente sempre podem ser modificadas e isso é feito através da arte da negociação.

Seu exemplo é muito bom: "simplesmente escreva" vs "inúmeras outras considerações". Pense nisso - se alguém escrever requisitos exaustivos para ambas as variantes, pode haver uma equivalência nos recursos descritos ou não?

Construir um F16 é diferente de construir um Cessna, embora ambos possam voar.

A resposta simples é: aceite.

Em todos os sistemas, há compromissos a serem feitos entre confiabilidade, robustez, segurança, velocidade, custo de hardware, custo de desenvolvimento, tempo de colocação no mercado, etc. Você nem sempre concorda com a forma como o cliente faz essas trocas, mas não é você quem toma essas decisões. Tudo o que você pode fazer é fornecer uma opinião ponderada. O desenvolvimento de software abrange toda a gama, de "minha página pessoal" a "executar o reator nuclear", e o código deve ser escrito de acordo. Se um acidente significa "recarregar minha página pessoal", quem realmente se importa se isso acontecer? Mas se uma falha significa "Chernobyl", sua preferência por código sólido é algo casual para o meu gosto.

Existem alguns clientes que aceitam com satisfação o código de nível "Prova de conceito" e o executam em seus sistemas ativos, e geralmente possuem administradores de sistema que estão bem acostumados a isso. No IME, seus sistemas geralmente ficam indisponíveis por uma hora ou mais no meio da noite, enquanto várias reinicializações agendadas acontecem. Mas eles tomaram a decisão comercial de que é assim que eles querem rolar. Idealmente, porque seu campo é tão rápido que o código de alta qualidade nunca estaria pronto, mas muitas vezes porque eles não conseguem ver o valor (se um sistema "simplesmente funciona", eles nunca o percebem, portanto esse sistema não representa valor para dinheiro). Se isso lhe incomoda muito, tente evitar esses clientes.

Manter-se atualizado é o tempo que todos temos que gastar, ou pelo menos devemos gastar. Às vezes, isso faz com que você trabalhe; outras, apenas mantém sua mente em boa forma. De qualquer maneira, tente se divertir.

Parece que suas habilidades seriam muito úteis para o desenvolvimento de sistemas de missão crítica de alta qualidade, como aplicativos relacionados a finanças / comércio, transmissão, aeroespacial, defesa ...

Os erros nesse tipo de aplicativo são muito caros e empregam pessoas que pensam como você, pois você pode cobrir todos os casos.

A verdade é que os sistemas modernos estão se tornando cada vez mais complexos. O computador agora é semelhante ao jogo "Jenga", no qual você tem todas essas peças confiando em muitas outras. Retire a peça errada e você tem um erro, retire uma peça correta / necessária e você ainda pode produzir um erro. Quanto mais complexo o sistema, mais tempo você passará pensando em maneiras de tornar seu código mais robusto e, com sorte, mais seguro também. A velocidade seria boa, mas acho que a velocidade fica muito atrás hoje em dia quando você ouve nas notícias que a empresa "XYZ" foi invadida e 6 milhões de números de cartão de crédito de clientes foram roubados.

Seus clientes podem não querer ouvir que o programa deles precisa ser seguro, robusto, etc. Mas você pode dizer a eles que o carro deles não precisa de cintos de segurança e airbags, nem a casa deles precisa de trancas e portas ... porque quem quer ouvir tudo este?

Se você está pensando demais, está pensando sobre as coisas da maneira certa, exceto que precisa escolher uma estratégia que pareça "concreta" e seguir em frente.

Parece que você está ciente de sua tendência a pensar em tudo que pode dar errado.

Os desenvolvedores cautelosos experientes geralmente aprendem a seguir o mantra YAGNI, e não é necessário, quando tentam retornar a um fluxo de trabalho enxuto, ágil e produtivo depois de ficarem muito empolgados com as ervas daninhas da análise de modo de falha que ficou doida.

No entanto, se você estiver realmente escrevendo algo em um domínio em que esse nível de atendimento não seja menor do que o profissionalismo exige, você deve perceber que sua "velocidade", sua "produtividade", em termos líquidos, são mensuráveis ​​por quanto de bom ( ou dano) que você está fazendo com sua empresa, seus clientes e o conjunto de softwares ou a família de produtos que você está construindo ou mantendo.

Lembrar de:

• Inclua o custo total de manutenção, o custo total de propriedade e o custo total de implantação e manutenção de soluções quando considerar mudanças em sua abordagem. Ir mais rápido e cometer mais erros pode ou não melhorar as coisas.

• Se você trabalha em uma boa empresa, provavelmente pode discutir isso em sua própria equipe e com seu próprio supervisor, sem que isso seja um movimento de limitação de carreira. Se não puder, agora é uma boa hora para descobrir isso e encontrar um novo emprego.

A única coisa que posso ver é: "Você está se tornando cada vez mais valioso".

À medida que você obtém mais experiência, aprende sobre coisas que deve evitar, e é isso que o torna melhor do que os outros.

Uma coisa que você deve ter notado é que seu código seria mais seguro e sustentável agora.

• A única coisa que você precisa fazer é explicar ao seu cliente por que demorou e como seria útil para eles.
• Você precisa mostrar a eles a profundidade do seu conhecimento.
• Você precisa dizer a eles por que fez, o que fez e como isso importaria para eles e para os negócios deles.

Minha sugestão seria me concentrar nessa parte.

quando em dúvida, o padrão é mal citar Knuth ...

"Otimização prematura é a raiz de todo o mal."

Aqui está o que eu sugeriria, pois parece que você tem um problema que eu tenho de tempos em tempos ...

O que realmente funciona para mim ...

1. Escreva os testes de unidade, como se todo o código estivesse pronto.
   
2. documentar a interface.
   
3. implementar a interface.

o que você realmente fez:

1. trabalhe com os requisitos das camadas do modelo
2. realmente configurar a divisão do trabalho, quais objetos são responsáveis ​​por quais
3. comece a trabalhar em um ambiente em que você possa realmente percorrer o código de trabalho, o que torna as coisas muito mais rápidas e precisas ...

também confie em afirmações no desenvolvimento inicial ... depois descubra quais remédios precisam ser implementados e você não escreverá código inacessível ou difícil de testar.

Eu acho que você deve seguir os seus padrões de codificação, mas certifique-se de estar na frente dos seus clientes. Muitos clientes não sabem o que é preciso / custa para criar um bom software. Faz parte do trabalho do desenvolvedor profissional educá-los.

Seja você ágil ou em cascata, você obtém algum tipo de acordo do cliente sobre o que ele espera que o aplicativo faça. Muitos desenvolvedores (OK, talvez mais vendedores) são culpados de ensacamento . "Eles não disseram que queriam um site altamente seguro". Na maioria dos casos, é porque eles não foram convidados. "Você se importa se o seu site de comércio eletrônico for invadido?" É claro que eles se importam e por que você o construiu para permitir que alguém penetre na segurança? Você tem que educá-los.

Apenas verifique se você está fazendo apenas o que o cliente está pagando para você fazer. Parte do seu serviço é a sua experiência. Os clientes esperam que você conheça as armadilhas sem que eles precisem perguntar. Cabe a eles incluir o requisito. Você pode passar para clientes que desejam algo barato.

Pense nas consequências práticas de um bug em comparação com todos os outros problemas que precisam ser resolvidos.

Considere as seguintes conseqüências da criação de um trecho de código mal escrito:

1. Todo o banco de dados é despejado a cada dois meses. 48 horas de inatividade enquanto os backups são restaurados.
2. Os registros do cliente são interligados. $ 200 em pedidos são enviados para os clientes errados por mês.
3. Um pedido fica preso no status errado uma vez por semana. Os navios de ordem, mas os armazéns, precisam ligar para o suporte técnico sempre que isso acontecer.
4. Depois de duas semanas, o aplicativo falha e o usuário precisa digitar novamente 2 minutos em dados.
5. Uma vez por mês, o aplicativo trava na inicialização. O usuário tem que interromper o processo e começar de novo.

O primeiro é obviamente inaceitável. # 2 - # 5 pode ou não ser, dependendo da natureza do negócio. # 2 - # 5 precisam ser avaliados no contexto de outros problemas que a empresa está enfrentando.

Idealmente, os números 2 a 5 nunca aconteceriam. Na vida real, com prioridades conflitantes, as pessoas que assinam seu salário podem querer que você trabalhe em outras coisas, em vez de escrever um código perfeito que nunca tenha um problema. Eles não ficarão impressionados se o 5 for corrigido às custas de não corrigir um bug mais sério em outro programa.

A solução é criar uma coleção de bibliotecas com funções comumente usadas que você pode reutilizar nos projetos. Por exemplo, eu tenho uma biblioteca .NET StringFunctions.dll que faz coisas como codificação, criptografia, descriptografia, avaliação de expressões regulares, etc. Dessa forma, não preciso reescrever continuamente coisas que não mudam.

Ter um wrapper para tarefas de criação de arquivo também faz muito sentido. Sua biblioteca pode expor um método chamado GetFile () que faz todas as verificações para você e retorna um arquivo nulo ou um arquivo (ou o que você julgar útil).

Eu acho que você precisa aprender a decidir quanto precisa ser feito para qual projeto. Alguns projetos podem ser triviais e você realmente não precisa gastar todo esse tempo aperfeiçoando-o. Nem tudo vai precisar de criptografia sólida, nem tudo será dimensionado para milhões de usuários.

Escrever um programa que pode ser dimensionado bem para mais de um milhão de usuários levará tempo e experiência que você tem agora, mas se você souber que seu aplicativo não será usado por mais de 1000 usuários no máximo, não há sentido em gastar todo naquele tempo aperfeiçoando.

Eu acho que essa é uma etapa importante em sua carreira em programação e agora você precisa ir para o próximo nível, que tem a ver com maturidade e não com programação. Você precisa decidir corretamente quanto tempo e código devem ser suficientes para qualquer projeto em particular.

E, como tudo o mais, você pode conseguir isso também com a prática. Portanto, tente decidir isso antes de iniciar um projeto, mesmo quando já estiver trabalhando nele, com a experiência que você passará além disso. Pode haver alguns acertos e erros no início, mas com o tempo você o aperfeiçoará (tomada de decisão, não código).

@Zilk, eu não sou um ótimo programador e estou programando desde 1998. Até agora estou enfrentando esse problema. Mas o que eu percebi é que, em última análise, a qualidade importa. Se eu morrer hoje, alguém deve ser capaz de captar o que estou fazendo agora de onde parti. Esses devem ser os padrões de programação (Universal).

Mudei-me de desenvolvedor para arquiteto agora. Mudar para Gerenciamento está mudando de linha. Se você quiser continuar com sua paixão, pode mudar para se tornar arquiteto.

Inicialmente como Arquiteto Técnico -> Arquiteto de Soluções -> Arquiteto Corporativo -> Arquiteto Chefe e assim por diante.

Como arquiteto, você guiará as pessoas para o sucesso. Pessoas como você que programam há décadas esses anos de experiência que você pode utilizar para guiar outras pessoas.

Como um pássaro mais alto, voa mais terra que pode ver, assim é a sua experiência.

Deixe-me também dizer que programar a implementação correta é importante do que programar uma implementação incorreta mais rapidamente. Recentemente, um dos meus juniores programou algo errado e custou muito dinheiro a um banco. É claro que tínhamos entregado a tempo mais cedo, mas não adiantou! Foi-me dado o papel de guia, mesmo que o mesmo júnior tenha codificado que o problema não teria acontecido. Estou dando este exemplo para enfatizar que dar uma boa orientação também é importante. Alguns chamam esse trabalho de consultoria.

Outra opção é: pare de escrever código, em vez disso, venda sua experiência em detectar os problemas com antecedência.

Em outras palavras, torne-se um consultor .

Muitas organizações ficam felizes em pagar dólares caros (se não os mais altos) para que alguém descubra os problemas antes de passar meses criando o código que os causa. É sabido que a correção de um bug no design é uma ordem de magnitude mais barata / fácil do que corrigi-lo depois de codificado, testado e implantado.

Você não escreverá tanto código e provavelmente perderá isso, mas parece que as linhas de código reais não são a sua força principal, mas o conhecimento de quais linhas de código devem ser escritas - e quais não.

Concentre-se em seus pontos fortes.
(bem, se é isso que você gosta ...)

Minha melhor recomendação para você é: blocos de construção.

Crie um bloco de construção de arquivos em que você possa confiar sempre, faça um para sua API, pare de desperdiçar seu tempo escrevendo a mesma coisa repetidamente. Pense em cada problema uma vez e corrija-o de uma vez por todas.

Ninguém vai entender isso, certamente não é o novato que gasta 80% do seu tempo depurando códigos que falham nos casos de canto que eles não entendem.

Acima de tudo, não corrija problemas que não podem acontecer, como permissões erradas.

Se as permissões estiverem erradas, algo já está errado e você deve corrigi-lo, em vez de tornar seu programa à prova de balas.

Em algum momento, você deve simplesmente não dar um tiro no próprio pé, em vez de sempre verificar se o fez ou não.

Em vez de gastar tempo com documentação, dedique um tempo para que seu código se autodocumente e seja o mais curto possível. Substitua todas essas funções duplicadas. Reduza sua biblioteca, renomeie as coisas com precisão.

Não seja muito duro consigo mesmo. Você está trabalhando em uma profissão de complexidade crescente, que requer mais inteligência, conhecimento e experiência humana do que nunca.

O poder de processamento do computador está diminuindo - talvez em breve pare -, levando à necessidade de introduzir chips de vários núcleos, números alimentados por gpu, paralelismo etc. Existem apenas muitos transistores que podem ser colocados em um chip.

Portanto, os grandes avanços atuais e futuros virão dos programadores - algoritmos avançados e código mais eficiente.

Se você olhar para GTA 4 e GTA 5, as diferenças são surpreendentes. Mas ambos rodam no mesmo hardware. Este é o resultado de alguma prática de programação muito inteligente e avançada que simplesmente não era necessária ou disponível há 10 anos.

Isso também pode significar que programadores experientes podem se tornar mais valiosos no futuro - assim como outras profissões, como engenharia, onde os ganhos de pico geralmente ocorrem no final da carreira.

Assim como você, comecei a programar aos 14 anos, também quando obtive meu primeiro computador (embora eu estivesse estudando há alguns meses naquele momento). No entanto, tenho "apenas" 33 anos agora. :-)

Minha sugestão é que, ao desenvolver algo, você tome cada uma dessas preocupações (permissões de arquivo, número de arquivos em um diretório etc.) e use toda a sua vasta experiência para responder a algumas perguntas sobre o assunto, neste espírito:

• Quanto tempo levaria para lidar com esse problema corretamente no seu código?
• Se você não lidar com isso adequadamente, qual é a probabilidade de que essa coisa o morda mais tarde?
• Se isso te morder, quais são as consequências?

Armado com essas respostas, um cara tão experiente não terá problemas para tomar uma decisão sábia. ;-)

É responsabilidade de "veteranos" como você criar esse tipo de requisito, e isso envolve identificar o que pode dar errado e decidir a quais problemas potenciais você deve prestar atenção.

Conhecer todos os critérios possíveis ao desenvolver o aplicativo é a coisa mais importante no desenvolvimento de um produto de qualidade. Você está indo bem nisso. Uma coisa que você pode fazer é: você pode categorizar o requisito em nível de qualidade e mapear o nível com o prazo determinado. Desta forma, você pode cumprir o prazo do projeto com facilidade.

Nas palavras de Edsger Dijsktra: “Se a depuração é o processo de remoção de bugs de software, a programação deve ser o processo de incluí-los.” ​​Você está apenas fazendo menos do último e, portanto, menos do que o anterior. É apenas uma questão de aprender a gastar tempo codificando corretamente. Eu ainda sou um programador relativamente jovem (leia 20 anos) e aspiro poder codificar algo completamente certo uma vez. Uma hora de planejamento e 10 minutos de codificação é muito melhor do que 10 minutos de planejamento, uma hora de codificação e três de depuração.