A programação como profissão está em uma corrida para o fundo? [fechadas]


41

Parece-me que a indústria da programação está correndo para o fundo. Se adotarmos as práticas de:

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

Essas coisas implicam para mim que estamos na corrida para nos tornarmos como qualquer outro funcionário de escritório. É do interesse do empregador que as coisas não exijam habilidade (mais fácil de substituir), que as coisas sejam pré-construídas (menos tempo do projeto).

Meu argumento aqui é que: a) existe um desalinhamento entre a habilidade e os interesses econômicos do empregador? eb) se houver, como você o mitiga para fazer cumprir os padrões profissionais?


28
Bem, alguém ainda tem que fazer essas ferramentas. Então, em certo sentido, é uma corrida manter bons programadores longe do trabalho chato.
Jeremy Heiler

11
Por que alguém acredita que o futuro do desenvolvimento de software se resume a arrastar e soltar componentes está além de mim. Sério, você honestamente acredita que será assim tão fácil?
pemdas

3
@Pemdas: Medo humano se o progresso e / ou mudar. A locomotiva a vapor, há 150 anos, era vista como má.

4
@ pierre Não sei ao certo onde você está indo com isso.
Pemdas

3
Dijkstra, é você?
L0b0

Respostas:


6

Eu acho que você fez uma pergunta muito comovente.

A criação de ferramentas de codificação da GUI coloca os programadores fora de um trabalho, assim como os robôs colocam os trabalhadores da linha de montagem fora de um trabalho. Na minha opinião, embora haja perda de empregos, também há uma mudança na localização dos próximos empregos.

A tecnologia para executar uma tarefa é alterada, mas a tarefa ainda precisa ser concluída: Os carros ainda precisam ser fabricados / montados antes de serem conduzidos; o código / lógica de negócios ainda precisa ser montado para que o aplicativo funcione.

Mudanças na tecnologia apresentam opções para programadores: Aprenda programação baseada em GUI ou ferramentas de GUI de programas ... ou ... algo completamente 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 estará inevitavelmente à frente do outro. Espero que seja você (-:

Muitas felicidades,

KM


Meu pensamento é focar no desenvolvimento de software mais especializado: programação intensiva em matemática, estatística e computação (embora o terceiro possa estar saindo de moda com o aumento da potência da VM). Eu não acho que esses domínios especializados estejam nessa corrida para o fundo, embora eu não tenha experiência neles, para que eu possa estar errado.
Q303

@ q303: Sempre haverá muitos aplicativos que ocupam toda a energia disponível do computador.
David Thornley

58

Nas tendências que você mencionou, eu acrescentaria mais uma, que o IMHO as explica:

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

A quantidade de tarefas que requerem ou incluem programação está sempre aumentando e em uma taxa ainda maior que o número de programadores. Hoje em dia existem vários microchips em um carro comum. Em 5 anos, pode haver um chip na sua geladeira e na sua torradeira. Em 10 anos, sua roupa de baixo? ... E alguém precisa produzir todo esse software para fazer isso funcionar. Portanto, todo esforço possível é feito para automatizar o que é automatizável e para melhorar a "produtividade" (como 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 preparada 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á. Em resumo, cada vez mais tarefas de programação estão se tornando cada vez menos desafiadoras. Mas ainda há desafios suficientes para quem os procura .

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

Não está demorando para implementar as melhores práticas

Muitas pessoas não, muitas pessoas fazem. Dez anos atrás, quando descobri o teste de unidade e a abordagem ágil, nenhum dos meus colegas tinha a menor idéia do que era. Atualmente, é quase um material padrão nas universidades, e muitos recém-formados já o entendem.

Usar o código de outras pessoas o máximo possível (código personalizado como responsabilidade)

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

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

Usando linguagens de nível cada vez mais alto para melhorar a produtividade

Ao contrário de codificar tudo na montagem? ;-)

"Ferramentas" de desenvolvimento baseadas em GUI que simplificam bastante a "programação" e não exigem que as pessoas entendam o encanamento por trás do código

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

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

  • a quantidade geral 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, somos expostos aos piores exemplos dia a dia. É como assistir a todas as notícias sobre terrorismo, terremotos e divorciar celebridades, e gritar o quão perigoso e imoral esse mundo se tornou.


+1 Acho que estamos em um ciclo de feedback "toda solução gera novos problemas" - não posso dizer se é um loop negativo ou positivo.
Maglob

6
+1 Se apenas bons codificadores reescreverem tudo do zero, eu serei feliz em ser um programador de baixa qualidade.
AndrewKS

1
Não quero batatas fritas na minha cueca, a menos que o tempo de atividade seja aceitável!

@ Thorbjørn: qual é o tempo de atividade aceitável para roupas íntimas? Se fosse auto-lavagem, então eu preocupar com o tempo de atividade ... caso contrário, você tem que tirá-los todos os dias de qualquer maneira (espero!)
Dean Harding

1
@ back2dos, não considero isso um desacordo. A linha em negrito indica a tendência, ou as empresas / gerentes visualizam, se desejar; você declara a visão dos desenvolvedores. Concordo plenamente com você que seria ideal ter melhores programadores, educação mais prática, orientação, para elevar o nível de qualidade do setor. No entanto, a triste realidade é diferente. O software tornou-se uma mercadoria que muitas pessoas esperam obter rápido e barato, sem entender as implicações de tais decisões (como custos de curto x longo prazo etc.).
Péter Török

29

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

À medida que o software se torna mais poderoso, as tarefas que ele leva em escala. Portanto, hoje em dia, talvez não seja necessário ser um programador de banco de dados para criar um banco de dados de contatos telefônicos quando você puder usar o Access. E pode não ser necessário ser um programador da web para criar um blog quando você pode simplesmente acessar o wordpress. Porém, enquanto há 15 anos seria necessário ser um programador para fazer essas coisas, o que os programadores fazem agora é uma ordem de magnitude maior do que o que poderia ser feito há 15 anos.

Deixe-me colocar desta maneira, daqui a 100 anos, será trivial configurar um sistema tão complexo quanto o facebook ou o google. Não estou falando das páginas deles, quero dizer dos data centers. Qualquer pessoa será capaz de fazê-lo. Ele será incorporado aos telefones, desde que ainda os utilizemos. MAS, ainda haverá programadores e, embora possam não estar trabalhando em sistemas 'triviais' daqui a 100 anos, eles estarão trabalhando em sistemas tão mais complexos e sofisticados que ninguém aqui pode sequer começar a entender seu escopo e escala. E esses sistemas, como os atuais, estarão fora do alcance do trabalhador de escritório comum, porque algumas pessoas, chamadas programadores, escolherão se especializar em levar a tecnologia daquela época ao extremo.


Ponto de vista interessante ...
q303

10
Eu gostaria que GrandmasterB escrevesse ficção científica.
Ocodo 07/02

5
Mal posso esperar para ter meu próprio data center do google no meu telefone.
Martin York

3
@ Slomojo Não é tão ficção científica quanto você imagina. Quando eu era criança na 3ª série, visitei uma demonstração por computador na faculdade perto de minha casa. Foi uma vitrine experimental para o público. Um dos programas em exibição era um jogo jogável de jogo da velha. Na época, era considerado um momento de ah e ah para poder jogar um jogo contra um computador. Isso foi no final dos anos 60. Quais serão os momentos ah e ah daqui a 100 anos?
Bill

Eu estava me referindo à maneira como ele disse isso, não que o conteúdo fosse material de fantasia , eu estava por perto quando Pong foi revolucionário, tenho certeza de que as crianças da Nintendo também podem se relacionar com as mudanças exponenciais na tecnologia também.
Ocodo

18

Eu li esse tipo de coisa há quarenta anos e não estava no início das previsões. Ainda não aconteceu.

COBOL era a ferramenta de desenvolvimento original destinada a remover a necessidade de programadores de negócios e era uma linguagem de nível muito superior ao assembler. As bibliotecas de código (para evitar a necessidade de escrever o próprio código) são de antiguidade semelhante.

De vez em quando, surge algo que permite que os não programadores façam algo mais como o trabalho de programação. Havia os "idiomas de quarta geração" dos anos 80, planilhas sofisticadas como o Excel, geradores de relatórios e similares. O que eles fizeram de maneira uniforme, se bem-sucedidos, é remover parte da escória da programação e permitir que os programadores façam outras coisas mais interessantes.

Esse padrão não vai durar para sempre, mas vou precisar de algo mais do que argumentos e previsões teóricas para me convencer de que a programação está realmente indo ladeira abaixo.

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


7
+1 - "pegue uma especificação inexata e a transforme em algo preciso e útil".
Ocodo

+1, eu não estive neste jogo há tanto tempo quanto você, mas definitivamente ouvi o mesmo tipo de pergunta que essa pergunta foi declarada e re-declarada há 20 anos.
Carson63000

+1 para 4gl's, vim dizer exatamente isso. Tudo o que prometem, tão pouco entrega :)
Ian

"Esse padrão não vai durar para sempre" - por que não?
Ian Warburton

3

Os programadores de Assembly e FORTRAN provavelmente disseram o mesmo quando entraram em cena a programação estruturada e os intérpretes generalizados.

No final do dia, o software é uma criação destinada a automatizar algo que anteriormente havia sido feito à mão. Um departamento de contabilidade em uma corporação moderada já exigia dezenas de pessoas, agora todo esse trabalho pode ser realizado pelo trabalho de uma ou duas. Como resultado, as postagens de meta foram movidas e agora esperamos que esse padrão de capacidade extra seja fornecido por um contador.

A Pixar leva mais tempo para renderizar filmes do que nunca. Apesar do enorme aumento na velocidade da computação, os animadores exigiram cada vez mais complexidade e detalhes em suas cenas. A animação do calibre do Toy Story não é aceitável em 2010 como em 1995. Como suas ferramentas avançaram, também têm suas capacidades e, portanto, suas 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 precisará de programadores que usem essas novas ferramentas sofisticadas para resolvê-los. As postagens da meta serão movidas.


3

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

Sim, é, e DEVE ser

Estou aqui para projetar uma solução para problemas que outros não podem. Qualquer coisa no conjunto de ferramentas que me demore a resolver problemas para lidar com todos os pequenos detalhes de como implementar meu design é desperdício.

A única razão pela qual eu temeria recorrer a uma linguagem de nível superior ou a uma ferramenta mais simples e mais abstrata é que essas ferramentas geralmente fazem suposições que me atrapalham e exigem tempo para contornar as suposições para obter a implementação desejada.

Sempre há mais problemas a resolver do que bons solucionadores de problemas. Mesmo que toda a cadeia de desenvolvimento se tornasse tão simples, as crianças em idade pré-escolar poderiam usá-la, 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 de todos os casos extremos e what-ifs que você precisa considerar para criar uma boa solução.

Nosso trabalho é resolver os problemas melhor do que a maioria, a complexidade da cadeia de ferramentas não é muito relevante na visão geral, desde que ela se afaste e permita que você construa e construa algo de bom.


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 alguma outra maneira "simples"), toda a complexidade do software ainda precisará ser entendida e tratada. Por esse motivo, é importante que os empregadores tenham programadores que conhecem os produtos da empresa de dentro para fora para atualizá-los ou adicionar novos recursos. E pode demorar um pouco para os funcionários aprenderem um produto de software.


1

Não importa o que você possa automatizar ou retirar da prateleira, a maioria dos pacotes de software se enquadra em duas categorias:

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

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

Sempre haverá uma 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 a dados manualmente, em vez de usar um O / RM). Isso permite que os desenvolvedores agreguem mais valor aos negócios com menos esforço.


1

Não aceito seus argumentos:

  1. Não está demorando para implementar as melhores práticas

exceto aquilo.

  1. Usar o código de outras pessoas o máximo possível (código personalizado como responsabilidade)

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

  1. Usando linguagens de nível cada vez mais alto para melhorar a produtividade

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

  1. "Ferramentas" de desenvolvimento baseadas em GUI que simplificam bastante a "programação" e não exigem que as pessoas entendam o encanamento por trás do código

Se a ferramenta executar o trabalho: Use-a. Caso contrário: recuse-o. Se a promessa se mantiver, e as pessoas realmente não precisam entender o código - muito bem! Você parece dizer que esta é uma promessa que não se mantém?

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


O ponto é que, para ser eficaz, você precisa de menos habilidade. Não há nada de inerentemente ruim nas "ferramentas" de desenvolvimento baseadas em GUI. O que há de ruim neles é que o uso repetido reduz o nível de habilidade necessário para fazer o que fazemos. O mesmo vale para o código de outras pessoas: eventualmente, você começa a programar na plataforma do Google. Finalmente, linguagens de nível superior abstraem muitas sutilezas que, novamente, exigem habilidade. Nada disso é ruim do ponto de vista do empregador, do gerenciamento de projetos. Isso, no entanto, me faz questionar o futuro da profissão.
Q303

Tudo depende das suas necessidades. Quando não preciso de uma técnica de classificação específica para fins especificamente distribuídos, posso usar perfeitamente as bibliotecas com algum algoritmo de classificação rápida. Por que eu deveria ler antes de precisar? Talvez eu precise de tempo para aprender outra coisa - conhecimento de fontes, acesso a banco de dados, design de GUI ... - o nome dele. É bom ter habilidades, mas há muitas habilidades que você poderia ter. Às vezes, é certo dizer: YAGNI.
usuário desconhecido

1

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

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

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


0

As práticas de programação não apenas aumentam a produtividade e reduzem os custos de certos tipos de desenvolvimento (sua corrida para o fundo), mas também aumentam os recursos de aplicativos e as expectativas dos clientes (incentivando uma corrida ao topo). Testemunhe os bônus que Goole e Facebook estão pagando para obter os melhores tecnólogos.


0

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

Portanto, eu não sujaria os esforços de outras pessoas para compartilhar código 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, os hábitos e as maneiras desprovidos de humanismo do praticante individual.


-2

Se adotarmos as práticas de:

  • Não está demorando para implementar as melhores práticas
  • Usar o código de outras pessoas o máximo possível (código personalizado como responsabilidade)

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

Se adotarmos as práticas de:

  • Não está demorando para implementar as melhores práticas
  • Não usar o código de outras pessoas o máximo possível (código personalizado como responsabilidade)


1
@NoahRoberts: sua edição altera o significado do segundo marcador. Essa também não é uma resposta apropriada para a pergunta e deveria ter sido um comentário.
Adam Lear

@ Anna - isso não era uma edição, é claro. É por isso que não aparece como alterações na pergunta original. É uma resposta porque aborda uma premissa falha na pergunta.
Edward Strange

Qual é a premissa?
Q303

3
@NoahRoberts: É um pouco estranha, mas acredito que a lista seja consistente em seu significado - o q303 está usando "usar o código existente de outras pessoas em vez de escrever o código personalizado internamente" como um ponto de apoio em seu argumento.
Adam Lear

@ q303 - Aparentemente, usar o código de outras pessoas o máximo possível é uma má prática. É o que eu tiraria da sua lista de qualquer maneira.
Edward Strange
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.