Como posso lidar com a atitude de programação do culto à carga?

Tenho alguns estudantes de ciência da computação em um curso obrigatório de programação introdutória que veem uma linguagem de programação como um conjunto de feitiços mágicos, que devem ser lançados para obter algum efeito (em vez de vê-la como um meio flexível para expressar sua idéia de solução) .

Eles tendem a copiar e colar o código de atribuições anteriores, de aparência semelhante, sem considerar a essência do problema.

Existem alguns exercícios ou analogias para tornar esses alunos mais confiantes de que podem e devem entender a estrutura e o significado de cada pedaço de código que escrevem?

Você pode apresentar a eles uma série de exercícios, cada um baseado no anterior, enquanto adiciona algum elemento extra ou distorção ao problema ou investiga o problema de uma perspectiva diferente, o que revela uma fraqueza da solução anterior, exigindo uma abordagem nova e diferente . Isso os obriga a pensar, analisar, modificar e experimentar cada solução, em vez de apenas copiar e colar um pedaço de código pronto.

Outra possibilidade - embora não seja estritamente uma tarefa de programação - é pedir que eles calculem várias coisas. Por exemplo, quanta água flui através do delta do Mississippi por segundo? Tais perguntas não têm uma resposta definida, especialmente porque é preciso fazer certas suposições para chegar a um (s) valor (s) convincente (s). E - embora as respostas para muitas dessas "clássicas" possam ser pesquisadas no Google - você pode facilmente criar novas que ainda não foram encontradas em nenhum lugar da rede.

Exemplos para esses dois tipos de exercícios podem ser encontrados em, por exemplo, Programming Pearls, de Jon Bentley. O Programador Pragmático também tem alguns bons desafios.

Um terceiro tipo de tarefa seria apresentar a eles algum código com (um ou mais) erros nele, que eles devem encontrar e corrigir. Isso novamente os obriga a usar suas habilidades analíticas e raciocinar sobre como o programa está realmente funcionando.

Atualizar

Feedback de um comentário de Billy ONeal:

O problema com a "série de exercícios" é que os alunos que têm problemas com um exercício anterior são completamente ferrado nos exercícios restantes.

Você está certo, embora eu ache que isso é mais sobre o problema geral de definir a dificuldade do curso para o nível certo / agrupar alunos com o mesmo nível de habilidade. Além disso, pode-se organizar os alunos em grupos menores, onde eles são obrigados a discutir e debater sobre os problemas e soluções, e resolver os problemas juntos. Se alguém não conseguir, os outros podem ajudar (essa configuração também melhoraria as habilidades de trabalho em equipe). E se alguém tenta ser preguiçoso e deixar que os outros façam todo o trabalho, certamente é percebido pelo professor (que deveria estar andando por aí, supervisionando e orientando os alunos, não jogando WoW em seu laptop no canto ;-)

E também é possível ajustar os exercícios para acomodar alunos com diferentes níveis de habilidade. Iniciantes podem ir mais devagar, experientes mais rapidamente.

Você está lutando contra o equilíbrio entre os alunos quanto à necessidade de se preocupar com o assunto e a necessidade de obter notas . Muitos estudantes sentem que:

(Entenda errado || Experiência) == (Nota reprovada e & tempo de desperdício)

Assim que um aluno sente que seu tempo ou nota está em risco, mesmo para um assunto interessante, ele para de aprender e passa direto para "Não me importo, apenas dê ao professor a resposta certa". Seus alunos estão tentando cortar custos (ou assim pensam) , pensando o mínimo possível sobre o problema e apenas cortando e copiando e colando.

Aqui estão minhas sugestões sobre como lidar com isso:

1. Use o método Bob Ross: prove para eles que é possível e mais rápido começar de novo vs. copiar e colar. Crie novos programas diante dos olhos deles durante a aula - mostre a eles que a programação pode ser como pintar uma imagem.
2. Forneça tarefas que exijam criatividade . Por exemplo, peça a cada aluno que crie suas próprias estruturas de dados (quais são os objetos necessários para criar um zoológico, loja de animais, cidade, faculdade etc.) em papel para usar ao longo do curso. A tarefa 2 pode converter essas estruturas em classes ou objetos, etc. Basicamente, incentive-os a pensar abstratamente - recompense-os por serem criativos e, em seguida, recompense-os por transformar sua criatividade em um programa de computador.
3. Use a menor quantidade possível de sintaxe. Coisas padronizadas, como criar classes e sintaxe de linguagem, são tão comuns na introdução da programação que muitas vezes levam os alunos a pensar que toda a programação apenas sabe onde colocar chaves - eles não percebem que o que está no meio da chave aparelho é onde a criatividade flui . Escolha um idioma simples e forneça arquivos de amostra (como um arquivo de turma vazio) para os alunos que ainda desejam copiar e colar algo. Você pode gradualmente se tornar mais rigoroso quanto à sintaxe e às tarefas compiláveis ​​à medida que o curso avança.

Várias coisas que me vêm à mente:

• Dê a eles tarefas onde eles realmente precisam explicar o código que outra pessoa (você) escreveu. A compreensão do código anterior ou, mais especificamente, a falta dele é a maior causa e perigo da programação do culto à carga. Peça que eles usem comentários, linha por linha, se necessário, para explicar seu programa em inglês simples (ou em qualquer idioma humano que você usar).

• Somente depois que eles explicarem o código, peça para modificá-lo para fazer uma determinada alteração. Por exemplo, se você deu a eles uma função de classificação que classifica como descendente, peça que eles a classifiquem em ordem crescente. Ou algo mais exigente. Mas verifique se é algo que requer entendimento do código fornecido.

• Você pode, se quiser, colocar alguns ovos de páscoa em código. Uma linha ou duas que não faz nada de útil ou mesmo relacionado ao problema. Dê a eles uma dica de que essas linhas existem e concedam pontos extras a quem os remove.

• Então, e somente então, você poderá atribuir a eles uma tarefa para escrever um código sozinho. Nesse ponto, eles devem ter uma compreensão muito melhor do que realmente é o código. Eles podem até achar um pouco mais fácil fazer isso sozinhos.

A idéia básica é que a programação não é apenas escrever código, mas também lê-lo. O código de leitura também deve ser ensinado.

Olhe para isso de outra maneira. Esse fenômeno do culto à carga é o estágio inicial do Modelo Dreyfus de aquisição de habilidades . É assim que nós aprendemos. Quando aprendi a programar, tudo o que eu fazia era digitar páginas de código na parte de trás do Compute! revista. Repetição é a chave. Os bebês aprendem a conversar copiando os sons que ouvem seus pais. Tudo o que aprendemos é através da imitação. Nós apenas temos que ser ensinados a passar da imitação para o domínio.

O problema que você tem é que seus alunos não estão repetindo nada, eles estão copiando da Internet. Há algum benefício nisso, mas os ganhos são mínimos. O ato de digitar o código foi o que me levou a um lugar de entendimento. Comecei a ver padrões no que estava digitando e adquiri uma compreensão do que estava fazendo.

Uma opção é estruturar seu laboratório como um dojo de código. Peça aos alunos que se revezem emparelhando-se no mesmo problema. Escolha um problema que leve cerca de 10 a 15 minutos para resolver. Repita esse problema em alguns laboratórios e introduza uma nova reviravolta no problema à medida que a proficiência da turma aumenta. Talvez inicie o laboratório fazendo com que os alunos assistam a programar a solução e peça que eles a repitam. Alternando pares a cada iteração.

Para seus testes, use um código de kata, em que cada aluno trabalha com os problemas do semestre em frente ao resto da turma. Concentre-se não apenas na correção, mas na forma e na criatividade. Eu acho que isso forneceria uma compreensão mais profunda de como programar do que dar tarefas de levar para casa.

Eu lecionei aulas introdutórias no passado e, lembro-me de olhar para trás agora:

Alguns estudantes pensam que a programação é assim por diferentes razões. Lembro-me de uma vez um bom garoto que cultuou muito o que eu fiz:

Acreditando que não era um problema isolado, mas outros alunos da mesma classe poderiam ter um comportamento semelhante ou se aproximar do problema e não expressá-lo, eu estava sempre abordando a classe.

1. Foi gasto algum tempo para explicar algumas coisas, como o determinismo, o que significava que, no mesmo ambiente, com os mesmos dados e código, eles teriam os mesmos resultados (dissipar a "aleatoriedade"),

2. Como a solução de problemas depende das ações do aluno e não de mais nada, a atenção deve estar na solução do problema e na não encontrar o feitiço certo,

3. Eles estão em um ambiente educacional; portanto, os problemas são criados para oferecer uma experiência de aprendizado; o resultado é aprender a programar (ou, em alguns casos, como aulas para administradores de sistemas, como os programas funcionam, que é diferente) e não me dê uma solução. ("O mundo não precisa de outra calculadora, é um exercício"), para que seus problemas pudessem ser resolvidos com os materiais disponíveis (exemplo: notas fornecidas),

4. Eu acho que está no Código Completo: "Mesmo se você copiar e colar, o código é seu". Se alguém fez isso, não deve ser do tipo carga. Cada linha tinha que ser explicada para mim (individualmente) ou para outro aluno (o mesmo) ou para a classe.

Seus alunos começaram no 'nível de abstração' correto no início do curso? Por exemplo, uma lição de casa que as apresenta às principais estruturas de programação, como loops e condicionais, sem escrever uma única linha de código?

Quando iniciei a programação, nossa primeira tarefa foi chamada de ' Rick, o Robô '. Tínhamos um pedaço de papel com um mapa aéreo de uma cidade com pontos interessantes, como bancos, supermercados, etc ... Tínhamos um cara chamado 'Rick' e tivemos ações como 'dar um passo', 'olhar para a esquerda', 'olhe bem', 'atravesse a rua' e poderíamos usar coisas como 'repita' e 'se alguma coisa, então faça alguma coisa'. (Isso não é 100%, pois eu não consegui encontrar essa tarefa). A ideia era que Rick só pudesse usar o que lhe foi dado e ele teria que chegar a lugares diferentes no mapa.

Este foi um exercício divertido e algo que lhe introduziu o básico (que às vezes é mais difícil de entender para os novatos). Não existe uma boa resposta para esse problema (é um jogo) e não há soluções para copiar e colar. Algo assim também pode permitir que você brinque um pouco mais com a criatividade deles sem intimidá-los com o código.

Finalmente, a idéia é que você comece com o abstrato e avance para o concreto . Eles não podem copiar colar resumo. Eles precisam entender isso para resolver um problema.

O que você está pedindo para eles fazerem é demonstrar análise e síntese no domínio cognitivo da Taxonomia de Bloom , onde atualmente estão apenas demonstrando aplicação.

Infelizmente, é uma espécie de situação do tipo "leve o cavalo à água". A análise e a síntese também são muito difíceis de fazer quando você ainda está lutando com a compreensão. Sem a compreensão, as atividades de análise e síntese funcionarão mais como saídas de ervas daninhas do que nas atividades de aprendizado.

Minha opinião pessoal é que não há problema em esperar nada além de aplicação na introdução às aulas de programação. Essa é a primeira vez que os alunos são expostos a esses conceitos; portanto, é como ensinar as crianças a ler antes de pedir que escrevam um ensaio. Essas habilidades de ordem superior seguirão em suas aulas posteriores.

Você já pensou em fornecer a eles algum código para começar? Qualquer que seja o andaime simples que a tarefa precise, como uma função principal vazia (não sei qual idioma você está usando). Algo que compila e roda e não faz nada. Em seguida, eles podem começar a adicionar seu código com algum grau de confiança de que pelo menos parte dele funciona.

Isso é realmente muito comum no "mundo real"; muitos IDEs e outras ferramentas criam projetos vazios com bibliotecas / modelos / arquivos de configuração típicos já existentes.

Qualquer tipo de mentalidade de culto à carga (incluindo os próprios cultos de carga ) vem da falta de entendimento fundamental da tecnologia envolvida.

A programação do culto à carga não deve ser pensada como um hábito problemático, mas como um sintoma da confusão subjacente que o programador está enfrentando.

Mais importante, a suposição de que a falta de compreensão do aluno é simplesmente o resultado de sua falta de confiança é fundamentalmente equivocada e não aborda o problema subjacente.

Em vez disso, o estilo de programação copiar e colar do aluno deve ser uma bandeira vermelha, informando que esse aluno está impressionado com a complexidade do que ele espera fazer.

Ele está instintivamente usando o trabalho passado como andaime sobre o qual construir seu projeto atual, tentando compor uma solução usando problemas previamente resolvidos como blocos de construção. Todos fazemos isso em certa medida, mas a maioria de nós faz isso usando o conhecimento adquirido em trabalhos passados ​​como nossos blocos de construção. Em vez disso, o aluno está usando o trabalho em si, o que significa que ele não entende realmente os blocos com os quais está trabalhando. Ele decompôs o trabalho, tanto quanto seu entendimento permitir, e tratou grandes blocos de código como unidades atômicas, porque ele não entende como eles funcionam . Ele só sabe o que eles fazem.

Mude sua ideia de projetos!

No mundo da programação, raramente criamos novos projetos para cada solução que aparece. Na maioria das vezes, modificamos os antigos.

Mude sua idéia de um projeto de uma solução para cada tarefa para uma solução para o semestre inteiro. Cada atribuição baseia - se na atribuição anterior.

Exemplo

Projeto: Construir um sistema de elevador

• Tarefa 1: Imprimir o piso atual
• Tarefa 2: Crie as estruturas de dados para uma classe de elevador e imprima o piso com base no elevador
• Tarefa 3: Crie um código que "mova o elevador", imprimindo o chão. Aceitar entrada do teclado (> entrar no andar :)
• Tarefa 4: manipular vários elevadores

O ponto é que você desenvolve a atribuição anterior em vez de reciclar atribuições antigas para uma nova tarefa.

Considere usar uma linguagem de nível muito alto que exija um mínimo de código padrão.

Para mim, geralmente é o código padrão em grandes estruturas ou linguagens verbais que parecem feitiços mágicos e dificulta a compreensão.

Fui ensinado pessoalmente ML no meu curso de programação introdutória em CS. Por muitos anos, Lisp foi ensinado como introdução à programação no MIT. Ambos são excelentes opções. Alguns dos benefícios que eles têm são

• Intérprete interativo. Muito importante, pois isso permite a exploração.
• Muito sucinto. Sem clichê. Permite que os alunos se concentrem nas idéias que estão tentando expressar.
• Relativamente obscuro e estranho (pelo menos em comparação com Java, C ou outras linguagens convencionais com as quais os alunos já tenham alguma experiência). Sim, listo isso como profissional. Nivela o campo de jogo para os alunos, pois provavelmente ninguém terá experiência anterior. E torna menos provável que eles consigam apenas copiar e colar soluções para fazer a lição de casa na web.

Eu fiz algumas pesquisas sobre os problemas dos programadores iniciantes nos anos 80. Com base na minha experiência com programadores iniciantes hoje, pouco mudou. Os iniciantes não têm um modelo mental útil do que os computadores realmente fazem. Eles recorrem a encantamentos mágicos porque a própria máquina é mágica.

A programação requer dividir tarefas naturalmente simples em etapas não naturais. Como os novatos não lidam com uma granularidade tão fina na vida cotidiana, é difícil para eles descobrir quais devem ser os pequenos passos, especialmente quando não está claro quais pequenos passos a máquina disponibiliza. Mas, mesmo que consigam descobrir isso, são confrontados com a sintaxe rígida e a semântica limitada de uma linguagem de programação (uma linguagem não natural que se disfarça de uma quase natural) que controla a máquina misteriosa pelo controle remoto.

Como eles não conseguem estabelecer a conexão entre uma solução lógica para o problema e a funcionalidade da máquina, eles se concentram em satisfazer as demandas da linguagem. O primeiro objetivo é escrever algo - qualquer coisa - que seja compilado. O segundo é ajustar esse programa - seja lá o que ele realmente faz - para impedir que ele caia. Então, se eles tiverem tempo, energia e interesse, tentam fazer com que o programa produza resultados que se assemelhem ao que o problema exige. Ao longo do caminho, eles podem produzir acidentalmente código bem escrito.

Com toda a probabilidade, os novatos que aprendem a programar são bem-sucedidos porque inferiram um modelo mental útil do computador, não porque receberam um intencionalmente um e o internalizaram.

Você pode fazer perguntas sobre partes do código que exigem respostas por escrito? Como "O que esse código está fazendo?" "Por que o programador resolveu assim?" "Existe uma maneira melhor?", Etc?

Isso fará com que eles pensem sobre o problema, algo que eles podem fazer sem sequer tocar no código.

• Desafie-os a criar as menores soluções possíveis para o problema.
• Recompense as soluções mais sucintas com um incentivo.
• Crie exercícios que giram inteiramente em torno do código de refatoração
• Peça aos alunos que troquem as tarefas e as classifiquem para obter eficiência e limpeza do código, e use algumas das menos eficientes como exemplo, em um projetor.

Semelhante à idéia do JoelFans, é que eles façam as atribuições iniciais no papel usando um pseudo-código (idioma) que você criar. Você pode adicionar as estruturas como achar melhor e elas não se preocupam com a caixa mágica.

Eu vou assumir que, por 'culto à carga', você quer dizer que eles estão inserindo coisas que julgam necessárias, mas na verdade não fazem absolutamente nada para resolver o problema.

Se for esse o caso, você sempre pode adicionar algum fator à classificação baseada na concisão - deixar código desnecessário ou redundante em seu programa está solicitando problemas no futuro, pois isso pode ocorrer ou pode dificultar a manutenção.

Eles seriam julgados da mesma forma em um exercício de escrita em uma aula de inglês - ninguém quer coisas que disparam em uma tangente aleatória ou que geralmente apenas divagam sem chegar ao ponto.

Quando eu fazia uma aula de montagem, o professor nos dizia para cada exercício se ele quisesse que escrevêssemos o código para velocidade, tamanho ou uso de memória e ele marcaria se você não chegasse perto de otimizar o que ele pediu. para.

...

Se eles estão copiando e colando código de atribuições semelhantes anteriores, e na verdade é algo para resolver o novo problema ... bem, isso é apenas reutilização de código, a menos que eles tenham feito suposições ruins sobre a adequação do código para reutilização , Acho perfeitamente razoável que eles façam isso. (por exemplo, lendo de um arquivo, apoiando a entrada ... todas as partes modulares que podem ser reutilizadas. Se você não quiser que elas façam isso, você precisa diferenciar os exercícios.

Infelizmente, é assim que muitos cérebros das pessoas funcionam. Então, entenda que existem pessoas que você não pode 'curar' disso. Muitas pessoas são incapazes de trabalhar no nível de precisão mental necessário para a programação. Algumas pessoas simplesmente não são projetadas para isso. Não estou dizendo para desistir dos alunos - estou dizendo para não assumir que você está falhando, se nem todo mundo entende.

Sem saber mais sobre o contexto da turma, eu diria que se concentre mais com esses alunos problemáticos nas estruturas básicas - simples if / thens, loops, etc. Rotinas simples para imprimir números ímpares, todos os décimos, etc. Nada mais de 10 linhas de código cada. Se eles são "pensamentos mágicos", eles obviamente ainda não dominaram esses princípios. Peça que eles façam muitas rotinas simples diferentes até entenderem o que está acontecendo. Outra pessoa mencionou escrever o código no papel - acho que também seria uma ótima maneira de fazer essas rotinas simples.

Você também pode considerar que eles aprendam gráficos de fluxo. Para algumas pessoas, poder ver o fluxo de um algoritmo e, em seguida, como isso se conecta ao código, pode ser útil para conectar o código ao fluxo.

Idealmente, na primeira palestra, inicie-os com algo completamente abstrato: peça que eles (em grupo, com você como líder) escrevam as instruções sobre como fazer compras em uma lista e divida as instruções de alto nível progressivamente até que eles atinjam a iluminação.

Ajuda a dizer-lhes que essas instruções serão seguidas literalmente por um robô, que não sabe deduzir as coisas. Tem que ser uma atividade muito prática, onde você está encarregado de guiá-los.

Alistair Cockburn fala sobre o conceito de Shu-Ha-Ri e como ele se aplica à programação, http://alistair.cockburn.us/Shu+Ha+Ri . Eu acho que pode ser importante ter em mente onde seus alunos estão nesse continuum. Primeiro, isso ajudará a aliviar parte de sua frustração. Copiar / imitar é uma resposta muito natural e um modo aceito quando você começa a aprender alguma coisa. Segundo, pode ajudá-lo a ter algumas idéias de como avançar. Por exemplo, você pode considerar a escolha de um problema que possa ser resolvido de várias maneiras (loops x recursão, console x web / gui) e, em seguida, explicitamente faça com que primeiro resolvam de uma maneira e depois de outra maneira - bônus que eles podem aprender sobre reutilização de código legítimo, componenteização, criação de bibliotecas reutilizáveis ​​etc.

Outra maneira bem-sucedida que eu já vi usada é ter uma série de projetos que se desenvolvem entre si, disponibilizando uma versão de trabalho padrão a cada etapa, depois que as tarefas são entregues para impedir que as pessoas fiquem para trás. Cada etapa do processo deve apresentar algo novo. Garanto que isso pode ser mais fácil de ser feito em uma classe de design do que em uma classe de programação, mas ainda deve ser possível. Uma coisa boa sobre isso é que você explicitamente oferece a eles uma boa (espero) implementação para comparar com a deles em cada etapa. Exponha essa comparação como uma atribuição, ou seja, faça uma revisão de minicódigo de seu próprio código em relação ao seu esforço. Você pode querer fazer desta uma das várias opções de crédito extras.

Embora eu normalmente não seja grande em "comentários", convém tornar a documentação do código um dos itens de nota. Peça que eles produzam um documento "Teoria da operação" para cada projeto que descreva sua abordagem, como cada componente se encaixa e como juntos resolvem o problema. Normalmente, eu gostaria que o código fizesse muito disso por conta própria, mas os levaria a colocar seus limites de pensamento e colocá-los no papel.

Por fim, convém ser criativo e pedir que seus alunos revisem o código um do outro e façam uma avaliação. Coloque a pressão dos colegas para trabalhar para você. Permita que isso faça parte da nota ou crédito extra para o código (e documentos) com a classificação mais alta.

Apenas uma sugestão rápida. Sempre que tenho um problema de programação que precisa ser resolvido ou depurado, gosto de ver meu código e 'reproduzir computador', onde, na minha cabeça, acompanho as variáveis ​​e seus valores e o que espero que sejam quando cada linha é executada. . Portanto, se eu copiei algum código de algum lugar, a menos que ele seja completo por si só e eu apenas precise referenciá-lo, eu gosto de ir linha por linha para entender exatamente o que está acontecendo. Essencialmente jogando computador. O depurador do VBA basicamente facilita essa tarefa, mas fazer com que seus alunos o façam no papel pode fornecer a eles princípios básicos. O que essa linha realmente faz?

Ensinei programação introdutória no nível da faculdade. Foi um curso de pão com manteiga, todo o corpo docente fez, e acho que fizemos muito bem. Seguimos um texto comum e tínhamos exames comuns, mas cada um de nós tinha nosso próprio método de sala de aula que funcionava. Faz muito tempo desde então, mas ocasionalmente eu dou aulas de programação para crianças, e todo o cenário é o mesmo.

O jeito que faço é começar de baixo, o mais concreto possível. O que os alunos sabem é uma estrutura. Eles já têm muitos conceitos. Estou construindo outros conceitos sobre eles e estou eliminando conceitos que eles podem formar que são contraproducentes. Ao mesmo tempo, eu os faço aprender fazendo .

Eu construí um pequeno computador com um chip Intel 8008, alguns EPROM e alguns circuitos. Eu o havia programado para tocar um dueto quando o chip de E / S foi conectado a alguns alto-falantes. Eu explicaria como o pequeno programa funcionava, com um loop interno para contar um contador. Isso funcionaria como um atraso. Depois, alternava o bit de saída e o fazia novamente. Faria isso por um tempo e depois mudaria para outro atraso, dando outro tom e assim por diante. O chip de memória tinha um temporizador pequeno e, se eu colocasse um fio de capacitor em uma das entradas do timer, o programa seria executado muito lentamente . A turma podia ouvir os palestrantes clicando, clicando, clicando ... Eu queria que a turma entendesse que o computador estava fazendo coisas muito simples, um passo de cada vez. Então eu desengatava o fio do capacitor e a "música" surgia. (aplausos)

Então eu construí um simulador para um computador decimal muito simples, com 1000 locais de memória, cada um contendo um número decimal assinado de 4 dígitos. Tinha opcodes muito simples como "adicionar ao acumulador", "pular se negativo" e assim por diante. Eu gostaria que eles escrevessem pequenos programas nessa "linguagem de máquina", como adicionar dois números ou adicionar uma lista de números. Depois, eles podiam vê-lo funcionar dando um passo ou mantendo pressionada a tecla Enter para vê-lo correr "rápido".

O objetivo disso foi estabelecer o conceito de que os computadores podem executar apenas um número muito pequeno de operações básicas diferentes, e elas são executadas uma por vez. Isso é para contrariar a impressão que eles têm de que os computadores são complicados e de que fazem tudo ao mesmo tempo, e lê sua mente por uma pechincha.

A partir daí, passamos a programar em uma linguagem "real" (BASIC :), começando com programas muito simples, mas interessantes, trabalhando através de condicionais, loops, matrizes, arquivos, mesclagens etc. O objetivo era criar um conjunto de habilidades suficiente para que eles pudessem assumir um projeto de sua própria escolha, porque essa é a única coisa que torna a programação interessante - o uso no qual você pode colocá-la. Eu jogava algumas idéias para projetos, e então elas aceitavam a partir daí. Eu pedia idéias escritas e, em seguida, relatórios de progresso, para impedir que adiassem para o último minuto e depois entrassem em pânico. Eu acho que os projetos foram a melhor parte, porque eles estavam aprendendo por conta própria.

Essa base inicial em uma compreensão muito concreta do que os computadores fazem tornou muito mais fácil ensinar conceitos mais tarde, que de outra forma seriam verdadeiros obstáculos, como matrizes ou (em um curso posterior) indicadores. Temos a tendência de glorificar o conceito de "abstração" como algo maravilhoso, mas ele precisa ser construído sobre uma base concreta, não no ar.

Um programador autodidata, acredito que a animação seja o mais desafiador em termos de saber o que o código está fazendo. Quando um programa contém algoritmos e transformações matemáticas executando manipulações abstratas, a única maneira de entender o que a matemática está fazendo em um determinado momento (a menos que você seja um gênio) exige entender a execução do próprio código.

Corrija-me se minha idéia ingênua estiver incorreta. O que você quer fazer é notimpedir que seus alunos usem "padrões de design", mas encontrar uma maneira de garantir que eles entendam o que são CnPs? Em seguida, desafie seus alunos a manipular uma animação. Para ajustar a saída em uma animação, é necessário entender o que está acontecendo em cada etapa. Para sua preocupação declarada, imagino que um projeto de animação bem concebido se manifeste de maneiras óbvias quando um aluno "entender" - quando eles realizarem uma transformação que você não esperava ou ajustar algumas variáveis ​​relacionadas e interdependentes.

Sem conhecer os limites e objetivos pedagógicos em que você trabalha, não posso dizer que a animação é a resposta completa. Todo um currículo de animações fora da profissão de animação é, devo arriscar adivinhar, fora de questão. Alguns projetos podem resultar em algo artístico e maravilhoso, o que não é ruim.

Em outra nota, li um artigo de jornal (sim, jornal!) Sobre uma competição de Olimpíadas de Codificação no nível do ensino médio - wot-wot - para programadores pré-universitários. A descrição de seus desafios foi a articulação mais clara da codificação pura que me lembro de ter lido. Os concorrentes são julgados entre si e pelos padrões de boas práticas. Para essas competições, os alunos devem planejar sua solução e codificar manualmente o "padrão de design" elementar que o problema exige para terminar dentro de prazos. Portanto, a solução para sua preocupação com a programação do CnP é testar se os alunos podem escrever os mesmos "blocos de código" que são o CnP'n!

Tenho certeza que foi no NY Times. Uma pesquisa rápida não a encontrou. Um exemplo semelhante é o Concurso Internacional de Programação Colegiada da ACM. Este concurso enfatiza a programação rápida: "A programação extremamente rápida na competição por equipes é uma habilidade decididamente peculiar, e não exatamente uma que muitos candidatos a emprego colocariam no topo de um currículo". Portanto, eu recomendaria que a abstração de problemas do mundo real seja a resposta.

Além disso,

HP Code Wars

Ensine a classe usando uma linguagem de programação tecnicamente boa, mas tão obscura que não será possível encontrar nenhum código existente para copiar.

Você também pode tratá-los da maneira mais difícil.

Encontre uma maneira de tornar uma cópia-pasta prejudicial para eles. Não tenho um exemplo preciso, mas se você criar um primeiro exercício cuja solução, se colada em um segundo exercício de aparência semelhante, traga aos alunos do culto de carga um bug muito longo e doloroso de "instabilidade instável" ou "corrupção silenciosa de dados". Enquanto isso, um pensamento de "não-culto à carga" de 2 minutos traria uma solução óbvia até para o pior aluno (se ele não tivesse visto a primeira solução de exercícios). Então, talvez exista alguma possibilidade de eles aprenderem a lição e pensar duas vezes antes de copiar o código de colagem no terceiro exercício.

Duvido que esse comportamento seja devido à crença de que os programas são feitiços mágicos - mais provavelmente é preguiça e falta de motivação.

Então, acho que seu trabalho como professor é motivar seus alunos - nenhum aluno genuinamente motivado irá recortar e colar uma solução (isso é apenas para programadores que trabalham com prazos e resultados finais para cumprir ...)

Ensine sub-rotinas. Peça que eles pegem o código que estão pegando das tarefas anteriores e o transformem em uma sub-rotina. Ensine-os sobre a documentação de funções para ajudá-los a entender o que a sub-rotina está realmente fazendo.

Faça com que eles façam a tarefa à sua frente na sala de aula sem acesso à Internet (peça à escola que a interrompa, não permita o uso do telefone também durante a aula). Pelo menos faça isso para testes. Não há nenhuma razão para eles estarem usando a Internet para experiências básicas de programação. O livro deve ser um recurso suficiente para exercícios introdutórios. Permita o uso da Internet quando estiver em uma aula avançada e eles já aprenderem a pensar.

Nunca lhes dê tarefas com o mesmo som.

Ou, mais louco, aprendê-los TDD desde o início. Empurra para escrever (não copiar, escrever) um monte de código (ou seja, testes) que realmente ajuda a formular o problema que está sendo resolvido.

Algo que eu achei muito útil para as pessoas da minha turma é escrever um pequeno projeto sobre elas, sobre um assunto que elas possam escolher.

Quando comecei a programar, era difícil para mim também e copiei bastante nas aulas. Então, em casa, comecei a fazer joguinhos, pois queria me tornar um programador de jogos e achei muito mais fácil fazê-los. Mesmo sendo muito mais difíceis do que as coisas que vimos na aula. Só porque me interessou.

Algumas outras pessoas da minha turma passaram de 40-50% nos exames para 90-100%, porque fizeram exatamente a mesma coisa.

Quando eu estava em um curso introdutório de programação, o instrutor exigia que todos escrevessem um algoritmo em inglês, imprimissem e entregassem antes de começarmos a escrever o código. Então teríamos que colocar muitos comentários, como Criar variáveis, Obter entrada do usuário, Executar cálculos, Imprimir resultados, etc. Fui encaixado algumas vezes por não ter comentários suficientes quando achava que havia muitos, então comecei a adicionar Mais. Isso me forçou a pensar no que estava fazendo, escrever as soluções e continuar traduzindo entre inglês e Java.