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

No hay nada de malo en resolver tus algoritmos en papel primero. No tanto para la codificación diaria, sino para los 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 hace más claro. Para un estudiante, el programa cada es complejo.

Si quieres mejorar en el diseño de algoritmos en una computadora, hay algunas técnicas que puedes practicar. No empiece simplemente escribiendo el código, escriba las mismas cosas que pondría en papel como comentarios, luego expándalo a un código real o comentarios más detallados uno por uno.

Por ejemplo, si estoy eliminando un elemento de la mitad de una lista enlazada, 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 element con una función con más pseudocódigo, y continuar hasta que tenga una solución completa. No creas que el código debe escribirse de manera lineal.

¡Adelante! 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 eliminar el código.

A la gente le gusta pensar (ya los ruidosos les gusta decirnos) que su forma de hacer las cosas es mejor. Pero la habilidad de todos y la combinación de habilidades es diferente. Así que haz lo que te funcione. A medida que adquiera práctica, probablemente cambiará a hacer más trabajo de diseño mentalmente y usará papel para problemas mayores.

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

No creo que haya nada incorrecto en el diseño del código (pseudo o de otro tipo) en el papel primero, realmente no es diferente a escribirlo en una pizarra, lo que mucha gente hace cuando analiza cómo abordar un problema.

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

Le sugeriría que intente escribir sus algoritmos, incluso si está 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 la pluma. Y si sus habilidades para escribir no son suficientes y de hecho esa es la fuente de su frustración, ¡tome un curso de escritura! Sería lo mejor que podrías hacer para tu futura carrera.

No escribo código real en un papel, pero para cualquier cosa no trivial casi siempre comienzo en una pizarra o un cuaderno. Por lo general esbozo:

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

Por lo general, es una combinación de bocetos, pseudocódigo e inglés.

Encuentro que al hacer esto, es más fácil de visualizar cuando comienzo a codificar. También detectaré fallas antes . Comienzo con el código porque puedo ver todo lo que está frente a mí (en lugar de un desplazamiento incesante y un salto de ventana). No solo eso, una vez que está escrito, puedo dejar que las cosas se formen en mi mente mientras trabajo en otras tareas. También puedo trabajar de forma no lineal, comprometiendo una idea en un papel cuando me golpea y luego vuelvo a ella cuando llegue al punto en que la necesito.

Comprometer algo en el papel es una gran ayuda para la retención de memoria. El lema de la marca de cuadernos de 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 un papel, incluso si hago una entrada en la aplicación ToDo en mi teléfono un momento después, encuentro que el pensamiento está más consolidado en mi cabeza que simplemente hacer la electrónica. Nota. IOW, al planear mi codificación en papel / pizarra, las ideas permanecen mejor en mi cabeza.

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

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í mismo, y no será suficiente para encontrar una buena solución. Si el papel, la pizarra o el comienzo en el techo te ayudan en ese sentido, entonces hazlo.

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

¡Ustedes van a las entrevistas! Te hacen escribir código en papel o en la pizarra. Soy exactamente lo contrario. Intentando escribir llaves o cortar & pegar con un bolígrafo es tan tedioso!

Mi papá usó mucho papel al programar COBOL. Creo que es solo tu estilo de pensamiento.

Solíamos tener una clase de dos semestres llamada The Basics of Programming. Ambas pruebas de medio semestre y los exámenes al final se realizaron en papel. Si cometió algún error de compilación, perdió una gran cantidad de puntos. Si cometiste grandes errores de compilación, fallaste. Sin embargo, siento que ha desarrollado la capacidad de ver cualquier código y encontrar líneas con errores en un período de tiempo relativamente corto.

No hay nada de malo en lo que estás haciendo, también aprendí a programar usando papel y bolígrafo.

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

A medida que adquiera más experiencia y confianza, se encontrará usando menos lápiz y papel. Ya sabrás cómo usar conceptos básicos como, por ejemplo, bucles, etc. Tendrás ejemplos en otros programas, que puedes reutilizar. Utilizará el compilador y un IDE para encontrar errores obvios durante la escritura del programa. Ahora mismo, aunque no tienes esa experiencia.

Al leer su pregunta, me pregunto si algunos de sus problemas podrían deberse a un enfoque. Si usar un lápiz y un papel en un entorno tranquilo te ayuda a enfocar, entonces es genial.

Todavía estás en la universidad y todavía estás aprendiendo. En última instancia, todo lo que estás haciendo es lo que funciona para ti. Si al usar papel y bolígrafo está ordenando sus pensamientos y pensando con claridad y calma, entonces está programando.

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

Haz lo que te funcione. No escribiría el código en el 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 me enfrento al mismo problema en mi primer día de aprendizaje de habilidades técnicas.

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

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

  

También estoy haciendo un trabajo de papel, pero cuando antes de implementar mi funcionalidad haga una estimación aproximada, comenzaré Mi implementación en el sistema.

Por favor, trate de pasar más tiempo en la práctica del sistema. Esto le dará un 100% de confianza y resultado.