Equilíbrio entre “ferramenta certa para o trabalho” e familiaridade [fechado]


19

Portanto, ao escolher qual idioma usar em um projeto, em um mundo ideal, o idioma é escolhido porque é a ferramenta certa para o trabalho. No entanto, muitas vezes eu prefiro usar um idioma em que eu seja fluente do que em um que eu precisaria aprender ou que tenha apenas conversação. É claro que a fluência no idioma também envolve o conhecimento das bibliotecas aplicáveis ​​no idioma. Só porque eu realmente gosto de uma linguagem de uso geral, como Java, não significa que eu sempre deva usá-la, mas, ao mesmo tempo, isso não significa que eu deveria criar algo como Perl toda vez que houver algum processamento de texto a ser feito. Como encontrar o equilíbrio aqui?

Respostas:


12

Uau, essa é uma pergunta MUITO difícil quando tirada do mundo da teoria e para o mundo da produção.

Em teoria

Simples. Sempre use a melhor ferramenta para o trabalho e apenas aprenda o que você precisa.

Na prática

Além da questão de sua fluência, há uma série de outras questões comerciais que precisam ser feitas antes que você possa responder:

  • Custo da compra do "ferramental correto"
  • Custo de apoiar isso - as pessoas precisam ser treinadas
  • Curva de custo de aprendizado
  • Custo de integração com outros produtos (agora e no futuro)
  • ... etc

Fora da teoria, existem sérias ramificações para sua escolha de tecnologia.

Agora não estou dizendo para não escolher a ferramenta correta - apenas certifique-se de que a ferramenta correta possa se equilibrar quanto à implicação de custos.

Se este é um projeto pessoal - sempre use a ferramenta "correta" - para que, quando você se deparar com essa decisão no contexto comercial, possa fazer uma chamada mais informada.


2
Não é "simples" em teoria. O que realmente significa melhor ? Quais são os critérios?
Whatsisname

+1: quando todos os fatores foram combinados, a ferramenta correta pode não acabar sendo a melhor ferramenta - poucas pessoas conseguem isso, escolhem a melhor ferramenta e sofrem as consequências.
Steven Evers

1
O @whatsisname best é subjetivo e depende do seu ambiente, orçamento, prazo ... - mas, no espírito de um projeto doméstico, seria o caso de experimentar uma tecnologia projetada para resolver esse problema. Por exemplo, Erlang para distribuído, Perl para manipulação de texto - então você pode fazer seu próprio julgamento.
Stephen Bailey

Uma coisa de que tenho cada vez mais certeza é que o Java geralmente não é a ferramenta certa para o trabalho. Existem tantas alternativas melhores. Não me interpretem mal. Era uma ótima linguagem nos anos 2000 e muitas pessoas se acostumaram, mas para mim não é a melhor ferramenta (mas ainda é uma ferramenta em alguns casos que uso, mas não a melhor) para o meu trabalho. Não é para mexer, nem para big data, nem para web.
dbow 13/03


3

Isso não é realmente resolvível, exceto como uma questão de negócios. No entanto, muitas perguntas de negócios são feitas apenas para números de curto prazo, o que é um erro em coisas como essa.

Minha abordagem geral:

  1. Se for algo pequeno ou de curto prazo, sempre escreva nas ferramentas familiares.
  2. Se for uma coisa grande e de longo prazo, observe a relação custo-benefício de aprender uma nova ferramenta.
  3. Se você não tiver certeza, trate-o como uma coisa de curto prazo até ter evidências de que é uma coisa de longo prazo. Então vá e olhe para a decisão novamente.

Três coisas a ter em mente ao pensar em custo e benefício: Primeiro, as pessoas com pressa tendem a mudar o futuro. Segundo, os custos de manutenção são a maior parte dos custos de qualquer sistema bem-sucedido. Terceiro, bons desenvolvedores gostam de aprender coisas e manter seus desenvolvedores felizes é um bom investimento a longo prazo.


1

Ótima pergunta! Como o whatsisname disse em sua resposta, "a familiaridade não recebe crédito suficiente". Uma ferramenta diferente, uma estrutura diferente, uma linguagem diferente poderia ser muito melhor do que você está acostumado a usar, e você ainda seria muito menos produtivo com ela na primeira vez em que aprendeu as cordas.

Eu trabalho há alguns anos como desenvolvedor de ASP.NET em agências digitais, onde temos uma mistura de grandes projetos, pequenos projetos, projetos restritos, projetos bem acolchoados etc. O que tentamos fazer, expandir nossas habilidades, é procurar "metas flexíveis", projetos menores que não tenham prazos difíceis e difíceis e usá-los como uma oportunidade de usar novas tecnologias que possam ser superiores. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework - todos eles que usei pela primeira vez em um projeto desse tipo.

Se você pode aproveitar suas oportunidades dessa maneira, esperamos que esteja pronto com um conjunto maior de opções para escolher a ferramenta certa sem sofrer falta de familiaridade. Assim como no exemplo de Julio: eles encontraram um alvo em que poderiam adicionar Ruby ao seu repertório e, agora, eles podem escolher entre Java e Ruby.

Mas se o prazo for curto e sólido e o projeto for importante, recomendo que você se atenha às ferramentas familiares. Algo diferente pode ser mais adequado, mas em projetos como esse, tudo se resume a riscos .


1

Isso depende de algumas coisas:

1. Você é bom em aprender novos idiomas ou ferramentas.

Se você é um estudo rápido, a barreira para aprender novos idiomas ou ferramentas é menor. Isso lhe dá a oportunidade de adicionar outra ferramenta à caixa de ferramentas.

2. Como independente da linguagem / ferramenta você cria seu ambiente de trabalho.

Se o seu fluxo de trabalho é altamente dependente de ferramentas, as barreiras para o aprendizado de diferentes idiomas são maiores. Se você está conectado a um IDE específico, a troca de idiomas envolve muito mais do que apenas aprender um idioma, pois a edição de texto certamente o frustrará.

Alguém usando vim ou emacs não tem esse problema. Tudo o que eles precisam fazer é aprender o novo idioma.

3. Realidade do negócio

Aprender novas ferramentas / idiomas leva tempo. Esse tempo tem um custo. Mas esse custo tem o potencial de ser um investimento que paga mais do que a despesa inicial. Além disso, uma solução desagradável geralmente leva mais tempo para implementar e é mais difícil de manter. Se for algo maior do que um projeto pequeno, e as ferramentas da minha caixa de ferramentas existente não parecerem adequadas ao problema, pesquisarei quais ferramentas são adequadas para o problema. Também investi em um ambiente para se adequar a uma abordagem generalista, aprendendo a usar o vim como meu editor escolhido.

Outra coisa - qual é a menor distância entre dois pontos? Se alguém escreveu algo que quase faz o que eu quero fazer, geralmente é mais rápido modificá-lo para atender às minhas necessidades.


0

Se há um novo idioma que você está curioso e você (e a empresa) podem pagar, por que não dedicar algumas semanas a um mês para explorá-lo?

Foi assim que aprendi Ruby. Meu parceiro de codificação tinha 7 anos de experiência com Java. Eu tinha 11 anos de experiência em Java. Nenhum de nós sabia nada sobre ruby, apenas que queríamos experimentar.

Eu o convenci e ao resto da empresa a tentar ruby ​​por um mês (esse seria um projeto de 6 a 8 meses). Na pior das hipóteses, começaríamos esse tempo usando Java.

Felizmente, depois de uma semana, ficamos viciados, então tudo acabou bem. Talvez você possa tentar algo semelhante? Veja se você pode criar algo do zero em algum outro idioma, mas deixando claro para os negócios por que está fazendo isso e, pelo menos o mais importante, qual é o plano B no caso de o experimento falhar.


0

Obviamente, não há uma resposta única para essa pergunta que se aplique a todas as situações. Mas aqui está um aspecto que acho que não foi mencionado ainda. Se você é um desenvolvedor, também deve levar em consideração sua própria comercialização. Se o idioma X for escolhido para o seu projeto, como isso ficará no seu currículo? Pode ser uma boa idéia escolher um idioma com o qual você não esteja familiarizado, para ter um motivo para aprendê-lo, expandir seus horizontes intelectuais e tornar suas habilidades mais atraentes para futuros empregadores.


0

Eu diria que a familiaridade com um idioma também é um aspecto de "ser uma ferramenta certa para um trabalho". Não consigo imaginar uma situação em que, por exemplo, o Prolog seria uma ferramenta certa para o trabalho, dada a minha total ignorância do idioma.


0

Minha própria versão é "usar a ferramenta certa disponível para mim" para o trabalho. Estar "disponível" significa que eu posso usá-lo, não apenas que posso comprar / obter o compilador e / ou o tempo de execução.

Em quase qualquer cenário da vida real, dado um problema, você tem um tempo muito limitado para resolvê-lo. Não acredito que você possa realmente aprender um novo idioma em muito pouco tempo . Aprender um idioma significa realmente ler livros, passar pelo código de outras pessoas, entender como ele funciona e a filosofia por trás dele. Pode-se apenas ler um tutorial na Web (o que é perfeitamente bom como ponto de partida) e obter hackers. Mas isso levaria a um código terrível e você provavelmente seria melhor escrevendo um código melhor em um idioma conhecido em um tempo possivelmente muito mais curto.

Apesar dos méritos do provérbio "ferramenta certa para o trabalho", a maioria dos idiomas populares é de uso geral. Eles podem ter pontos fortes em certas áreas e não serem tão bons quanto outros em outras áreas, mas podem realizar a maioria dos trabalhos. Não conhecer um idioma praticamente significa que a ferramenta não está disponível para você.

Não estou dizendo apenas aprender um (ou mesmo dois ou três) idiomas e usá-los em todos os projetos e não aprender mais nada. É importante aprender outros idiomas, adquirir mais ferramentas para adicionar à sua caixa de ferramentas. Mas, diante de um problema, é melhor seguir as ferramentas que você conhece, em vez de aumentar suas preocupações usando tecnologias desconhecidas. Mas continue aprendendo outros idiomas para que da próxima vez a escolha seja mais fácil.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.