Lei do Instrumento e a Maldição do Programador

Se você não está familiarizado com o Lei do Instrumento, também conhecido como martelo / martelo de Maslow, ou o martelo dourado, é frequentemente expresso como

Se sua única ferramenta for um martelo, você trata tudo como um prego.

Meu entendimento é que a lei do instrumento significa que você está limitado por instrumentos ou ferramentas que você sabe como usar. Por exemplo, se você tiver um parafuso, um pouco de madeira e um martelo, poderá enfiar o parafuso na madeira com sucesso, mas uma chave de fenda seria uma alternativa melhor.

A lei do instrumento também significa um obsessão com a perfeição dos instrumentos que você conhece. Lembro-me de quando estava convencido de que não havia motivo para me preocupar com outras linguagens de programação porque Delphi era a melhor. Agora, passei algum tempo usando várias outras linguagens de programação e, portanto, posso dizer com segurança que Delphi é a melhor, embora também possa ver o valor e o uso de outras linguagens de programação.

Acredito que vale a pena aprender sobre novas tecnologias, frameworks, linguagens ou metodologias. Então você pode escolher o correto para o trabalho. Isso não significa que você precisa ser um especialista em todos eles, mas você deve saber o suficiente para estar confiante em sua escolha.

O reverso disso é a obsessão em perseguir tecnologias novas e interessantes e recriar coisas a cada poucos anos. Isso mantém os desenvolvedores entretidos, mas não fornece valor de negócios. Mais uma vez, acredito que o Delphi faz um bom trabalho com isso, pois respeita o código existente enquanto avança para novas plataformas, recursos e estruturas.

Então, qual é o Maldição do Programador?

Quando estou conversando com outros programadores, vejo dois comportamentos. A primeira é que todos os problemas que encontram na vida (no trabalho e fora dela) eles respondem com “Eu poderia escrever um programa para fazer isso, ”Ou alguma variação. Por extensão, eles também lançam um olhar crítico em relação a qualquer sistema de software (mesmo aqueles desenvolvidos por eles mesmos) para ver como melhorá-los. Isso resulta em um grande acúmulo de projetos que eles criam para consertar problemas, consertar um problema melhor ou apenas por curiosidade para ver se podem.

Isso é semelhante à Lei do Instrumento, mas vejo isso mais como o aprendizado da flexibilidade e o poder da programação resulta em você ver muitas oportunidades de aplicá-la. Conversei com pessoas de outras indústrias e acho que a tendência geral é bastante universal, mas a programação é (na minha opinião) muito mais poderosa e flexível do que muitas outras tecnologias aplicadas.

O segundo comportamento, que é algo para ser mais cauteloso ao cair, é o desejo de criar um “biblioteca”Ou“estrutura”Em vez de terminar o programa em mãos. Por exemplo, você está criando um programa para resolver um problema e, no processo, cria uma série de bibliotecas para o caso de precisar resolver problemas semelhantes.

Há valor em ter bibliotecas, funções, componentes e estruturas reutilizáveis. O truque é não deixar que a criação deles atrapalhe o transporte. A melhor maneira que encontrei de lidar com isso é criar a biblioteca apenas quando você precisar dela. Escreva seu código com o nível apropriado de acoplamento para resolver o problema em questão. Quando você precisar reutilizar um pouco dele em outro lugar, considere refatorá-lo em algo reutilizável. Então, conforme você o usa em mais lugares, você pode continuar a refatorá-lo e expandi-lo até ter uma estrutura completa.

Como você vê a maldição do programador em sua vida? O que você usa para evitar que cada projeto gere uma série de estruturas reutilizáveis?

Fonte:http://delphi.org/2018/01/curse-of-the-programmer/