A programação é uma profissão em uma corrida para baixo? [fechadas]

41

Parece-me que a indústria de programação está em uma corrida para o fundo. Se tomarmos as práticas de:

  1. Não está demorando para implementar as práticas recomendadas
  2. Uso do código de outras pessoas o máximo possível (código personalizado como um passivo)
  3. Usando linguagens cada vez mais avançadas para melhorar a produtividade
  4. "ferramentas" de desenvolvimento baseadas em GUI que simplificam muito a "programação" e não exigem que as pessoas entendam o encanamento por trás do código

Estas coisas implicam para mim que estamos em uma corrida para se tornar como qualquer outro trabalhador de escritório. É do interesse do empregador que as coisas não requeiram habilidade (mais fácil de substituir), para que as coisas sejam pré-construídas (menos tempo de projeto).

Meu ponto aqui é que a) existe um desalinhamento entre a habilidade e os interesses econômicos do empregador? e b) se existe, como você o atenua para impor padrões profissionais?

    
por q303 07.02.2011 / 21:44
fonte

13 respostas

6

Acho que você fez uma pergunta muito comovente.

A criação de ferramentas de codificação GUI coloca os programadores fora de um trabalho, tanto quanto os robôs colocam os trabalhadores da linha de montagem fora de um trabalho. Na minha opinião, enquanto há uma perda de empregos, há também uma mudança no lugar dos próximos trabalhos.

A tecnologia para realizar uma tarefa muda, mas a tarefa ainda precisa ser concluída: os carros ainda precisam ser montados antes que possam ser conduzidos; o código / lógica de negócios ainda precisa ser reunido para que o aplicativo funcione.

Mudanças na tecnologia apresentam opções para programadores: Aprenda programação baseada em GUI ou ferramentas GUI de programa ... ou ... algo totalmente diferente.

Pode haver um desalinhamento entre as habilidades dos funcionários e os interesses do empregador, mas não por muito tempo, especialmente se o empregador for experiente. Portanto, é no melhor interesse do empregador e do empregado que eles busquem o que é para seu benefício mútuo. Mas um inevitavelmente estará à frente do outro. Espero que seja você (-:

Felicidades,

KM

    
por 07.02.2011 / 22:09
fonte
58

Para as tendências que você menciona, eu adicionaria mais uma, que a IMHO explica:

Há muito mais programadores (necessários) do que nunca.

A quantidade de tarefas que exigem ou incluem programação é cada vez maior, e em uma taxa ainda maior do que o número de programadores. Hoje em dia existem vários microchips em um carro comum. Em 5 anos pode haver um chip em sua geladeira e sua torradeira. Em 10 anos, sua calcinha? ... E alguém precisa produzir todo esse software para fazer isso funcionar. Portanto, há todo esforço possível para automatizar o que é automatizável e melhorar a "produtividade" (por mais que seja definido). E mais e mais cérebros frescos são recrutados.

Isso implica que a maioria dos programadores ativos de hoje é inexperiente e / ou mal preparado para seu trabalho. Leva vários anos para chegar a um nível adequado de experiência e é preciso aprendizado constante para se manter lá. A linha inferior é, mais e mais dos trabalhos de programação estão se tornando cada vez menos desafiador. Mas ainda há desafios suficientes para quem está procurando por eles .

Deixe-me jogar o advogado do diabo contra os seus pontos acima:

Not taking time to implement best practices

Muitas pessoas não, muitas pessoas fazem. Tenish anos atrás, quando descobri os testes unitários e a abordagem ágil, nenhum dos meus colegas tinha a menor idéia do que era. Hoje em dia é quase um material padrão nas universidades, muitos recém-formados já entendem isso.

Using other's people code as much as possible (custom code as a liability)

Ao contrário de quê? Reinventando a roda? Ou usando o código de outras pessoas para evitar isso?

Eu acho importante notar que somos pagos (principalmente) para resolver problemas, e escrever código não é o fim, apenas os meios para isso . Se um problema pode ser resolvido sem escrever uma única linha de código, isso ainda deixa o cliente feliz. Especialmente se assim conseguirmos produzir uma solução mais confiável, mais rápida e barata. Eu não vejo nenhum problema com isso.

Using increasingly higher level languages to improve productivity

Ao contrário de codificar tudo em assembly? ; -)

GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

IMHO qualquer ferramenta pode ser mal utilizada. O que não quer dizer que os construtores de GUIs eram necessariamente perfeitos ou mesmo bons - a maioria (ou pelo menos alguns) deles são utilizáveis dentro de seus limites. Mas se alguém não conhece esses limites, isso é um problema da ferramenta ou de seu usuário?

Em geral, eu acredito (apesar de não ter provas para provar isso) que nos dias dos cartões perfurados e códigos de máquina, aproximadamente a mesma proporção de código existente era horrível agora, apenas ambos

  • a quantidade total de código e
  • as chances de pessoas de fora verem esse código

foi muito, muito menos.

Agora, com a Internet e o Daily WTF, ficamos expostos aos piores exemplos dia a dia. É um pouco como assistir a todas as notícias sobre terrorismo e terremotos e se divorciar de celebridades e gritar como esse mundo é perigoso e imoral.

    
por 07.02.2011 / 21:55
fonte
29

Você resume a situação corretamente, mas interpreta completamente o significado.

À medida que o software se torna mais poderoso, as tarefas assumem escala com ele. Então, certamente, pode não ser necessário hoje em dia ser um programador de banco de dados para criar um banco de dados de contatos por telefone quando você puder usar o Access. E pode não ser necessário ser um programador web para criar um blog quando você pode simplesmente ir ao wordpress. Mas, enquanto 15 anos atrás, seria necessário ser um programador para fazer essas coisas, o que os programadores fazem agora é ordens de magnitude maiores do que o que poderia ser feito há 15 anos.

Deixe-me colocar desta forma, daqui a 100 anos, será trivial configurar um sistema tão complexo como o facebook ou o google. Eu não estou falando de suas páginas da web, quero dizer seus centros de dados. Qualquer um será capaz de fazer isso. Ele será embutido em telefones, assumindo que ainda os utilizemos. MAS, ainda haverá programadores, e embora eles possam não estar trabalhando em sistemas tão "triviais" daqui a 100 anos, eles estarão trabalhando em sistemas muito mais complexos e sofisticados que ninguém aqui pode sequer começar a compreender seu alcance e escala. E esses sistemas, como os atuais, estarão longe do alcance do trabalhador de escritório comum, porque algumas pessoas, chamadas programadores, escolherão se especializar em levar a tecnologia daquela época a seus extremos. / p>     

por 07.02.2011 / 22:49
fonte
18

Eu já li esse tipo de coisa há quarenta anos e não estava no começo das previsões. Ainda não aconteceu.

O COBOL era a ferramenta de desenvolvimento original destinada a remover a necessidade de programadores de negócios e era uma linguagem de muito mais alto nível do que o assembler. Bibliotecas de código (para evitar a necessidade de escrever o próprio código) são de antiguidade similar.

De vez em quando, surge algo que permite que não-programadores façam algo mais parecido com o trabalho de programação. Havia as "linguagens de quarta geração" dos anos 80, planilhas sofisticadas como o Excel, geradores de relatórios e coisas do gênero. O que eles fizeram uniformemente, se bem-sucedidos, é remover parte da rotina de programação e permitir que os programadores façam outras coisas mais interessantes.

Esse padrão não vai durar para sempre, mas eu vou precisar de algo mais do que argumentos teóricos e previsões para me convencer de que a programação está de fato caindo em declive.

A questão do COBOL para as ferramentas de desenvolvimento modernas é que elas não substituem a capacidade de obter uma especificação inexata e transformá-la em algo preciso e útil. Essa é a habilidade fundamental dos programadores e por que não estamos indo embora por muito tempo.

    
por 07.02.2011 / 22:44
fonte
3

Os programadores Assembly e FORTRAN provavelmente disseram as mesmas coisas quando a programação estruturada e os intérpretes generalizados estavam chegando ao fim.

No final do dia, o software é uma criação destinada a automatizar algo que antes era feito manualmente. Um departamento de contabilidade em uma corporação moderada já teria exigido dezenas de pessoas, agora todo esse trabalho pode ser realizado pelo trabalho de um ou dois. Como resultado, os postes da meta mudaram e agora esperamos que o padrão de capacidade extra seja de um contador.

A Pixar leva mais tempo para renderizar filmes do que nunca. Apesar do enorme aumento na velocidade de computação, os animadores exigiram complexidade e detalhes cada vez maiores em suas cenas. A animação de calibre Toy Story não é aceitável em 2010 como foi em 1995. Como suas ferramentas avançaram, também têm suas capacidades e, portanto, expectativas.

Quando arrastar e soltar ou outras metodologias de programação são comuns, o mundo exigirá soluções para problemas ainda mais desafiadores e complexos, e eles precisarão de programadores que usem essas novas ferramentas sofisticadas para resolvê-los. Os postes da baliza serão movidos.

    
por 07.02.2011 / 22:17
fonte
3

Embora eu concorde com a maioria das respostas que apontam que ainda haverá muito trabalho a ser feito, darei uma resposta diferente para você considerar:

Sim, e deve ser

Estou aqui para projetar uma solução para problemas que outras pessoas não conseguem. Qualquer coisa no conjunto de ferramentas que demore meu tempo longe de resolver problemas para lidar com todos os pequenos detalhes de como implementar meu projeto é desperdício.

A única razão pela qual eu temeria ir a uma linguagem de nível mais alto ou a uma ferramenta mais simples e mais abstrata é que essas ferramentas costumam fazer suposições que me atrapalham e exigem tempo para trabalhar nas suposições para obter a implementação desejada. / p>

Sempre há mais problemas para resolver do que bons solucionadores de problemas. Mesmo que toda a cadeia de desenvolvedores se tornasse tão simples, a maioria das soluções projetadas seria insuficiente ou ineficiente o suficiente para que as pessoas pagassem por uma solução melhor porque a maioria das pessoas é ruim em ver a solução correta para os problemas. e what-ifs que você precisa considerar para fazer uma boa solução.

Nossos trabalhos são para resolver problemas melhor do que a maioria dos outros, a complexidade da cadeia de ferramentas não é terrivelmente relevante na visualização de imagem grande, desde que saia do caminho e permita que você construa e construa algo bom.

    
por 08.02.2011 / 00:03
fonte
1

Embora as tecnologias de programação possam mudar, a complexidade subjacente de um produto de software ainda está lá. Se o software puder ser escrito completamente usando diagramas ou fluxogramas (ou algum outro modo 'simples'), toda a complexidade do software ainda precisa ser entendida e tratada. Por esse motivo, é importante que os empregadores tenham programadores que conheçam os produtos da empresa de dentro para fora, a fim de atualizá-los ou adicionar novos recursos. E pode demorar um pouco para que os funcionários aprendam um produto de software.

    
por 07.02.2011 / 22:06
fonte
1

Não importa o que você pode automatizar ou extrair da prateleira, a maioria dos softwares embalados se divide em duas categorias:

  1. É simples de usar, mas não corresponde exatamente ao que a empresa realmente precisa
  2. É altamente personalizável, mas é preciso um especialista para entender e aproveitar a personalização

Acho que esqueci o terceiro É um software de produtividade padrão (e-mail, navegador, word proc etc. O software da categoria 1 leva as empresas a contratar desenvolvedores de software para personalizar o software pronto para uso (se possível). bem, eles também podem contratar um desenvolvedor porque a pessoa que conhece esse sistema personalizável por dentro ou por fora é muito procurada (pense em SAP, PeopleSoft, etc.) ou em uma raça em extinção (pense em qualquer sistema semelhante ao SAP e PeopleSoft que não não tem a mesma penetração no mercado).

Sempre haverá necessidade de desenvolvedores. O que estou vendo é que mais do que costumava ser trabalho manual, tedioso e repetitivo se tornou automatizado (pense em escrever código para acesso de dados à mão versus usar um O / RM). Isso permite que os desenvolvedores ofereçam mais valor aos negócios com menos esforço.

    
por 07.02.2011 / 22:09
fonte
1

Eu não aceito seus argumentos:

  1. Not taking time to implement best practices

exceto isso.

  1. Using other's people code as much as possible (custom code as a liability)

A reutilização de código é uma prática recomendada. Código usado é testado. É claro que você deve usar código de boas fontes, que é mantido e usado por muitos.

  1. Using increasingly higher level languages to improve productivity

A produtividade não é ruim por si só - é?

  1. GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

Se a ferramenta faz o trabalho: use-a. Se não, recuse-o. Se a promessa se mantiver, e as pessoas realmente não precisarem entender o código - bem feito! Você parece dizer que esta é uma promessa que não é válida?

(Os números aqui são automaticamente renderizados errado. :))

    
por 08.02.2011 / 09:50
fonte
1

A programação visual não é menos válida ou merece menosprezo do que a programação baseada em texto.

Existem certos déficits e desafios ao programar visualmente, mas o encanamento componente subjacente sendo potencialmente perigoso quando ignorado não é monopolizado por componentes visuais e, mais relevante, por designers visuais. O encanamento subjacente sendo ignorado é um risco para qualquer desenvolvimento.

Se você tiver a chance de experimentar o Labview, poderá ver o potencial (ou até mesmo uma variante especializada no ambiente Lego NXT). Embora não sem falhas ou deficiências, há benefícios hereditários. Ver é acreditar.

    
por 08.02.2011 / 16:49
fonte
0
Práticas de programação não apenas aumentam a produtividade e reduzem os custos para certos tipos de desenvolvimento (sua corrida para o fundo), mas aumentam as capacidades de aplicação e as expectativas do cliente (encorajando assim uma corrida para o topo). Veja os bônus que o Goole e o Facebook estão pagando para obter os melhores tecnólogos.

    
por 07.02.2011 / 22:16
fonte
0

Não há outra profissão que lide com a engenharia da existência que se esforça para mudar tanto quanto a programação. Assim que você simplifica algo, basta abrir uma lata para novos problemas que geram novas idéias.

Portanto, eu não deixaria de lado os esforços de outras pessoas para compartilhar códigos e soluções, a fim de nos ajudar a avançar em direção a novos desafios, idéias e experiências do usuário com as más práticas do praticante individual, maus hábitos e maneiras desprovidas de humanismo.

    
por 07.02.2011 / 23:15
fonte
-2

Se tomarmos as práticas de:

  • Não está demorando para implementar as práticas recomendadas
  • Usando o código de pessoas de outras pessoas tanto quanto possível (código personalizado como um passivo)

WTF? Você quis dizer que essa lista é inconsistente? As listas devem vir do mesmo lado para cada elemento, em vez de alternar sem aviso prévio. Assim, sua lista deve ler:

Se tomarmos as práticas de:

  • Não está demorando para implementar as práticas recomendadas
  • Não usando o código de outras pessoas o máximo possível (código personalizado como um passivo)

    
por 07.02.2011 / 22:29
fonte