“Metade de tudo o que você sabe ficará obsoleto em 18 a 24 meses” = (Verdadeiro ou Falso?) [Fechado]

Simplesmente deparei com isso e me pergunto se alguém tem uma maneira de provar ou refutar esta declaração:

Algo a ter em mente ... qual é a meia-vida do conhecimento em alta tecnologia? Ele acompanha a Lei de Moore: metade de tudo que você sabe ficará obsoleta em 18 a 24 meses.

FONTE: Em resposta de Craig Trader a esta pergunta " Qual foi a coisa mais eficaz que você fez para melhorar suas habilidades de programação? "

Esta declaração se aplica apenas a tecnologias efêmeras, que você só deve aprender conforme necessário. Dito isto, você aprenderá muitos deles ao longo de sua carreira.

Os princípios e técnicas fundamentais de programação são eternos.

Absurdo

Pessoas que dizem coisas assim estão apenas tentando ser sensacionalistas, ou então estão aprendendo as coisas erradas.

O melhor (pior?) Teste que consigo pensar é pensar um ano atrás. Quanto do conhecimento de programação que você usa todos os dias foi aprendido nos 18 - 24 meses anteriores? Além disso, quanto foi inventado nos 18-24 meses anteriores? O princípio parece altamente suspeito para mim, pois a maior parte do conhecimento técnico e de programação que uso diariamente foi adquirida em 5 a 10 anos.

Agora, se você está desenvolvendo algo como uma plataforma de telefonia móvel, talvez seja um jogo diferente.

Na minha experiência, há uma enorme desconexão entre a imagem da mídia / público de qual tecnologia é a Nova Nova Coisa e o que realmente está sendo usado no mundo real por aí.

Pegue algo como Visual C ++ / MFC no espaço de aplicativos da área de trabalho. Embora possa parecer antigo e desatualizado, e provavelmente não algo que um novo programador deva estar aprendendo agora para o desenvolvimento de desktops, ainda existem muitos projetos e trabalhos do mundo real escritos nele que estão sendo mantidos - e provavelmente será mantido nos próximos anos e décadas. Eu daria o COBOL como exemplo, mas isso estaria falando teoricamente - eu realmente conheço o exemplo VC ++ / MFC muito bem pessoalmente.

Essencialmente, não é que as tecnologias se tornem inúteis e não utilizadas quando se tornam "obsoletas", é mais que elas não são mais vistas como a maneira mais atualizada de fazer as coisas e iniciar novos projetos. Mas o descomissionamento de grandes sistemas de software do mundo real, que não estão quebrados e não precisam de correção, acontece muito mais lentamente. Muitos dos projetos Visual C ++ / MFC em que trabalhei (que começaram no início dos anos 90) ainda estão muito vivos e empregam muitos programadores (tanto em manutenção quanto em novo desenvolvimento) e parecem não estar indo a lugar algum em breve. Na verdade, tenho certeza de que a maioria das que ainda estou pensando ainda estará em 2020 e mais.

Claro, isso nem é o principal problema. A questão principal é que muitos dos conceitos são semelhantes ou relacionados, e você não está "começando do zero" ao aprender alguma nova tecnologia. Por exemplo: depois de entender as linguagens de marcação e o que elas tratam, é muito fácil aprender novas. Portanto, não importa muito que JSON seja a novidade e tudo que você usou por anos é XML. É apenas uma questão de aprender nova sintaxe - em vez de ser um não programador que não sabe nada sobre o que as linguagens de marcação são, ou os conceitos internos por trás dos dados que estão representando etc.

TL; DR: 1) Existe muita tecnologia "obsoleta" em uso, mas como essa não é a coisa nova e sexy, você não ouve muito sobre isso - mas está longe de ser inútil para os empregados com ela . 2) Os conceitos de programação são construídos um sobre o outro e evoluem. Poucas coisas são realmente algo que você precisa aprender completamente do zero e esquecer o antigo.

Tudo depende do que você focar em aprender, memorizar e geralmente encher seu cérebro. Os detalhes podem se tornar obsoletos rapidamente, mas os princípios devem durar muito mais tempo.

Exemplos de coisas nas quais estive profundamente envolvido recentemente:

• Sintaxe genérica Java vs. contêineres digitados
• Tipos de dados MySQL, limites de armazenamento, etc. vs. princípios de escalabilidade do banco de dados
• Camada leve de abstração de banco de dados que ajudei a criar vs. princípios de rigidez / flexibilidade de abstração de banco de dados

As coisas que aprendi em negrito durarão muito mais tempo do que as do lado esquerdo. Se você deseja evitar as armadilhas da obsolescência na programação, concentre-se nos princípios .

Robert Harvey acertou em cheio , mas depois de pensar nisso, sou obrigado a jogar concisão ao vento e responder.

Tenho que adicionar um aviso de isenção de responsabilidade, não fui ao Perl On Rails no momento em que foi anunciado. Tive a sensação de que funcionava bem para o uso muito localizado para o qual foi projetado e anotei-o para referência futura.

Eu também não sucumbi a mais de 50 permutações para a biblioteca C padrão ao longo das últimas duas décadas, gostaria de poder vincular a elas, mas elas parecem agora ser existencialmente desafiadas.

Insira um longo discurso aqui sobre acreditar em tudo que você lê ou ouve.

Quando algo novo aparecer, pegue-o e dê uma olhada. Se você disser 'ick', solte-o. Se você disser 'uau', melhore. Se você não pode considerar tal decisão, escolha o cérebro das pessoas que podem.

Tudo juiz no mérito técnico sozinho . Vale o seu tempo significa que você economiza tempo e obtém os polegares da maioria de seus colegas.

Agora, abordarei sua pergunta diretamente:

Metade de tudo que você sabe ficará obsoleta em 18 a 24 meses, verdadeiro ou falso?

Você precisará nos informar em 18 a 24 meses. As empresas pagam quantias substanciais para que as pessoas falem sobre o quão bom é o seu produto. Temos que percorrer não apenas empresas iniciantes, mas gigantes estabelecidos que desembolsam quantias consideráveis ​​de dinheiro para:

• Os blogueiros respeitados [sic] regurgitam um discurso de vendas para seus leitores
• Envie equipamentos gratuitos de marca caros para obter posicionamento da marca, onde eles podem ser notados através de se gabar ou usar
• Pague às pessoas para garantir que você veja uma 'solução de trabalho' no top 10 do Google ao pesquisar um problema
• Pague pelos 'prêmios' dos sites dos dez principais diretórios e finja que eles são oficiais
• Uma infinidade de outros meios para convencer as pessoas a parar de pensar e apenas seguir a multidão

Você pode, é claro, formar suas próprias decisões com base na experiência anterior e em suas tentativas com algo novo. Ao fazer isso, evite os empregadores que têm gerentes que distribuem mandamentos com base em seu leitor de RSS.

No entanto, tenho essa nova e incrível biblioteca de construção de ponte que é inteligente o suficiente para alternar entre Brooklyn e Londres com base no seu local. Vai ser enorme, você quer entrar no térreo?

Minha resposta é de fato intencionalmente sardônica e talvez anti-booleana, mas realmente? Para fins de tratamento de exceções, minha resposta é um falso retumbante .

Se você acha que algo é tecnicamente sólido - aceite-o, caso contrário, é como sempre. C é meu idioma principal, funciona tão bem quanto quase duas décadas atrás, enquanto eu recebo o pagamento duas vezes mais do que quase duas décadas atrás.

Admiro sua forma concisa e citações, mas isso parece ser um experimento violador .

Bem feito :)

Depende do que você gasta seu tempo aprendendo. Eu aprendi a programação Bourne shell e C em 1980. Eu ainda uso todos os dias. Por outro lado, o tempo que passei aprendendo as estruturas de menus do Compuserve é uma perda completa, e não foi realmente muito útil, mesmo na época. Depois, existem coisas como pinagem de cabo RS-232 e protocolos seriais: hoje inútil, mas essencial por cerca de dez anos da minha vida. Escolha as tecnologias que você dedica muito tempo com cuidado.

O princípio é verdadeiro. O valor real é - que eu saiba - muito maior.

Lembro-me de uma apresentação do Pragmatic Programmer em que eles disseram cerca de sete anos, mas não posso localizá-la agora, portanto o valor pode ser um pouco diferente.

Imagine como as tecnologias mudaram: há quinze anos, a web era totalmente nova e todos tentamos escrever páginas da web - talvez até com tabelas - e um gif animado. Há sete anos, o AJAX decolou. Hoje, algumas pessoas escrevem jogos do tipo Doom para celulares.

Sua melhor aposta é aprender coisas gerais que podem ser aplicáveis ​​com a próxima tecnologia que aparece, em vez de dizer "Começa! Só conheço o Visual Basic!" (ou o equivalente em 15 anos).

Eu não acho que seja preciso.

Era uma vez mais próximo da verdade - há muito tempo, você tinha pouca escolha a não ser programar em um nível relativamente baixo de abstração, o que significava conhecer um grande número de detalhes que não eram mais relevantes em uma nova plataforma.

Com o tempo, porém, mais e mais programação é feita em níveis cada vez mais altos de abstração. Um nível mais alto de abstração se traduz mais ou menos diretamente em menos preocupação com detalhes que provavelmente mudarão e se tornarão obsoletos rapidamente.

Obviamente, existem pessoas que trabalham em coisas como drivers de dispositivo ou pequenos sistemas embarcados que ainda precisam trabalhar com um baixo nível de abstração. Fora de áreas como essa, no entanto, há relativamente pouca desculpa para essas coisas. Sim, um monte de gente fazer aprender um monte de trivia que nunca precisa, mas se você está realmente usando tal material em seu código muito, as chances são muito boas que você simplesmente não está fazendo muito boas decisões. A maioria dessas coisas pode (e mais importante, deve) geralmente ser evitada.

Possivelmente verdade, possivelmente não; no entanto, mesmo que as coisas reais aprendidas se tornem obsoletas logo após aprendê-las, os conceitos e idéias por trás delas poderão ser úteis por muito mais tempo.

Se esse fosse o caso, apenas 5,39x10 ^-6 do Mês do Homem Mítico seriam relevantes hoje. No momento, existem muito poucos princípios-chave que Fred Brooks detalha que datou significativamente ou provou ser fundamentalmente falso.

Grande parte do seu conhecimento permanecerá relevante durante o teste do tempo (embora possa precisar de alguma atualização ao longo do tempo), fundamentos especiais, como estruturas de dados etc.

Obviamente, se você conhece a linguagem de programação X e Y, aprender a linguagem Z será mais fácil do que se você não conhecesse X ou Y, para poder usar seu conhecimento anterior para adaptar novos conhecimentos.

Também vale a pena mencionar que muitas habilidades que eram relevantes décadas atrás ainda são relevantes hoje, mesmo tecnologias específicas, como C (início de 1970, ainda relevante hoje).

É possível que metade do que você saiba fique obsoleta ao longo de algum tempo, e provavelmente mais que apenas metade, mas a cada 18 a 24 meses pareça meio extremo.

Fatos isolados não têm grande relevância. Você os pega, entende, aplica-os apenas no momento.

Mas isso ensina o processo de lidar com fatos ou pelo menos lidar com um certo subconjunto de fatos. Aprendi muita matemática na escola que na verdade nunca usei. Ainda aprendi e treinei o pensamento matemático.

Trabalhei como programador web com Ruby on Rails. E, embora eu não escreva sites no momento, isso influenciou fortemente meu código de pensamento e me transformou em um codificador C ++ melhor. (Use mais STL, por exemplo).

O mesmo vale para o aprendizado da raquete. Eu nunca escrevi nenhum programa grande, mas isso me deu um novo ponto de vista para aplicar em algum espaço problemático.

É só treinar sua mente ...

Eu acho que você pode refutar facilmente a afirmação brincando com o objeto que você está 'na metade de tudo o que você sabe'.

Existe uma certa distribuição de conhecimento, alguns dos quais se tornarão obsoletos (independentemente da taxa). Portanto, se uma determinada pessoa contiver apenas conhecimento da metade desse espectro que permanecerá após 18 a 24 meses, eles quebrarão a afirmação.

Aqui está uma versão melhor da frase: metade de tudo que você aprendeu hoje (ou esta semana, ou este mês ou este ano) ficará obsoleto em um ou dois anos. Isso é verdade - você aprende como fazer algo na versão 5 de uma ferramenta e, quando o 6 é lançado, faz isso automaticamente ou você aprende como fazer algo em um idioma que não entende, para nunca mais usá-lo. Mas a outra metade do que você aprende todos os dias fica com você e cresce, e é o que torna um desenvolvedor com 20 anos de experiência melhor do que um desenvolvedor com dois anos de experiência.

Há uma pepita de verdade ou relevância aqui, mas acho que é apresentada de maneira imprecisa.

Uma maneira melhor de apresentar isso seria

Quanto do conhecimento que você usa hoje você tinha 18 a 24 meses atrás?

ou

Dentro de 18 a 24 meses, quanto do conhecimento que você aplicará já sabe? Quanto você precisará aprender hoje para concluir essas tarefas?

Pode depender de qual campo você está trabalhando, mas sei que estou constantemente trabalhando em novas tecnologias. Todo projeto parece ter uma enorme quantidade de coisas novas que eu preciso aprender - novas estruturas e padrões, novas abordagens para problemas levemente variados ou apenas novas ferramentas que são (supostamente!) Melhores do que as que usamos anteriormente.

Se a cada seis meses o projeto tiver apenas 12,5% de novos conhecimentos necessários, em dois anos, 50% do conhecimento usado será 'novo'.

Dito isto, isso não é muito significativo ou preciso.

• O material 'velho' não é obsoleto.
• O material 'novo' tem uma enorme sobreposição com o material antigo
• Os princípios são geralmente transferíveis

Oh Deus, essa maravilhosa resposta do senso comum está acima. Bom trabalho.

Dito de forma simples, se é uma moda ou tendência quente, se você é um bom programador, lerá sobre isso e depois voltará ao que normalmente faz ou trabalha.

A menos que haja algo vital para o que você faça, ou novas práticas que façam sentido para você.

Só porque algo é novo, um tanto novo ou um pouco antigo, não o torna a solução de uso obrigatório para nada.

Eu tenho uma frase simples, essa capa é tudo isso.

"Se funcionar, use-o"

Isso significa que, se essa nova tecnologia for incrivelmente legal, mas não algo que torne seu trabalho mais produtivo, com qualidade mais alta ou menos propenso a erros, ou resolva problemas técnicos, como soluções móveis ou cliente / servidor. Do que é melhor ler e depois ignorá-lo, até que você tenha um uso prático.

Vi e li mais pessoas perdendo tempo, tentando encontrar a novidade nova e depois usá-la. O que geralmente acaba sendo um total desperdício de tempo e dinheiro.

É importante sempre aprender, praticar e melhorar seu ofício e habilidades.

No entanto, você deve aprender o que é útil ou o que lhe dá perspectivas diferentes para resolver os problemas que você normalmente tem.

Mas, além disso, deve voltar ao básico de ser um programador incrível.

1. http://www.joelonsoftware.com/articles/fog0000000043.html
2. Planejamento
3. Processo de gerenciamento de projetos - para garantir que nenhum código seja iniciado antes da elaboração de um plano claro e aprovado pelas pessoas que solicitaram seu trabalho.
4. Melhore a legibilidade do seu código - porque todos trabalhamos no código de outras pessoas
5. Organize-se, seja eficiente

Eu pratico as boas práticas do senso comum, que todos aprendemos com nossas experiências. Não perca tempo com coisas legais.

Porque honestamente, legal não é legal.

Eu ouvi essa frase atribuída aos campos de engenharia, não à programação. Mais especificamente, ouvi dizer: "Quando você receber um diploma de bacharel em engenharia, seus dois primeiros anos de estudo serão baseados em tecnologia antiga". (Ou algo nesse sentido.)

Eu não acho que isso se aplica à programação. A única maneira possível de ver isso relacionado é quando os recursos são preteridos ou removidos de uma linguagem de programação / biblioteca / qualquer coisa.

A plataforma de tecnologia média permanece em algum lugar entre 10 e 25 anos, então isso me parece bastante improvável, mesmo se você desconsiderar completamente o fato de que o conhecimento de padrões persiste por meio das tecnologias. Se você estiver em qualquer tipo de plataforma principal, pode contar com essa pilha sendo popular por PELO MENOS 5 ou 6 anos antes mesmo de começar a desaparecer. Conheço programadores que codificam RPG há 30 anos usando ferramentas quase idênticas de hardware e software.