Mi TA piensa que tengo lo que se necesita para ser un buen programador, pero me castigo por los problemas que encuentro. ¿Cómo paro esto?

Primero, encuentra maneras de relajarte e ignora cualquier sentido de la presión del tiempo.

A continuación, suelta tu ego … aprende a renunciar a preocuparte por si eres “bueno” o “suficientemente bueno”.

Esos dos factores son muy probablemente los principales impedimentos para su progreso en cualquier rompecabezas. (Tampoco piense que los problemas “enigmáticos” son indicadores particularmente buenos de sus habilidades como programador. La codificación y la depuración presentan a cada programador situaciones desconcertantes … pero los rompecabezas artificiales que se presentan con fines académicos suelen ser considerablemente diferentes a los que usted describe d cara en la practica.

En cuanto al ejemplo específico que diste. Divídalo en partes que puede hacer fácilmente.

Por ejemplo, presumiblemente sabes cómo aceptar una entrada y evaluarla como (convertirla o analizarla como) un número entero. Así que escribe esa parte.

Presumiblemente, usted sabe cómo verificar que un número sea impar o par … y cómo lanzar una excepción o emitir un error y salir si la entrada no es válida. (También es posible que desee pensar en otras formas de entrada no válida. ¿Hay algún número entero impar que se degeneraría?)

Es de suponer que también sabe cómo imprimir líneas de texto y, con suerte, cómo crear cadenas e incluso listas de cadenas. Así que escribe una función para construir una cadena que se compone de algún carácter (ch?) Repetido varias veces (n). Así que escribe la función que devuelve eso … y es tu barra cruzada.

Para todas las otras líneas, necesita alguna forma de tener una sola instancia de este carácter (ch) que se desplace hacia el “centro” de la línea (tal vez agregándolo a un cierto número de espacios). Tal vez pueda reutilizar la función que ya escribió para eso o tal vez sea más fácil escribir una nueva. Puede que sea lo suficientemente simple como para ser una expresión (según el idioma que estés usando, por ejemplo).

Ahora necesita alguna forma de imprimir un número de copias de esta línea rellenada con espacio, seguida de una línea de “barra de desplazamiento”, y luego otra cantidad de copias de esa línea rellenada con espacios.

En este momento, la mayoría de los lectores se quejarán de lo mucho que he explicado esto en exceso. Pero mi punto es que descomponer la especificación o los requisitos originales en pasos absurdamente pequeños y simples es EXACTAMENTE cómo se escriben los programas. (Los expertos y mi caso sobre los límites de la descomposición funcional … y podemos tener una discusión diferente sobre eso).

La cosa es que, para cualquier rompecabezas, está el “Ajá” cuando entiendes, en términos generales, cómo hacerlo. Cuando estás atascado, puedes codificar * alrededor de * los bordes y luego jugar con cosas que sabes que no están del todo bien hasta que te golpee con algo de epifanía.

Por ejemplo, podría preguntar por qué tiene que ser un número impar … e intente imaginar lo que haría, cómo podría escribir esto, para manejar los números pares como entrada. Es una mala idea garabatear algunos ejemplos en una hoja de papel o una pizarra.

Eventualmente, es probable que se te ocurra que hay algo importante en tener un punto medio entero en tu entrada y, a partir de ahí, se te puede ocurrir que necesitas usar este punto medio para al menos una o dos de las funciones o Pasos en tu código.

Date cuenta que la meta no es el grado, sino el progreso. Los grados son un proxy de lo que has aprendido, pero no uno bueno. Tu objetivo no debería ser “obtener una A”, sino mejorar en lo que haces. Puedes juzgar por ti mismo si estás mejorando manteniendo las tareas más antiguas y mirando hacia atrás más tarde para ver si habrían sido más fáciles o si las harías de manera diferente.

El primer paso es sacar de la mente cualquier preocupación con la velocidad. Por ejemplo, cuando se encuentra pensando en cuánto tiempo está gastando en el problema, podría recordarse que cada problema lleva tanto tiempo como se va a resolver y, con frecuencia, no tiene sentido tratar de adivinar cuánto tiempo será (bueno , a menos que sea un problema que haya resuelto repetidamente en el pasado).

En cuanto a volver a los problemas de preguntas y cosas así, no te preocupes por eso. He hecho lo mismo con los ejercicios de codificación que tuve que hacer como parte de la entrevista para los trabajos, a veces incluso después de saber que no obtuve el trabajo solo porque quiero saber cuál debería ser la respuesta. Si bien ese tipo de comportamiento puede ser inútil si le permite perder horas de su día, mantenerlo dentro de los límites es uno de los rasgos que podría convertirlo en un gran programador algún día. Solo asegúrate de que cuando te quedas atascado, dejes de lado el problema o empieces a investigar sobre el problema, y ​​si te quedas atascado en la investigación, hazlo a un lado también.

Dado que tu AT aprecia tu “talento” y no tus esfuerzos, lo que sientes es muy normal. Saque esa TA de su cabeza y acérquese a la pregunta con una mente clara. Lo que importa es si disfrutas o no de resolver problemas en el código. No importa lo que piense tu AT. Dependiendo de su esfuerzo, podría terminar siendo un gran programador o podría terminar en la parte inferior del espectro. Resiste la intervención de tu AT y persiste en tus esfuerzos. Debería ayudar.

¡Buena suerte!