¿Cómo puedo lidiar con la actitud de programación de culto de carga?

Tengo algunos estudiantes de informática en un curso obligatorio de programación introductoria que ven un lenguaje de programación como un conjunto de hechizos mágicos, que deben lanzarse para lograr algún efecto (en lugar de verlo como un medio flexible para expresar su idea de solución) .

Tienden a copiar y pegar código de tareas anteriores de aspecto similar sin tener en cuenta la esencia del problema.

¿Existen algunos ejercicios o analogías para hacer que estos estudiantes estén más seguros de que pueden y deben entender la estructura y el significado de cada código que escriben?

Puede presentarles una serie de ejercicios, cada uno de los cuales se basa en el anterior al tiempo que agrega un elemento adicional o un giro al problema, o investiga el problema desde una perspectiva diferente, lo que revela una debilidad de la solución anterior, que requiere un enfoque nuevo y diferente . Esto los obliga a pensar, analizar, modificar y experimentar con cada solución, en lugar de simplemente copiar y pegar un código listo para usar.

Otra posibilidad, aunque no es estrictamente una tarea de programación, es pedirles que estimen varias cosas. Por ejemplo, ¿cuánta agua fluye a través del delta del Mississippi por segundo? Estas preguntas no tienen una respuesta establecida, especialmente porque uno necesita hacer ciertas suposiciones para llegar a un (s) valor (es) convincente (s). Y, aunque las respuestas a muchos de estos "clásicos" pueden buscarse en Google, puede inventar fácilmente otras nuevas que (todavía) no se encuentran en ninguna parte de la red.

Se pueden encontrar ejemplos de estos dos tipos de ejercicios en, por ejemplo, Programming Pearls de Jon Bentley. También The Pragmatic Programmer tiene algunos buenos desafíos.

Un tercer tipo de tarea sería presentarles algún fragmento de código con (uno o más) errores, que deben encontrar y corregir. Esto nuevamente los obliga a usar sus habilidades analíticas y razonar sobre cómo funciona realmente el programa.

Actualizar

Comentarios de un comentario de Billy ONeal:

El problema con la "serie de ejercicios" es que los estudiantes que tienen un problema con un ejercicio anterior están completamente atornillados para los ejercicios restantes.

Tiene razón, aunque creo que se trata más del problema general de establecer la dificultad del curso en el nivel correcto / agrupar a los estudiantes de un nivel de habilidad similar. Además, se puede organizar a los estudiantes en grupos más pequeños donde se les exige que discutan y debatan sobre los problemas y las soluciones, y que resuelvan los problemas juntos. Si alguien no lo entiende, los demás pueden ayudar (esta configuración también mejoraría las habilidades de trabajo en equipo). Y si alguien trata de ser flojo y deja que los demás hagan todo el trabajo, seguramente lo notará el maestro (quien se supone que debe estar caminando, supervisando y asesorando a los estudiantes, no jugando WoW en su computadora portátil en la esquina ;-)

Y también se pueden ajustar los ejercicios para acomodar a los estudiantes con diferentes niveles de habilidad. Los principiantes pueden ir más despacio, los más experimentados más rápido.

Usted está luchando contra el acto de equilibrio de los estudiantes de su necesidad de preocuparse por su materia y su necesidad de obtener calificaciones aprobatorias . Muchos estudiantes sienten que:

(Hazlo mal || Experimento) == (Calificación reprobatoria y & Tiempo de desperdicio)

Tan pronto como un estudiante siente que su tiempo o grado está en riesgo, incluso para una materia interesante, deja de aprender y pasa directamente a "No me importa, solo dale al maestro la respuesta correcta". Sus estudiantes están tratando de cortar esquinas (o eso piensan) al pensar lo menos posible sobre el problema y simplemente hackearlo copiando y pegando.

Aquí están mis sugerencias sobre cómo lidiar con esto:

1. Use el método Bob Ross: demuéstreles que es posible y más rápido comenzar de nuevo frente a copiar y pegar. Cree nuevos programas ante sus ojos durante la clase: muéstreles realmente que la programación puede ser como pintar un cuadro.
2. Proporcione tareas que requieran creatividad . Por ejemplo, haga que cada alumno cree sus propias estructuras de datos (cuáles son los objetos necesarios para crear un zoológico, una tienda de mascotas, una ciudad, una universidad, etc.) en papel para usar durante todo el curso. La tarea # 2 puede convertir esas estructuras en clases u objetos, etc. Básicamente, incitarlos a pensar de manera abstracta: recompensarlos por ser creativos y luego recompensarlos por convertir su creatividad en un programa de computadora.
3. Use la menor cantidad de sintaxis posible. Las cosas repetitivas, como la creación de clases y la sintaxis del lenguaje, son tan frecuentes en la introducción de la programación que a menudo engañan a los estudiantes para que piensen que toda la programación es solo saber dónde colocar llaves, no se dan cuenta de lo que está en medio de la curva. llaves es donde fluye la creatividad . Elija un idioma simple y proporcione archivos de muestra (como un archivo de clase vacío) para los estudiantes que aún quieren copiar y pegar algo. Poco a poco puede volverse más estricto sobre la sintaxis y las tareas compilables a medida que avanza el curso.

Varias cosas que me vienen a la mente:

• Dales tareas donde realmente tengan que explicar el código que alguien más (tú) escribió. La comprensión del código anterior o, más específicamente, la falta de él es la causa y el peligro más importantes de la programación de culto de carga. Pídales que usen comentarios, línea por línea si es necesario, para explicar su programa en inglés simple (o cualquier idioma humano que use).

• Solo después de que hayan explicado el código, pídales que lo modifiquen para hacer un cierto cambio. Por ejemplo, si les asignó una función de ordenación que desciende, pídales que la ordenen de manera ascendente. O algo más exigente. Pero asegúrese de que sea algo que requiera la comprensión del código dado.

• Puede, si lo desea, poner algunos huevos de pascua en el código. Una o dos líneas que no hacen nada útil o que incluso están relacionadas con el problema. Déles una pista de que tales líneas existen y otorgue puntos extra a quienes las eliminen.

• Entonces, y solo entonces, puede asignarles una tarea para escribir un código desde cero por su cuenta. En este punto, deberían tener una mejor comprensión de lo que realmente es el código. Puede que incluso les resulte un poco más fácil hacerlo ellos mismos.

La idea básica es que la programación no es solo escribir código, sino también leerlo. También se debe enseñar el código de lectura.

Míralo de otra manera. Este fenómeno de culto a la carga es la etapa de novato del modelo Dreyfus de adquisición de habilidades . Así es como aprendemos. Cuando aprendí a programar, todo lo que estaba haciendo era escribir páginas de código desde la parte posterior de Compute! revista. La repetición es la clave. Los bebés aprenden a hablar copiando los sonidos que escuchan hacer a sus padres. Todo lo que aprendemos es a través de la imitación. Solo tenemos que enseñarnos cómo pasar de la imitación al dominio.

El problema que tiene es que sus alumnos no repiten nada, lo están copiando de Internet. Hay algún beneficio en eso, pero las ganancias son mínimas. El acto de escribir el código es lo que me llevó a un lugar de comprensión. Comencé a ver patrones en lo que estaba escribiendo y entendí lo que estaba haciendo.

Una opción es estructurar su laboratorio como un dojo de código. Haga que los estudiantes se turnen para emparejarse entre sí en el mismo problema. Elija un problema que tarde entre 10 y 15 minutos en resolverse. Repita ese problema en algunos laboratorios e introduzca un nuevo giro al problema a medida que crece la competencia de la clase. Quizás comience el laboratorio haciendo que los estudiantes lo vean programar la solución y que la repitan. Cambiar pares con cada iteración.

Para sus exámenes, tenga un código kata donde cada alumno resuelva los problemas del semestre frente al resto de la clase. Centrarse no solo en la corrección, sino también en la forma y la creatividad. Creo que esto proporcionaría una comprensión más profunda de cómo programar que dar tareas para llevar a casa.

He enseñado clases introductorias en el pasado y, según recuerdo, ahora miro hacia atrás:

Algunos estudiantes piensan que la programación es así por diferentes razones. Recuerdo una vez que un buen chico que cargaba mucho lo que hice:

Creyendo que no era un problema aislado, pero que otros estudiantes en la misma clase podrían tener un comportamiento similar o acercarse al problema y no expresarlo, siempre me dirigía a la clase.

1. Se dedicó algún tiempo a explicar algunas cosas, como el determinismo, lo que significaba para ellos que en el mismo entorno con los mismos datos y código, tendrían los mismos resultados (disipar la "aleatoriedad"),

2. Dado que la resolución de problemas depende de las acciones del estudiante y no de otra cosa, la atención debe estar en resolver el problema y no encontrar el hechizo correcto,

3. Se encuentran en un entorno educativo, por lo que los problemas están diseñados para ofrecer una experiencia de aprendizaje, el resultado es aprender a programar (o, en algunos casos, como clases para administradores de sistemas, cómo funcionan los programas, que es diferente) y no dame una solución ("El mundo no necesita otra calculadora, es un ejercicio"), por lo que sus problemas podrían resolverse con los materiales disponibles (ejemplo: notas proporcionadas),

4. Creo que está en Code Complete: "Incluso si copia y pega, el código es suyo". Si alguien lo hizo, no debería ser de estilo de carga. Cada línea tenía que ser explicada a mí (individualmente) oa otro estudiante (igual) o a la clase.

¿ Comenzaron sus alumnos en el "nivel de abstracción" correcto al comienzo del curso? Por ejemplo, ¿una tarea que los presente a las principales estructuras de programación como bucles y condicionales sin escribir una sola línea de código?

Cuando introduje la programación, nuestra primera tarea se llamó ' Rick the Robot '. Teníamos un pedazo de papel con un mapa aéreo de una ciudad con puntos interesantes, como bancos, supermercados, etc. Teníamos un tipo llamado 'Rick' y teníamos acciones como 'dar un paso', 'mirar a la izquierda', 'mirar a la derecha', 'cruzar la calle' y podríamos usar cosas como 'repetir' y 'si algo, entonces hacer algo'. (Esto no es 100%, ya que no pude encontrar esta tarea). La idea era que Rick solo podía usar lo que le habían dado y tenía que llegar a diferentes lugares en el mapa.

Este fue un ejercicio divertido y algo que lo introdujo a los conceptos básicos (que a veces son los más difíciles de comprender para los recién llegados). No hay una buena respuesta a este problema (es un juego) y no hay soluciones para copiar y pegar. Algo así también podría permitirte jugar con su creatividad un poco más sin intimidarlos con código.

Finalmente, la idea es comenzar con lo abstracto y avanzar hacia lo concreto . No pueden copiar pegar resumen. Tienen que entenderlo para resolver un problema.

Lo que les está pidiendo que hagan es demostrar análisis y síntesis en el dominio cognitivo de la Taxonomía de Bloom , donde actualmente solo están demostrando aplicación.

Desafortunadamente, es una especie de situación de "guiar al caballo al agua". El análisis y la síntesis también son muy difíciles de hacer cuando todavía estás luchando con la comprensión. Sin la comprensión en su lugar, las actividades de análisis y síntesis actuarán más como eliminaciones que actividades de aprendizaje.

Mi opinión personal es que está bien no esperar nada más que la introducción a las clases de programación. Esta es la primera vez que los estudiantes se ven expuestos a estos conceptos, por lo que es como enseñar a los niños a leer antes de pedirles que escriban un ensayo. Esas habilidades de orden superior seguirán en sus clases posteriores.

¿Ha considerado proporcionarles un código para empezar? Cualquier andamiaje simple que necesite la asignación, como una función principal vacía (no sé qué idioma está usando). Algo que compila, corre y no hace nada. Luego pueden comenzar a agregar su código con cierto grado de confianza de que al menos parte de él funciona.

Esto es bastante común en el "mundo real"; Muchos IDEs y otras herramientas crean proyectos vacíos con bibliotecas / plantillas / archivos de configuración típicos ya en su lugar.

Cualquier tipo de mentalidad de culto a la carga (incluidos los cultos a la carga ) proviene de una falta de comprensión fundamental de la tecnología involucrada.

La programación de culto de carga no debe considerarse un hábito problemático, sino un síntoma de la confusión subyacente que enfrenta el programador.

Más importante aún, la suposición de que la falta de comprensión del estudiante es simplemente la consecuencia de su falta de confianza es fundamentalmente errónea y no aborda el problema subyacente.

En cambio, el estilo de programación de copiar y pegar del estudiante debería ser una señal de alerta que le diga que este estudiante está abrumado por la complejidad de lo que espera hacer.

Está utilizando instintivamente el trabajo pasado como un andamiaje sobre el cual construir su proyecto actual, intentando componer una solución utilizando problemas previamente resueltos como bloques de construcción. Todos hacemos esto hasta cierto punto, pero la mayoría de nosotros lo hacemos utilizando los conocimientos adquiridos del trabajo pasado como nuestros componentes básicos. En cambio, este estudiante está utilizando el trabajo en sí, lo que significa que realmente no comprende los bloques con los que está trabajando. Ha descompuesto el trabajo hasta donde su comprensión lo permite, y trata grandes bloques de código como unidades atómicas porque no comprende cómo funcionan . Él solo sabe lo que hacen.

¡Cambia tu idea de proyectos!

En el mundo de la programación, rara vez creamos realmente nuevos proyectos para cada solución que surja. La mayoría de las veces modificamos los viejos.

Cambie su idea de un proyecto de una solución para cada tarea a una solución para todo el semestre. Cada tarea se basa en la tarea anterior.

Ejemplo

Proyecto: construir un sistema de ascensor

• Tarea 1: imprimir el piso actual
• Tarea 2: Cree las estructuras de datos para una clase de elevador e imprima el piso en función del elevador
• Tarea 3: Cree un código que "mueva el elevador", imprimiendo el piso. Aceptar entrada de teclado (> enter floor:)
• Tarea 4: Manejar múltiples ascensores

El punto es que usted construye sobre la asignación anterior en lugar de reciclar las asignaciones antiguas para una nueva tarea.

Considere usar un lenguaje de muy alto nivel que requiera un mínimo de código repetitivo.

Para mí, a menudo es el código repetitivo en marcos grandes o lenguajes detallados que se sienten como hechizos mágicos y dificultan la comprensión.

Personalmente me enseñaron ML en mi curso introductorio de programación CS. Durante muchos años, a Lisp se le enseñó como introducción a la programación en el MIT. Ambas son excelentes opciones. Algunos de los beneficios que tienen son

• Intérprete interactivo Muy importante, ya que esto permite la exploración.
• Muy sucinto No hay repeticiones en absoluto. Permite a los estudiantes concentrarse en las ideas que intentan expresar.
• Relativamente oscuro y extraño (al menos en comparación con Java, C u otros lenguajes convencionales con los que los estudiantes ya pueden tener alguna experiencia). Sí, lo enumero como profesional. Nivela el campo de juego para los estudiantes, ya que probablemente nadie tendrá experiencia previa. Y hace que sea menos probable que puedan copiar y pegar soluciones a la tarea desde la web.

Investigué un poco sobre los problemas de los programadores novatos en los años 80. Según mi experiencia con los programadores novatos de hoy, no ha cambiado mucho. Los novatos no tienen un modelo mental útil de lo que realmente hacen las computadoras. Recurren a encantamientos mágicos porque la máquina en sí misma es mágica.

La programación requiere dividir tareas naturalmente simples en pasos anormalmente pequeños. Dado que los novatos no se ocupan de una granularidad tan fina en la vida diaria, es difícil para ellos descubrir cuáles son los pequeños pasos, especialmente cuando no está claro qué pequeños pasos pone a disposición la máquina. Pero incluso si logran darse cuenta de eso, se enfrentan con la sintaxis forzada y la semántica limitada de un lenguaje de programación (un lenguaje antinatural disfrazado como cuasi natural) que controla la máquina misteriosa por control remoto.

Como no pueden hacer la conexión entre una solución lógica al problema y la funcionalidad de la máquina, se enfocan en satisfacer las demandas del lenguaje. El primer objetivo es escribir algo, cualquier cosa, que compile. El segundo es ajustar ese programa, lo que sea que realmente haga, para evitar que se bloquee. Luego, si tienen el tiempo, la energía y el interés, intentan que el programa produzca resultados que se parezcan a los que requiere el problema. En el camino, pueden producir accidentalmente código bien escrito.

Con toda probabilidad, los novatos que aprenden a programar tienen éxito porque han inferido un modelo mental útil de la computadora, no porque se les haya dado uno intencionalmente y lo hayan internalizado.

¿Podría hacerles preguntas sobre piezas de código que requieren respuestas escritas? Como "¿Qué está haciendo este código?" "¿Por qué el programador lo resolvió así?" "¿Hay una mejor manera?", Etc.

Eso realmente los hará pensar en el problema, que es algo que pueden hacer sin siquiera tocar el código.

• Desafíelos a crear las soluciones más cortas posibles al problema.
• Recompense las soluciones más breves con un incentivo.
• Crea ejercicios que giran completamente alrededor del código de refactorización
• Haga que los estudiantes intercambien las tareas, y simule las calificaciones de eficiencia y limpieza del código, y use algunos de los menos eficientes como ejemplos, en un retroproyector.

Similar a la idea de JoelFans es hacer que hagan las tareas iniciales en papel usando un pseudocódigo (lenguaje) que usted cree. Puede agregar las estructuras como mejor le parezca y no se preocupe por la caja mágica.

Asumiré que con "culto a la carga", quiere decir que están insertando cosas que creen que son necesarias, pero en realidad no hacen absolutamente nada para resolver el problema.

Si ese es el caso, siempre puede agregar algún factor en la calificación que se base en la concisión: dejar código innecesario o redundante en su programa es pedir problemas en el futuro, ya que puede romperse o simplemente hacer que sea más difícil de mantener.

Serían juzgados de manera similar en un ejercicio de escritura en una clase de inglés: nadie quiere cosas que suenen en una tangente aleatoria o que simplemente divaguen sin llegar al punto.

Cuando tomaba una clase de ensamblaje, el maestro nos decía para cada ejercicio si quería que escribiéramos el código de velocidad, tamaño o uso de memoria, y él marcaba si no se acercaba a optimizar lo que pedía. para.

...

Si están copiando y pegando código de tareas similares anteriores, y en realidad es algo para resolver el nuevo problema ... bueno, eso es solo reutilización de código, y a menos que hayan hecho suposiciones erróneas sobre la idoneidad del código para su reutilización , Creo que es perfectamente razonable que lo hagan. (p. ej., leer de un archivo, propiciar la entrada ... todas las partes modulares que se pueden reutilizar. Si no quería que lo hicieran, debe hacer que los ejercicios sean diferentes.

Desafortunadamente, esa es la forma en que funcionan los cerebros de muchas personas. Así que entienda que hay personas que no puede "curar" de esto. Hay muchas personas que no pueden trabajar al nivel de precisión mental necesario para la programación. Algunas personas simplemente no están diseñadas para ello. No digo que renuncies a los estudiantes, digo que no asumas que estás fallando si no todos lo recogen.

Sin saber más sobre el contexto de la clase, diría que enfóquense más con estos estudiantes problemáticos en estructuras muy básicas: simples if / thens, bucles, etc. Rutinas simples para imprimir números impares, cada décimo número, etc. Nada Más de 10 líneas de código cada una. Si son 'pensamiento mágico', obviamente todavía no han dominado esos conceptos básicos. Haga que hagan muchas rutinas simples diferentes hasta que comprendan lo que está sucediendo. Alguien más mencionó escribir el código en papel: creo que también sería una excelente manera de hacer estas simples rutinas.

También puede considerar que aprendan diagramas de flujo. Para algunas personas, poder ver el flujo de un algoritmo, y luego cómo se conecta eso al código, puede ser útil para ellos conectar el código al flujo.

Idealmente en la primera clase, comience con algo completamente abstracto: pídales que (como grupo, con usted como líder) escriban las instrucciones sobre cómo ir de compras de una lista y desglosen las instrucciones de alto nivel progresivamente. hasta que alcancen la iluminación.

Es útil decirles que estas instrucciones serán seguidas literalmente por un robot, que no sabe cómo inferir cosas. Sin embargo, tiene que ser una actividad muy práctica en la que usted esté a cargo de guiarlos.

Alistair Cockburn habla sobre el concepto de Shu-Ha-Ri y cómo se aplica a la programación, http://alistair.cockburn.us/Shu+Ha+Ri . Creo que puede ser importante tener en cuenta dónde están sus estudiantes en este continuo. Primero, eso ayudará a aliviar algo de tu frustración. Copiar / imitar es una respuesta muy natural y un modo aceptado cuando comienza a aprender algo. En segundo lugar, puede ayudarlo a obtener algunas ideas sobre cómo avanzar. Por ejemplo, es posible que desee considerar elegir un problema que se pueda resolver de varias maneras (bucles frente a recursividad, consola frente a web / gui) y luego explícitamente hacer que primero lo resuelvan de una manera, luego de otra manera: bono que pueden aprender sobre reutilización de código legítimo, componente, creación de bibliotecas reutilizables, etc.

Otra forma exitosa que he visto usar es tener una serie de proyectos que se construyen uno sobre el otro, haciendo que una versión de trabajo predeterminada esté disponible en cada paso después de que se entreguen las tareas para evitar que las personas se retrasen. Cada paso del proceso debe introducir algo nuevo. Te concederé que esto puede ser más fácil de hacer en una clase de diseño que en una clase de programación, pero aún así debería ser factible. Una cosa buena de esto es que explícitamente les das una buena (ojalá) implementación para compararla con la de ellos en cada paso. Exponga esta comparación como una tarea, es decir, haga una revisión de mini-código de su propio código contra su esfuerzo. Es posible que desee hacer de esta una de las varias opciones de crédito adicionales.

Si bien normalmente no me interesan los "comentarios", es posible que desee que la documentación del código sea uno de los elementos de calificación. Pídales que produzcan un documento de "Teoría de la operación" para cada proyecto que describa su enfoque, cómo encaja cada componente y cómo resuelven juntos el problema. Normalmente, me gustaría que el código hiciera gran parte de esto por sí solo, pero los llevaría a poner sus límites de pensamiento y ponerlo en papel.

Por último, es posible que desee ser creativo y hacer que sus estudiantes revisen el código del otro y lo evalúen. Presiona a tus compañeros para que trabajen para ti. Permita que esto se convierta en parte de la calificación o crédito adicional para el código de mayor calificación (y documentos).

Solo una sugerencia rápida. Cada vez que tengo un problema de programación que necesita ser resuelto o depurado me gusta mirar mi código y 'jugar computadora' donde en mi cabeza hago un seguimiento de las variables y sus valores y lo que espero que sean cuando se ejecuta cada línea . Entonces, si copié algún código de algún lugar, a menos que esté completo por sí solo y solo necesite hacer referencia a él, me gustaría ir línea por línea para comprender exactamente lo que está sucediendo. Esencialmente jugando a la computadora. El depurador de VBA esencialmente hace esta tarea más fácil, pero hacer que sus estudiantes lo hagan en papel podría darles elementos fundamentales. ¿Qué hace realmente esta línea?

Enseñé programación introductoria a nivel universitario. Fue un curso integral, todos los profesores lo hicieron, y creo que lo hicimos bastante bien. Seguimos un texto común y tuvimos exámenes comunes, pero cada uno tenía nuestro propio método de clase que funcionaba. Ha pasado mucho tiempo desde entonces, pero ocasionalmente puedo dar clases particulares a algún niño en programación, y toda la imagen es casi la misma.

La forma en que lo hago es comenzar desde abajo, lo más concreto posible. Lo que los estudiantes saben es una estructura. Ya tienen muchos conceptos. Estoy construyendo más conceptos además de esos, y estoy eliminando los conceptos que pueden formar que son contraproducentes. Al mismo tiempo, les hago aprender haciendo .

Había construido una pequeña computadora con un chip Intel 8008, algunas EPROM y algunos circuitos. Lo había programado para tocar un pequeño dueto cuando el chip de E / S estaba conectado a un par de altavoces. Explicaría cómo funcionaba el pequeño programa, con un bucle interno para contar un contador. Eso actuaría como un retraso. Luego alternaría el bit de salida y lo volvería a hacer. Haría eso por un tiempo, y luego cambiaría a otro retraso, dando otro tono, y así sucesivamente. El chip de memoria tenía un pequeño temporizador, y si colocaba un cable del condensador debajo de una de las entradas del temporizador, el programa se ejecutaría muuuy lentamente . La clase podía escuchar a los oradores haciendo clic, clic, clic ... Quería que la clase entendiera que la computadora estaba haciendo cosas muy simples paso a paso. Luego desengancharía el cable del condensador y la "música" explotaría. (aplausos)

Luego construí un simulador para una computadora decimal muy simple, con 1000 ubicaciones de memoria, cada una con un número decimal con signo de 4 dígitos. Tenía códigos de operación muy simples como "agregar al acumulador", "saltar si es negativo", y así sucesivamente. Me gustaría que escribieran pequeños programas en este "lenguaje de máquina", como sumar dos números o sumar una lista de números. Luego podrían verlo funcionar con un solo paso, o manteniendo presionada la tecla Intro para verlo correr "rápido".

El objetivo de esto era poner en práctica el concepto de que las computadoras solo pueden hacer un número muy pequeño de operaciones básicas diferentes, y las hacen una a la vez. Esto es para contrarrestar la impresión que tienen de que las computadoras son complicadas, y que hacen todo al mismo tiempo, y leen su mente en el trato.

A partir de ahí pasamos a la programación en un lenguaje "real" (BÁSICO :), comenzando con programas muy simples pero interesantes, pasando por condicionales, bucles, matrices, archivos, fusiones, etc. El objetivo era establecer un conjunto de habilidades suficiente para que pudieran asumir un proyecto de su propia elección, porque eso es lo único que hace que la programación sea interesante: el uso que puede darle. Lanzaría algunas ideas para proyectos, y luego lo tomarían desde allí. Pediría ideas escritas, y luego informes de progreso, para evitar que lo pospongan hasta el último minuto y luego entren en pánico. Creo que los proyectos fueron la mejor parte, porque estaban aprendiendo bajo su propio poder.

Esa base inicial en una comprensión muy concreta de lo que hacen las computadoras hizo que fuera mucho más fácil enseñar conceptos más adelante que, de lo contrario, serían golpes de velocidad reales, como conjuntos o punteros (en un curso posterior). Tendemos a glorificar el concepto de "abstracción" como algo maravilloso, pero debe construirse sobre una base concreta, no en el aire.

Un programador autodidacta, creo que la animación es la más desafiante en términos de saber qué está haciendo el código. Cuando un programa contiene algoritmos y transformaciones matemáticas que realizan manipulaciones abstractas, la única forma de comprender lo que está haciendo la matemática en un punto dado (a menos que sea un genio) requiere comprender la ejecución del código en sí.

Corrígeme si mi ingenua idea es incorrecta. Lo que quiere hacer es notevitar que sus alumnos usen "patrones de diseño", pero ¿encontrar una manera de asegurarse de que entienden lo que son CnP? Luego desafíe a sus alumnos a manipular una animación. Para ajustar la salida en una animación, es necesario comprender lo que sucede en cada paso. Para su preocupación expresada, imagino que un proyecto de animación bien concebido se manifestará de manera obvia cuando un estudiante "lo entienda", cuando se dé cuenta de una transformación que no esperaba o modificó ciertas variables interdependientes relacionadas.

Sin conocer los límites y objetivos pedagógicos con los que está trabajando, no puedo decir que la animación sea la respuesta completa. Debo arriesgarme a adivinar que todo un currículum de animaciones fuera de la profesión de la animación está fuera de discusión. Sin embargo, algunos proyectos pueden resultar en algo ingenioso y maravilloso, lo que no está mal.

En otra nota, leí un artículo de periódico (¡sí, papel!) Sobre una competencia olímpica de codificación a nivel de secundaria (wot-wot) para programadores preuniversitarios. La descripción de sus desafíos fue la articulación más clara de la codificación pura que recuerdo haber leído. Los competidores se juzgan unos contra otros y según los estándares de buenas prácticas. Para estas competencias, los estudiantes deben planificar su solución y codificar a mano el "patrón de diseño" elemental que el problema requiere para terminar dentro de los límites de tiempo. Por lo tanto, la solución a su preocupación con respecto a la programación de CnP es probar si los estudiantes pueden escribir los mismos "fragmentos de código" que son CnP'n.

Estoy seguro de que fue en el New York Times. Una búsqueda rápida no lo encontró. Un ejemplo similar es el Concurso Internacional de Programación Colegiada de ACM. Este concurso enfatiza la programación rápida: "La programación veloz como un rayo en la competencia por equipos es una habilidad decididamente peculiar, no exactamente una que muchos buscadores de trabajo colocarían en la parte superior de un currículum". Por lo tanto, recomendaría la abstracción de los problemas del mundo real es la respuesta.

También,

HP Code Wars

Enseñe a la clase utilizando un lenguaje de programación que es técnicamente bueno pero tan oscuro que no podrán encontrar ningún código existente para copiar.

También podría tratarlos de la manera difícil.

Encuentre la manera de hacer que copiar y pegar sea perjudicial para ellos. No tengo un ejemplo preciso, pero si elaboras un primer ejercicio cuya solución, si se pega en un segundo ejercicio de aspecto similar, lleva a los estudiantes de culto de carga a un muy largo y doloroso error de "inestabilidad inestable" o "corrupción silenciosa de datos". Mientras tanto, un pensamiento de 2 minutos "sin culto a la carga" habría traído una solución obvia incluso al peor estudiante (si no hubiera visto la primera solución de ejercicio). Entonces, tal vez haya alguna posibilidad de que puedan aprender la lección y pensarlo dos veces antes de copiar el código de pegado en el tercer ejercicio.

Dudo que este comportamiento se deba a la creencia de que los programas son hechizos mágicos; lo más probable es que sea pereza y falta de motivación.

Así que creo que su trabajo como profesor es motivar a sus alumnos: ningún alumno que esté realmente motivado cortará y pegará una solución (eso es solo para programadores que trabajan con plazos y resultados finales para cumplir ...)

Enseñar subrutinas. Pídales que tomen el código que están tomando de las tareas anteriores y lo conviertan en una subrutina. Enséñeles sobre la documentación de funciones para ayudarlos a comprender lo que la subrutina está haciendo realmente.

Haga que hagan la tarea frente a usted en el aula sin acceso a Internet (haga que la escuela lo interrumpa, no permita el uso del teléfono durante la clase). Al menos haz esto para las pruebas. No hay ninguna razón para que deban usar Internet para las experiencias básicas de programación. El libro debería ser un recurso suficiente para los ejercicios de introducción. Permita el uso de Internet una vez que esté en una clase avanzada y ya hayan aprendido a pensar.

Nunca les dé tareas que suenen de manera similar.

O, más loco, aprende TDD desde el principio. Presiona para escribir (no copiar, escribir) una gran cantidad de código (es decir, pruebas) que realmente ayuda a formular el problema que se está resolviendo.

Algo que me ha resultado muy útil para las personas de mi clase es escribir un pequeño proyecto sobre ellos, sobre un tema que pueden elegir ellos mismos.

Cuando comencé a programar, también fue difícil para mí, y copié mucho en clase. Luego, en casa, comencé a hacer pequeños juegos, ya que quiero convertirme en programador de juegos, y descubrí que son mucho más fáciles de hacer. Aunque fueron mucho más difíciles que las cosas que vimos en clase. Solo porque me interesó.

Algunas otras personas en mi clase pasaron del 40-50% en sus exámenes al 90-100%, porque hicieron exactamente lo mismo.

Cuando estaba en un curso introductorio de programación, el instructor requería que todos escribieran un algoritmo en inglés, lo imprimieran y lo entregaran antes de comenzar a escribir el código. Luego tendríamos que poner muchos comentarios como Crear variables, Obtener entrada del usuario, Realizar cálculos, Imprimir salida, etc. Me atracaron un par de veces por no tener suficientes comentarios cuando pensé que había muchos, así que comencé a agregar más. Esto me obligó a pensar en lo que estaba haciendo y escribir las soluciones y seguir traduciendo entre inglés y Java.