¿Escribir mi enfoque de resolución de problemas en papel? [cerrado]

Soy un estudiante de primer año de Ciencias de la Computación y acabamos de comenzar a hacer algunos proyectos reales en Python. He descubierto que soy muy eficiente cuando uso el método de lápiz y papel que mi profesor sugirió en clase. Pero cuando no puedo escribir mi problema y resolver mis algoritmos en papel, soy muy lento. Durante los laboratorios, siempre parece que tengo que llevar la tarea a mi dormitorio. Cuando llego allí y lo escribo, resuelvo el problema que me llevó a toda la clase en unos 5 minutos.

Tal vez sea porque me estreso al ver gente resolviendo laboratorios antes que yo. O tal vez es el método de lápiz y papel.

Estaba navegando por los foros y alguien escribió que si tienes que escribir tus programas en papel, entonces no deberías ser un programador. Estoy realmente preocupado porque estoy mucho mejor cuando puedo ver lo que está haciendo el programa y seguir mi camino antes de escribir el código real. ¿Estoy haciendo algo mal?

Editar: Perdón por no estar claro, pero cuando dije escribir en papel me refería a mi enfoque de resolución de problemas (por ejemplo, escribir ejemplos, hacer tablas con valores, etc.) no mi código real. Solo uso el papel para sacar mis ideas.

No hay nada de malo en resolver sus algoritmos en papel primero. No tanto para la codificación diaria, sino para algoritmos más complejos, los programadores profesionales los resuelven en papel o en una pizarra todo el tiempo, especialmente si un formato gráfico lo deja más claro. Para un estudiante, cada programa es complejo.

Sin embargo, si desea mejorar el diseño de algoritmos en una computadora, existen algunas técnicas que puede practicar. No comience simplemente escribiendo el código, escriba las mismas cosas que pondría en papel como comentarios, luego amplíelo en código real o comentarios más detallados uno por uno.

Por ejemplo, si estoy eliminando un elemento del medio de una lista vinculada, podría comenzar con algo como:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Entonces podría reemplazar // find the elementcon una función con más pseudocódigo, y continuar hasta que tenga una solución completa. No piense que el código tiene que escribirse de manera lineal.

¡Ve a por ello! Si llamamos a lo que está haciendo pensando y diseñando su solución, entonces tiene sentido que su proceso sea mucho más rápido que simplemente lanzar código.

A la gente le gusta pensar (y a los ruidosos nos gusta decirnos) que su forma de hacer es mejor. Pero la habilidad y la combinación de habilidades de cada persona es diferente. Entonces haz lo que funciona para ti. A medida que adquiera práctica, probablemente cambiará a hacer más trabajo de diseño en su cabeza y usará papel para problemas mayores.

Una cosa a tener en cuenta es qué forma tomarán los exámenes. ¿Estarán en papel o estarán basados ​​en computadora? Si se basan en papel, entonces su camino le dará una ventaja. Si están basados ​​en computadora, entonces también está bien: haga cualquier diseño en papel y luego escriba el código. ¡Lo que funcione mejor!

No pongo el código real en papel, pero para cualquier cosa que no sea trivial, casi siempre comienzo en una pizarra o un cuaderno. Generalmente bosquejo:

• Algoritmos / proceso / flujo de control
• Estructuras de datos
• Relaciones
• Componentes (¿cómo divido este problema?)

Suele ser una combinación de bocetos, pseudocódigo e inglés.

Me parece que al hacer esto, es más fácil de visualizar cuando empiezo a codificar. También detectaré fallas antes de comenzar con el código porque puedo ver todo lo que tengo enfrente (en lugar de desplazarse incesantemente y saltar ventanas). No solo eso, una vez que está escrito, puedo dejar que las cosas se formen en el fondo de mi mente mientras estoy trabajando en otras tareas. También puedo trabajar de forma no lineal, comprometiendo una idea con el papel cuando me golpea y luego volviendo a ello cuando llegue al punto donde lo necesito.

Comprometer algo con el papel es una gran ayuda para la retención de la memoria. El lema de la marca de portátiles Field Notes es este:

No lo escribo para recordarlo más tarde, lo escribo para recordarlo ahora.

Después de adoptar un enfoque más centrado para escribir las cosas en papel, incluso si hago una entrada en la aplicación Tareas en mi teléfono un momento después, me parece que el pensamiento está en mi cabeza mucho mejor que simplemente hacer la nota electrónica. IOW, al planificar mi codificación en papel / pizarra, las ideas se quedan en mi cabeza mejor.

También sirve como una referencia útil cuando es hora de documentar lo que he escrito.

No creo que haya nada intrínsecamente malo en redactar el código (pseudo u otro) en papel primero; en realidad no es diferente de escribirlo en una pizarra, lo que mucha gente hace cuando discute cómo abordar un problema.

¿Escribe primero los primeros borradores de ensayos para clases que no son CS en papel antes de escribirlos? De hecho, solía hacerlo hace años cuando aún era un estudiante universitario, pero después de mi primer año, me obligué a escribir todos los borradores en una pantalla, ya que hizo que escribir borradores posteriores fuera mucho más fácil, y la misma idea se aplica para escribir código.

Te sugiero que intentes escribir tus algoritmos, incluso si es solo en un editor de texto como Word. Cuanto más lo hagas, más cómodo te sentirás al no depender del papel y el bolígrafo. Y si sus habilidades de mecanografía son deficientes y esa es la fuente de su frustración, ¡tome un curso de mecanografía! Sería lo mejor que podrías hacer para tu futura carrera.

Resolver el problema y escribir el código que implementa su solución son dos actividades diferentes.

Si no está familiarizado con un idioma, pasará mucho tiempo en el código en sí, y no lo suficiente para encontrar una buena solución. Si el papel, la pizarra o comenzar desde el techo te ayudan en ese sentido, entonces, por supuesto, hazlo.

(Personalmente, me encuentro bajando de la computadora y caminando en círculos tratando de construir una solución en mi mente)

¡Te saldrán entrevistas! Te hacen escribir código en papel o en la pizarra. Soy exactamente lo contrario. ¡Tratar de escribir llaves o cortar y pegar con un bolígrafo es TAN tedioso!

Mi papá usaba mucho papel cuando programaba COBOL. Creo que es solo tu estilo de pensamiento.

Solíamos tener una clase de dos semestres llamada Los fundamentos de la programación. Tanto las pruebas de mitad de semestre como los exámenes al final se realizaron en papel. Si cometió algún error de compilación, perdió una gran cantidad de puntos. Si cometió grandes errores de compilación, falló. Sin embargo, creo que desarrolló la capacidad de echar un vistazo a cualquier código y encontrar líneas defectuosas en un tiempo relativamente corto.

No hay nada de malo en lo que estás haciendo, también aprendí a programar con papel y lápiz.

Como otros han sugerido, haz lo que funcione para ti. Recuerdo que el primer programa Java que escribí fue principalmente en papel y luego pasé dos horas escribiendo y quince minutos llorando cuando vi más de 200 errores del compilador. ¡Hubo más, pero el compilador solo mostraría los primeros 200! Sin embargo, lo que quiero decir es que al escribir el código en papel pude pensar a través del algoritmo básico y la funcionalidad de lo que el programa necesitaba hacer. El compilador señaló las razones por las cuales mi programa no se ejecutaba. El 90% de los problemas estaban fuera de los límites de excepciones con matrices.

A medida que gane más experiencia y confianza, se encontrará utilizando menos lápiz y papel. Ya sabrá cómo usar conceptos básicos, como bucles, etc. Tendrás ejemplos en otros programas, que puedes reutilizar. Utilizará el compilador y un IDE para encontrar errores obvios durante la redacción del programa. En este momento, aunque no tienes esa experiencia.

Leyendo su pregunta, me pregunto si algunos de sus problemas podrían deberse a un enfoque. Si usar un lápiz y papel en un ambiente tranquilo te ayuda a concentrarte, entonces genial.

Todavía estás en la universidad y todavía estás aprendiendo. En definitiva, todo lo que estás haciendo es lo que funciona para ti. Si al usar papel y lápiz estás ordenando tus pensamientos y pensando con claridad y calma, entonces estás programando.

Mi código está mucho mejor organizado cuando escribo notas y enfoques en un bloc de notas, reviso libros, reviso la web y pienso en ello. También soy mucho más una persona visual, por lo que es muy útil dibujar imágenes con estructuras de datos. No escribo cada línea, pero sí garabateo lo que considero fragmentos "importantes" o funcionalidades clave. Para proyectos más grandes, enciendo Visio. No estoy seguro de por qué alguien recomendaría saltar directamente al teclado a menos que sean mucho más eficientes o paguen por hora.

Haz lo que te funcione. No escribiría código en papel. Escribo pseudocódigo y dibujo diagramas de flujo en papel, pero escribir el código completo parece una pérdida de tiempo.

También estoy enfrentando el mismo problema en mi primer día de aprendizaje de habilidades técnicas.

Pero este tipo de práctica no debería dar el 100% de éxito porque si estamos escribiendo código en papel, entonces no hay posibilidad de corregir errores, existe la posibilidad de resolver los errores y excepciones durante el papeleo.

Por lo tanto, el papeleo no proporciona ninguna navegación para resolver los problemas, y podemos obtener la velocidad de escritura como bonificación debido a la práctica del sistema.

También estoy haciendo trámites, pero cuando antes de implementar mi funcionalidad solo haga una estimación aproximada, después de esto comenzaré mi implementación en el sistema.

Intenta dedicar más tiempo a la práctica del sistema. Esto le dará 100% de confianza y resultado.