O uso de novas técnicas prejudica a produtividade? [fechadas]

Parece que à medida que cresce a experiência com o conjunto específico de ferramentas com as quais você precisa trabalhar, o incentivo para experimentar coisas novas enfraquece.

Quando eu era novo nesse trabalho de programação, experimentar coisas novas, pesquisar online, me tornava mais produtivo, porque muitas vezes encontrava uma maneira (ou biblioteca) que tornava a tarefa mais fácil que a estrutura de código já estava em vigor. Então, usar algo novo - para mim e no contexto da base de código fornecida - me tornou mais produtivo.

Agora notei que há cada vez mais instâncias em que, para um determinado problema, eu sei que provavelmente existe uma solução melhor "lá fora" e descobrir que - presumivelmente - melhoraria o código. No entanto, dado meu conhecimento agora íntimo da base de código, é muito mais fácil usar as ferramentas abaixo do ideal que temos e obter uma solução (incluindo testes) em execução do que encontrar algo novo e "melhor" e "melhorar" a base de código.

Portanto, existe essa tensão: "faça-o corretamente" versus "faça o trabalho decentemente ".

Isso é algo que acontece com muitos desenvolvedores? Esse é um problema específico conhecido? (É um problema real, afinal?) Isso realmente tem a ver com o aumento dos níveis de experiência?

Ah, e observe: eu ainda gosto do meu trabalho e gosto de mantê-lo. É só que parece - sempre interessante! - a parte de pesquisa fica menor à medida que aprendo a base de código e os conjuntos de problemas que enfrentamos com nosso aplicativo.

Muitas vezes, é arriscado tentar coisas novas. Às vezes, enfrentamos problemas porque costumamos fazer duas coisas:

1. Superestime o quão útil é a coisa legal / nova / snazzy. Vemos um exemplo interessante, algum código lançado online. Muito legal, pensamos. Muito legal! No XI, é possível executar a tarefa Y dez vezes mais rápido. É claramente superior. Ainda não vemos todas as "incógnitas desconhecidas". Não fomos surpreendidos pelos problemas que os vendedores da novidade omitem. Não temos experiência suficiente na novidade para ver as minas terrestres esperando no caminho.

2. Subestime a utilidade das ferramentas / framework / software / coisas existentes. Geralmente não estávamos lá quando o sistema atual foi construído inicialmente. Não apreciamos as delicadas trocas que foram feitas. É fácil jogar o quarterback de segunda-feira de manhã em um sistema existente, mas funciona . Provavelmente tem muita estranheza devido a trocas muito específicas entre manter a manutenção, trabalhar e ter um bom desempenho. Sim, com certeza é estranho. Talvez o mais importante seja que a equipe seja especialista na estranheza atual e saiba como lidar com essa estranheza. Eles conhecem as minas terrestres, as armadilhas e as armadilhas a evitar. Na verdade, é precisamente porque vemos todas as verrugas na maneira atual de fazer coisas que estamos interessados ​​em brincar com coisas novas.

Mas deixar de tentar coisas novas e agir de forma muito conservadora é provavelmente ainda mais perigoso. Claro que precisamos pisar com cuidado, mas se não descobrirmos como criar a melhor armadilha para ratos, nossos concorrentes um pouco mais dispostos a tentar algo novo aparecerão e chutarão as bundas! Agir de forma conservadora e não evoluir pode resultar em uma destruição inevitável, especialmente em um mercado competitivo.

Então, sim, precisamos equilibrar a manutenção e o envio da coisa atual com algum nível de experimentação lúdica / educacional, com novas maneiras de resolver problemas, tendo em mente que muitas dessas novas formas são becos sem saída, enquanto outras podem ser recompensadoras. IMO Esse é um bom motivo para muitas empresas terem 20% de tempo para brincar com coisas novas. Eles sabem muitas vezes que não dão certo, mas muitas das idéias que saem de 20% do tempo se tornam gangbusters. Sem tempo para brincar e experimentar, você pode facilmente estagnar como empresa e realmente se ferrar.

Isso acontece o tempo todo . Eu já disse isso em outras postagens, mas mais vezes do que não, você não está no negócio de desenvolver código elegante, está no negócio de enviar um produto. Dessa forma, será difícil encontrar qualquer gerente que esteja disposto a alocar nhoras para que você conserte algo que não está quebrado e realmente (no final do dia) não melhora muito a experiência do usuário final. Você terá tanta dificuldade em encontrar um gerente disposto a alocar nhoras para pesquisar (sem um objetivo final claro) que não seja "provavelmente existe algo melhor do que o que está sendo feito".

Dito isto, se houver gargalos em seu aplicativo que você descobriu usando ferramentas de criação de perfil e tal, e você pode quantificar claramente o aprimoramento esperado da experiência do usuário que a correção traria, então (com bastante facilidade) você deveria ter tempo para fazer alguma pesquisa e desenvolvimento trabalhe para otimizá-los usando técnicas que você pode encontrar de várias fontes.

Eu acho que parte disso se resume a ter esforço e conhecimento mais profundo de como resolver com êxito alguns problemas.

Quando você é novo, todos os problemas também são novos e você precisa pesquisar como resolvê-los. Mas, como você resolveu o mesmo tipo de problema repetidamente, a necessidade de pesquisar diminui, pois você conhece uma solução bem-sucedida para esse problema.

Então, você só tende a pesquisar os novos problemas ou aqueles onde os antigos tentados e verdadeiros não funcionam mais (foram preteridos) ou estão causando um problema de desempenho ou falha. Quando você começa a entender um sistema complexo com mais profundidade, sabe que não tem tempo para usar realisticamente novas técnicas toda vez que elas aparecem e descobriu por experiência própria que, muitas vezes, a nova técnica não vive até seu hype e cria mais problemas do que resolveu. Portanto, você fica menos inclinado a usar novas ferramentas e técnicas quando na verdade não precisa delas para resolver o problema.

Porém, menos inclinado não deve significar que você para de aprender ou nunca usa uma nova técnica, apenas que é mais criterioso sobre quando é apropriado.

Aqui estão alguns detalhes:

1. Existem prazos : o programador deve ter previamente todos os detalhes necessários disponíveis das ferramentas que está usando. Ler um site, encontrar algo interessante e usá-lo no ambiente de produção é um grande não-não. Você simplesmente não tem experiência suficiente com a ferramenta e, o que é mais importante, não tem o tempo necessário para começar a aprender algo novo. Se você quiser coisas novas e legais, aprenda-as meio ano ou ano antes de usá-las.
2. Certifique-se de conhecê-lo corretamente antes de usá-lo : alguma ferramenta nova e agradável pode ser divertida de usar, mas pesquisar soluções e usá-las sem aprendê-las adequadamente pode ser muito ruim. Você simplesmente não tem experiência suficiente com isso. Se você precisava pesquisar no Google para descobrir isso significa que você simplesmente não o conhece bem o suficiente para corrigi-lo quando ele quebra metade do sistema.
3. Usar o material mais recente não está funcionando corretamente : o material novo não é uma tecnologia comprovada. No próximo ano, a tecnologia provavelmente desapareceu completamente, sendo você o único no mundo a usá-la por mais tempo. Todo mundo notou que simplesmente não funciona. É preciso muito trabalho para evitar a mais nova bala de prata, mas vale a pena.
4. Concentre-se nas técnicas que são o seu conhecimento principal : todo programador conhece apenas uma pequena parte de todo o conhecimento de programação disponível no mundo. A parte em que o programador se sente confortável o suficiente é ainda menor. A parte que realmente funciona é ainda menor. Use apenas o conhecimento que aprendeu corretamente e sabe que funciona. Isso torna o programador mais rápido e resulta em um melhor código.
5. Não o ajuste infinitamente : o código perfeito é um bom objetivo, mas isso não significa que você escreva algumas porcarias primeiro e depois o ajuste infinitamente para torná-lo incrementalmente melhor. Escreva perfeitamente da primeira vez, usando todo o bom conhecimento que você tem. Confie em si mesmo. Não confie no mundo. Ninguém mais sabe exatamente as mesmas coisas que você. A opinião deles não importa. Você é o programador, precisa fazê-lo funcionar. O mundo não pode fazer isso por você. Quando terminar, pare. Não toque até alguém reclamar.
6. Gaste tempo para aprender coisas novas : todos precisam aprender coisas novas continuamente. O nosso futuro depende disto. Apenas se recuse a usá-lo! Aprenda coisas novas, mas não as use até ter certeza de que realmente está funcionando. Você terá chance de usá-lo no próximo ano, uma vez que é uma tecnologia comprovada. Ou você esqueceu, como todo mundo - apenas as coisas boas permanecem ...
7. Não perca as coisas boas : depois de criar com êxito grandes sistemas e corrigir todos os problemas neles, e aprender algumas técnicas legais, a pior coisa a fazer é despejar esse conhecimento e buscar algo novo. Você já sabe como funciona, quais são os problemas e como resolvê-los. Jogá-lo fora é apenas perda de tempo.
8. Acompanhe as novas tecnologias : um dos novos sistemas será bem-sucedido. Tem algo fundamentalmente melhor do que qualquer outra coisa no mercado. Você simplesmente não sabe qual é a bala de prata. Se você não conseguir encontrá-lo a tempo, seu conhecimento estará desatualizado. O mundo pode fazer você perder todas as coisas boas removendo o acesso aos sistemas antigos.

Sim, tive que acontecer. Geralmente, você precisa fazer uma análise de risco sobre quanto tempo vai custar para aprender a nova técnica e pode recuperar e usar uma técnica mais antiga, caso a nova técnica não atenda às expectativas. Prefiro aprender novas técnicas quando posso, mas quando a pressão está alta e não posso me dar ao luxo de gastar tempo tentando coisas novas que podem falhar, continuo com métodos testados e aprovados.

Em geral, acho que o melhor momento para aprender novas técnicas é no início de um novo projeto. Geralmente, não há muita pressão e, se você encontrar algo novo que funcione bem, poderá integrá-lo facilmente ao restante do projeto, daqui para frente. O pior momento para tentar aprender coisas novas é nas últimas duas semanas frenéticas antes de uma grande implantação.

Sim, coisas novas prejudicam a produtividade

Sim, claro. Mesmo para o melhor cenário, coisas novas requerem tempo adicional porque não são familiares. Muitas vezes, pode custar muito mais tempo.

Não, novas técnicas podem melhorar a produtividade

Qualquer nova técnica que permita expressar uma solução com mais facilidade aumentará sua produtividade. Isso pode ser tão simples quanto passar de grandes if-elseifcondições para uma tabela de expedição.

Sim, isso pode prejudicar a produtividade. Minha ex foi convidada a fazer um trabalho chato de processamento de dados uma vez, então ela decidiu que seria melhor escrever um programa longo para lidar com os dados e depois executá-lo - o que resolveria o problema em segundos.

Levou uma semana para escrever, é claro, mas o problema foi resolvido em segundos depois disso.

Penso que o mesmo se aplica à sua pergunta: sim, você pode aumentar sua produtividade aprendendo coisas novas, mas ainda seria melhor aplicar o conhecimento existente à tarefa e, em geral, fazê-lo mais rapidamente. Quem se importa em encontrar e aprender uma nova biblioteca, se conseguir escrever a sua em menos tempo.

Não se esqueça também: muitas vezes fazê-lo decentemente com as ferramentas existentes é uma solução melhor do que colocar as coisas novas. Cada vez que você adiciona novas, aumenta a superfície de manutenção necessária, o que, por sua vez, atrasa todo mundo (e pode torne seu código bastante confuso - penso nas camadas da 'nova' tecnologia que passaram para o legado ao longo do tempo, mas ainda estão em nosso código tornando as coisas horríveis.Lembrando, seria melhor usar apenas os modos C antigos em vez de adicionar todo esse COM e todo esse VB e todo esse .NET e agora inserindo HTML nele também)