¿Debo tratar de aprender algo rápido o está bien tomarme mi tiempo?

La programación es difícil porque requiere un pensamiento lógico y abstracto. Estás diseñando algo nuevo y único. Hay algunos conceptos generales como algoritmos y patrones de diseño que pueden ayudarte, pero al final, necesitas hacer las cosas por tu cuenta.

La segunda razón es porque las computadoras no pueden comprender algo como lo hacemos nosotros. Necesitas decir exactamente lo que (computadora) debe hacer y, a menudo, a medida que crece la base de código, aparecen esos pequeños demonios, parte de las pesadillas de todos los desarrolladores de todo el mundo, ¡bichos!

¿Pero cómo? ¡Todo funcionó bien desde el último compromiso! Ahora necesitas seguirlos. Compruebe esta línea. Bien, veamos de dónde viene este argumento. Hmm … tal vez si cambio esto … Felicitaciones. Arreglaste un error e hiciste 20 nuevos.

Ahora empiezas a rasgarte el pelo, ¿qué hice mal? Ahora es el momento de agregar puntos de interrupción y realizar un proceso aburrido de depuración. Bueno. Arreglaste 19 bugs pero queda uno. ¿De dónde viene? Vamos a empezar de nuevo. ¡Genial! El error está arreglado. ¡Vamos, compilamos!

Guay. El programa es completamente válido pero no hace lo que pretendías. “Fu * k esto, voy a tirar último compromiso y empezar de nuevo”.

Unos minutos más tarde

“¡Aquí vamos!” Compilando … “¡¿Estás bromeando ?! 25 bichos ?! ¡Esto es ridículo! El modo de ira cambió. Estás golpeando el teclado más duro. Refactorización. Compilar. 30 bichos. Deshacer. Refactorización. Compilar. 27 bichos. Deshacer. Refactorización. Compilar. 34 bichos. Deshacer.

“Eso es, nunca terminaré esto. Voy a perder mi trabajo Nadie me volvería a contratar. Soy el peor y más miserable programador de este mundo … espera … olvidé ponerle el punto y coma aquí …

Compilar. Todo funciona. Eres la persona más feliz del mundo. Tu compilador te quiere. Ahora tienes motivación para agregar la siguiente característica increíble. Tan feliz que te olvidaste de cometer cambios.

La gente aprende a su propio ritmo. Lo que usted considera “tomar demasiado tiempo para aprender” es posible que alguien más esté muy feliz de aprender a ese ritmo. Su único error es darse por vencido … cuanto más aprenda acerca de la programación, más problemas encontrará y, por naturaleza, son problemas más difíciles ya que está avanzando en su conocimiento.

Ver, la programación es una experiencia de aprendizaje de por vida. Por ejemplo, he estado trabajando durante diez años y he aprendido mucho, y aún tengo mucho más que quiero aprender. A menos que sea por una razón específica relacionada con el trabajo, no tiene ningún sentido medir su progreso en términos de tiempo. Más bien, mida su progreso en términos de conocimiento.

Déjame darte una pista. Aquí hay una respuesta que escribí para otra pregunta que terminó siendo enviada en el Compendio de cuotas: la respuesta de Michael Bryant a ¿Cómo puedo desarrollar habilidades de programación rápidamente como novato?

Tenga en cuenta el uso de la palabra “rápidamente” en esa pregunta. Una de las primeras cosas que digo es “Abandonar la expectativa de ‘rápido'”.

Sí, está bien aprender algo más lento de lo que “debería” (lea: esperar). Me tomó mucho tiempo aprender esa lección. Yo era el niño inteligente en mi escuela primaria. Incluso siendo una escuela privada, todo fue fácil para mí y, en las pocas ocasiones en que no fue así, cerré y me negué a hacer la tarea porque era “imposible”.

Aprendí mi lección en mi clase de estudios sociales en la escuela secundaria. Casi fracasé esa clase en 6to grado. Se chupó

Sin embargo, me enseñó una valiosa lección. A veces te lleva un tiempo aprender algo. A veces no puedes levantarlo inmediatamente y te lleva alejarte y volver a él más tarde. A veces es necesario hacerlo varias veces, pedir ayuda, obtener una respuesta, aún no poder resolverlo, alejarnos y finalmente resolverlo después de regresar.

La marca de un buen programador de la OMI no es la rapidez con la que pueden aprender y escribir código, sino la persistencia en el aprendizaje del idioma o la realización correcta del proyecto . Surgen errores que no puedes rastrear de inmediato a la fuente. ¿Se da por vencido o investiga sobre problemas similares y sigue atentamente todo a través del código hasta que encuentra el problema (probablemente en una biblioteca que está usando)?

Dado que usaste términos como “mal hábito”, diría que ya sabes cuál es la respuesta y solo estás buscando confirmación: no eres estúpido por luchar para entender algo. La mayoría de los programadores tienen ese problema en algún momento, en realidad. Los que no tienden a tener la experiencia suficiente como para haber visto el problema antes y por eso se lo pasan fácil. Sin embargo, eso no significa que no lucharon al principio.

El mejor consejo que puedo darte es que no tomes atajos para aprender a codificar. Vas a extrañar algo que desearías no haber tenido. Tómese el tiempo para hacerlo bien. Solo confía en mí en eso.

Puede hacerlo de cualquier manera, pero tomarse el tiempo para aprender algo disminuye la posibilidad de perder algo importante y mejorar en las partes con las que no es bueno. Personalmente, ser bueno en una habilidad debería tomar tiempo y esfuerzo para desarrollarse. No solo le brinda logros reales a usted como aprendiz, sino que también puede apreciar lo que se necesitó para llegar a ese punto.