Isso tem me incomodado há algum tempo e eu realmente aprecio a opinião de outros profissionais.
Antecedentes: 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. Mais tarde, talvez, mas foi assim. Ainda estou feliz com a minha escolha, adoro programar e me considero bom no que faço.
Ultimamente, tenho notado que quanto mais experiência ganho, mais tempo demora para concluir projetos ou determinadas tarefas em um projeto. Eu não estou senil ainda. É só que eu já vi tantas maneiras diferentes em que as coisas podem dar errado. E as potenciais armadilhas e pegadinhas que eu conheço e lembro estão ficando cada vez mais.
Exemplo trivial: costumava ser apenas "ok, escreva um arquivo aqui". Agora eu estou preocupado com permissões, bloqueio, concorrência, operações atômicas, indirection / frameworks, sistemas de arquivos diferentes, número de arquivos em um diretório, nomes de arquivos temporários previsíveis, a qualidade da aleatoriedade no meu PRNG, escassez de energia no meio de qualquer operação, uma API compreensível para o que estou fazendo, documentação apropriada, etc etc etc.
Em suma, os problemas mudaram há muito tempo de "como faço isso" para "qual é a melhor maneira de fazê-lo".
O resultado é que demoro mais para terminar um projeto do que um novato. Minha versão pode ser sólida e tão impenetrável quanto eu sei como fazer, mas demora mais.
O exemplo "criar arquivo" acima foi apenas isso, um exemplo. As tarefas reais são obviamente mais complexas, mas menos adequadas para uma questão genérica como essa. Espero que você entenda onde estou indo com isso. Não tenho nenhum problema em criar algoritmos eficientes, adoro matemática, gosto de assuntos complexos, não tenho dificuldades com 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 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 eu sou na conclusão de projetos.
Como você lida com isso?
Você não é mais lento na conclusão de projetos. Anteriormente, você achava que seus projetos iniciantes estavam prontos quando eles realmente não estavam. Você deve vender essa qualidade para os clientes.
"Esta empresa pode fazê-lo de forma mais rápida e barata, mas é mesmo feito? Ou você vai estar caçando insetos há 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: gerenciamento.
Não estou sugerindo que você desista de programar 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 negro é todo sobre valor presente. Trata-se de fazer um investimento mínimo para ganho máximo (análise 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; agir em conformidade.
Isso funciona tão bem quando você é um desenvolvedor: criar um arquivo temporário, ignorando permissões e colisões de nomes - 5 min. Ganho líquido, o resto da equipe pode começar a trabalhar em qualquer código depende da presença desse arquivo. É uma solução perfeita? Absolutamente não. Você conseguirá 99%, 95%, talvez 90%? Sim, provavelmente será.
Outra pergunta a fazer: Como você se sente em relação à dívida técnica? Algumas pessoas acham que isso 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 dois anos, seu cliente já estará inscrito na concorrência.
A chave é gerenciar a dívida técnica da mesma forma que um negócio bem administrado gerencia a dívida financeira. Se você não assumir o suficiente, não estará obtendo um ótimo retorno do investimento. Se você assumir muito, o interesse vai te matar.
Então, meu conselho: comece a avaliar seu trabalho com base em saber se você está maximizando seu valor em vez de maximizar sua eficácia. E se você praticar isso, você desenvolverá a mesma intuição que você já desenvolveu em sua área técnica.
Como uma nota lateral, eu comecei recentemente a fazer a técnica pomodoro e isso ajudou muito. Em vez de seguir tangenciando uma tangente, concentre-se em pequenos intervalos de tempo e depois aloque pomodoros para futuros trabalhos / pesquisas. É incrível quantas vezes eu fiz uma nota para pesquisar um tópico, mas uma hora depois, quando chegou a hora, pensei comigo mesmo, "há pelo menos três outras coisas que eu poderia fazer com o meu tempo hoje, que são todas mais valiosas". p>
Eu tive o (provavelmente) mesmo problema há muitos anos, durou alguns anos e eu superei. Então, talvez seja de algum interesse para você saber como consegui isso, mesmo que não tenha certeza de que o meu caminho também se aplica a você.
Você também deve dar uma olhada aqui: Os sete estágios do conhecimento 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 ponto entre o estágio 3 e o estágio 4 na tecnologia que você está usando atualmente (proficiência em habilidades depende da tecnologia, você pode dominar algumas tecnologias enquanto ainda aprende outras).
Agora eu começo com um testemunho biográfico.
Um pouco de contexto. Tenho 47 anos. Comecei a programar em 12 nos anos 80. Enquanto cursava o ensino médio, também trabalhei como programador profissional em meio período. Basicamente, isso não me deu muito 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 fiz 20 anos, sempre que comecei qualquer tarefa de programação, eu sabia muitas maneiras de resolver os problemas dados e estava muito consciente dos muitos parâmetros e armadilhas nas mãos, e desvantagens e limites de qualquer método.
Em alguns pontos (digamos, cerca de 26 anos de idade) tornou-se realmente difícil para mim escrever qualquer programa. Havia tantas possibilidades abertas que não consegui mais escolher entre elas. Por alguns anos (até 6) eu até parei de programar e me tornei um redator técnico de notícias.
Eu nunca parei de tentar programar mesmo assim. 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 poderia possivelmente funcionar".
Basicamente, eu me forcei a não me importar com a eficiência do código (que era meu principal obstáculo, evite projetos ineficientes), mas siga o caminho mais fácil. Eu também me forcei a me importar menos com erros, e atrasar o tratamento de erros para um momento posterior, depois de escrever testes para aumentar o erro (realmente isso é TDD).
Isso é algo que aprendi quando estava escrevendo. Quando eu não sei o que escrever, ou eu sabia o que estava escrevendo era ruim. Apenas continue. Na verdade, escreva as coisas ruins. Eu eventualmente irei corrigi-lo 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 na primeira vez.
Realmente, é muito provável que um código que você acredite ser bom na primeira escrita precise melhorar tanto quanto realmente ruim.
Se você seguir o caminho da Simplicidade, você também receberá um bônus adicional. Você aceita facilmente remover / alterar o design / codificação inicial. Você tem uma mente mais flexível.
Eu também tive o hábito de colocar um comentário temporário no código, explicando o que eu não estava fazendo agora e pretendia fazer mais tarde, quando o código fosse funcional no caso de uso normal.
Eu também participei de um XP Dojo e pratiquei katas de código com outros programadores para internalizar as práticas do XP. Ajudou. Isso tornou os métodos formais acima instintivos. A programação em pares também ajudou. Trabalhar com jovens programadores dá algum impulso, mas com a experiência você também vê o que eles não fazem. Por exemplo, no meu caso, muitas vezes os vejo envolvidos em projetos excessivamente complicados e conheço o pesadelo de design que pode levar a. Foi assim. Fez isso. Tive problemas.
O ponto principal 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 novato (e não testei nada), mas também não tenho medo de refatorar e certamente gastar muito menos tempo depurando (quase sem tempo, faça menos de 10% de tempo ).
Resumindo: eu superei meu codeblock usando métodos ágeis (XP), buscando simplicidade e refatorando, e praticando para tornar isso instintivo. Isso funcionou para mim. Não tenho certeza se pode ser generalizado para qualquer outra pessoa.
Em termos de nível de aquisição de habilidades, eu aprendi principalmente a aceitar que toda vez que eu mudo de tecnologia (aprendo nova linguagem, novo framework, etc.) eu vou passar por um estágio quando estou desacelerando. Isso é normal e acabará por superar isso. Eu também posso compensar isso com boa metodologia e habilidades de programação de propósito geral e não será um problema tão grande.
Uma parte importante da programação é gerenciar e controlar a complexidade e, para mim, pessoalmente, é um dos principais problemas. Se ignorada, então a frequência de deficiências aumenta ou, como no seu caso, o ETA do software finalizado aumenta drasticamente.
Acomplexidadedosoftwarepodesercontroladaegerenciadaapartirdediferentesníveiseformas,masumaboaregrapráticaé:"A principal prioridade de qualquer projeto de software é a satisfação do cliente, que é uma função de suas expectativas." p>
Em outras palavras, a complexidade do software depende muito de sua capacidade de controlar as expectativas de seu cliente.
Quando se adota essa visão, dois pontos importantes tornam-se óbvios:
O seu exemplo é muito bom, "simplesmente escreva" vs "miríade de outras considerações". Pense nisso - se alguém escrever requisitos exaustivos para ambas as variantes, pode haver uma equivalência entre os 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á compensações a serem feitas entre confiabilidade, robustez, segurança, velocidade, custo de hardware, custo de desenvolvimento, tempo de entrada no mercado, o nome dele. Nem sempre você concorda com o modo 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, desde "minha página pessoal" até "executar o reator nuclear", e o código deve ser escrito de acordo. Se uma falha significa "recarregar minha página pessoal", quem realmente se importa se isso acontecer? Mas se um acidente significa "Chernobyl", então sua preferência por código sólido é algo casual para o meu gosto.
Existem alguns clientes que aceitarão com prazer o código de nível "Prova de conceito" e o executarão em seus sistemas ativos, e geralmente eles têm administradores de sistemas bem acostumados com isso. IME seus sistemas são geralmente indisponíveis por uma hora ou mais no meio da noite, enquanto um monte de reinicializações agendadas acontecer. Mas eles tomaram a decisão de negócios de que é assim que querem rolar. O ideal é que seu campo seja tão veloz que códigos de alta qualidade nunca estariam prontos, mas muitas vezes porque eles não podem ver o valor (se um sistema "simplesmente funciona" eles nunca o percebem, portanto esse sistema não representa valor para dinheiro). Se incomoda muito, tente evitar esses clientes.
Manter-se atualizado é o tempo que todos nós temos que gastar, ou pelo menos deveria gastar. Às vezes isso faz com que você trabalhe, outras vezes apenas mantém sua mente em boa forma. De qualquer maneira, tente aproveitar.
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 ...
Erros nesses tipos de aplicativos são muito caros e empregam pessoas que pensam como você, como 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", onde você tem todas essas peças dependendo de muitas outras. Puxe a peça errada e você tem um erro, puxe uma peça correta / necessária e você ainda pode produzir um erro. Quanto mais complexo for o sistema, mais tempo você gastará pensando em maneiras de tornar seu código mais robusto e, espera-se, mais seguro também. A velocidade seria boa, mas acho que a velocidade ocupa muito o lugar nos dias de hoje quando você ouve a notícia de que a empresa "XYZ" foi hackeada e 6 milhões de números de cartão de crédito do cliente foram roubados.
Seus clientes podem não querer ouvir que seu programa 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 precisa de fechaduras e portas ... porque quem quer ouvir tudo isso?
Se você está pensando demais, você está indo sobre as coisas da maneira certa, exceto que você precisa escolher uma estratégia que parece "concreta" e apenas ir com ela.
Parece que você está ciente da sua tendência a pensar em tudo que pode dar errado.
Desenvolvedores cautelosos experientes muitas vezes aprendem a seguir o mantra YAGNI , você não vai precisar, quando eles tentam retornar a um fluxo de trabalho enxuto, ágil e produtivo depois de ficarem muito sufocados pelas ervas daninhas do modo de falha análise-gone-amok.
Lembre-se 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 ao considerar alterações em sua abordagem. Ir mais rápido e cometer mais erros pode ou não melhorar as coisas.
Se você trabalha em uma boa companhia, provavelmente pode discutir isso em sua própria equipe e com seu próprio supervisor, sem que seja um Limite de Carreira. Se você não puder, agora é um bom momento para descobrir isso e encontrar um novo emprego.
A única coisa que consigo ver é: "Você está se tornando cada vez mais valioso".
Quando você obtém mais experiência, aprende sobre coisas que deve evitar, e é isso que faz de você uma pessoa melhor do que outras.
Uma coisa você teria notado que seu código seria mais seguro e mais fácil de manter agora.
Minha sugestão seria me concentrar nessa parte.
em caso de dúvida padrão para mal cotar Knuth ...
"Otimização prematura é a raiz de todo mal."
Aqui está o que eu sugeriria, já que parece que você tem um problema que eu tenho de tempos em tempos ...
O que realmente funciona para mim ...
o que você realmente fez:
também confie em assertivas no desenvolvimento inicial ... e então descubra quais remédios precisam ser implementados e você não escreverá código inacessível ou difícil de testar.
Acho que você deve se ater aos seus padrões de codificação, mas certifique-se de estar à frente dos seus clientes. Muitos clientes não sabem o que é preciso / custos para construir 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 sandbagging . "Eles não disseram que queriam um site altamente seguro". Na maioria dos casos, é porque eles não foram solicitados. "Você se importa se seu site de comércio eletrônico for invadido?" É claro que eles se importam e por que você criaria para permitir que alguém penetrasse na segurança? Você tem que educá-los.
Apenas certifique-se de fazer o que o cliente está lhe pagando para 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 querer passar clientes que querem algo barato.
Pense nas conseqüências práticas de um bug em comparação a todos os outros problemas que precisam ser resolvidos.
Considere as seguintes consequências da criação de um código de código mal escrito:
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 o negócio está enfrentando.
Idealmente, o # 2 - # 5 nunca aconteceria. Na vida real, com prioridades conflitantes, as pessoas que assinam seu cheque de pagamento podem querer que você esteja trabalhando em outras coisas, em vez de escrever um código perfeito que nunca, jamais, tenha um problema. Eles não ficarão impressionados se o número 5 for consertado à custa de não consertar 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ão regular, etc. Desta forma, eu não tenho que reescrever continuamente as coisas que não mudam.
Ter um wrapper para tarefas de criação de arquivos 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 nulo ou um arquivo (ou o que você julgar útil).
Acho que você precisa aprender a decidir quanto precisa ser feito para cada projeto. Alguns projetos podem ser triviais e você realmente não precisa gastar todo esse tempo para aperfeiçoá-lo. Nem tudo vai precisar de criptografia sólida, nem tudo será dimensionado para milhões de usuários.
Escrever um programa que pode ser bem dimensionado para mais de um milhão de usuários levará tempo e experiência que você tem agora, mas se você sabe que seu aplicativo não será usado por mais de 1.000 usuários no máximo, não faz sentido em gastar todo esse tempo aperfeiçoando-o.
Eu acho que esta é uma etapa importante na sua carreira de programação e agora você precisa ir para o próximo nível, que tem a ver com a maturidade e não com a programação. Você precisa ser capaz de decidir corretamente quanto tempo e código devem ser suficientes para qualquer projeto em particular.
E como tudo mais, você pode conseguir isso também com a prática. Portanto, tente decidir isso antes de iniciar um projeto, em algum momento, mesmo quando você já estiver trabalhando nele, com a experiência, você também passará por isso. Pode haver alguns acertos e erros no começo, 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é eu estou enfrentando essa questão agora. Mas o que eu percebi é em última análise, questões de qualidade. Se eu morrer hoje, alguém deve ser capaz de captar o que estou fazendo agora de onde me resta. Tais devem ser os padrões de programação (Universal).
Eu me mudei de desenvolvedor para arquiteto agora. Mover-se para a Administração está mudando a linha. Se você quiser continuar com sua paixão, pode se tornar Arquiteto.
Inicialmente, como Arquiteto Técnico - > Arquiteto de Soluções - > Arquiteto Corporativo - > Arquiteto-chefe e assim por diante.
Como Arquiteto, você estará orientando as pessoas para o sucesso. Pessoas como você, que vêm programando há décadas os anos de experiência que você pode utilizar para orientar os outros.
Como um pássaro mais alto voa mais terra que pode ver assim é a sua experiência.
Deixe-me também dizer que a implementação correta da programação é 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 havíamos entregado a tempo, mas isso não adiantou! Foi-me dado o papel de guiar, embora o mesmo júnior tivesse 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 é: parar de escrever código, em vez disso, vender sua experiência em identificar os problemas com antecedência.
Em outras palavras, torne-se um Consultor .
Muitas organizações estão dispostas a pagar dólares caros (se não o valor máximo) para que alguém detecte os problemas antes de passar meses criando o código que causa os problemas. É bem sabido que consertar um bug no design, é muito mais barato / fácil do que consertá-lo depois de ter sido codificado, testado e implementado.
Você não vai escrever tanto código, e você provavelmente vai sentir falta disso, mas então parece que as linhas de código não são a sua força principal, mas em conhecer quais linhas de código deve ser escrito - e que não deveria.
Concentre-se em seus pontos strongs.
(bem, se é isso que você gosta ...)
Minha melhor recomendação para você é: blocos de construção.
Crie um bloco de construção de arquivos no qual você possa confiar sempre, crie um para sua API, pare de desperdiçar seu tempo escrevendo a mesma coisa repetidas vezes. Pense em cada problema uma vez e corrija de uma vez por todas.
Ninguém vai se atualizar sobre isso, certamente não o novato que passa 80% do tempo depurando código que falha em casos que não entendem.
Acima de tudo, não corrija problemas que não possam acontecer, como permissões erradas.
Se as permissões estiverem erradas, algo já está errado e você deve corrigir isso em vez de tornar seu programa à prova de balas.
Em algum momento, você simplesmente não deve se atirar no pé, em vez de sempre verificar se fez isso ou não.
Em vez de gastar tempo com documentação, gaste tempo fazendo seu código autodocumentar e o mais curto possível. Substitua todas as funções duplicadas. Encolha sua biblioteca, renomeie as coisas com precisão.
Não seja muito duro consigo mesmo. Você está trabalhando em uma profissão de crescente complexidade, que requer mais inteligência humana, conhecimento e experiência do que nunca.
O poder de processamento do computador está diminuindo - talvez protelando em breve - levando à necessidade de introduzir chips de múltiplos núcleos, números alimentados por gpu, paralelismo, etc. Existem apenas tantos 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 correm 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 atrás.
Também pode significar que programadores experientes podem se tornar mais valiosos no futuro - muito parecido com outras profissões, como engenharia, em que os ganhos de pico geralmente ocorrem no final da carreira.
Assim como você, comecei a programar aos 14 anos, também quando consegui meu primeiro computador (apesar de ter estudado por alguns meses naquele momento). No entanto, eu sou "apenas" 33 agora. : -)
Minha sugestão é que, ao desenvolver algo, você tome cada uma dessas preocupações (permissões de arquivos, número de arquivos em um diretório, etc.) e use toda a sua vasta experiência para responder a algumas perguntas sobre isso, esse espírito:
Armado com essas respostas, um cara tão experiente não terá problemas para tomar uma decisão sábia. ; -)
É da responsabilidade dos "veteranos" como você apresentar esse tipo de requisito, e isso envolve identificar o que pode dar errado e decidir em quais problemas potenciais você deve dar 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 facilmente.
Nas palavras de Edsger Dijsktra: “Se a depuração é o processo de remover erros de software, então a programação deve ser o processo de colocá-los.” Você está apenas fazendo menos do último, então você tem que fazer menos do antigo . É apenas uma questão de aprender a gastar tempo codificando corretamente. Eu ainda sou um programador relativamente jovem (leia 20 anos) e aspiro ser capaz de codificar algo completamente certo uma vez. Uma hora de planejamento e 10 minutos de codificação é muito melhor do que um planejamento de 10 minutos, uma hora de codificação e três de depuração.
Tags experience effort