Cómo motivarme para aprender codificación.

La motivación viene del deseo, y el deseo viene de la razón. Pregúntate a ti mismo por qué quieres aprender a codificar, lo hace porque sientes a tu amigo y aprendiendo a codificar, entonces te sugeriré que encuentres algo que provenga de tu corazón. Aprender a codificar es muy divertido cuando aprendes que todo es posible con algunas líneas de código.
Encuentre un lenguaje que le guste, como comencé con html y C, luego mi interés en la codificación aumentó, aprendí CSS y php y, por último, me convertí en desarrollador de temas de wordpress. ¿Qué te gusta o qué te atrae?
¿Le gustan las aplicaciones móviles o sitios web o software de escritorio, bases de datos, etc. busque eso y luego comience a aprender esas cosas en particular? Hay muchos recursos en línea disponibles, como Udemy: Cursos en línea en cualquier momento, en cualquier lugar, tutoriales en línea de W3Schools en línea y puede buscar en Google para obtener una gran cantidad de sitios, algunos gratuitos y otros por los que tendrá que pagar. El código de aprendizaje depende de mucha práctica y paciente. Comience hoy. Ningún cuerpo es perfecto desde el primer día. La perfección necesita tiempo y el paciente hace más y más eso. No tomes la codificación como una presión, disfrútala.
Espero que tengas tu respuesta

Por qué querrías hacer eso. La codificación es el producto final de la planificación y el diseño. Por supuesto, ser un programador productivo es parcialmente una experiencia, pero creo que la metodología es una parte importante. Asi que…

Déjame empezar con una anécdota. Conozco a muchos programadores ecológicos que, ante un problema, se sientan e inmediatamente comienzan a programar. A ellos les parece que es lo correcto (¿el código no es el objetivo?). Sin embargo, hacer eso puede encerrarte en una dirección. Tienden a producir métodos de deambulación prolongados, objetos que no están bien pensados ​​y estructuras de datos que son malas para los datos. Esta metodología a menudo puede sentirse como si estuvieras codificando sin llegar a ningún lado.

En su lugar, lo que defiendo es retroceder y ver el problema desde tantos ángulos como sea posible. Consiga el diseño general en su cabeza primero (aunque puede ser borroso). Documentar los casos de uso y cualquier requerimiento técnico. Luego, diseñe y trabaje a través de las estructuras de datos (si estos datos están mejor representados como un árbol, una lista, un diccionario, una base de datos, un árbol de nodos XML, etc., y para problemas de cualquier complejidad, obviamente serán combinaciones). Use la estructura de datos más simple que requieren los datos, no se complique hasta que la implementación lo obligue a hacerlo.

Comience a desglosar los datos y piense cómo fluirán, aún desde la perspectiva general. ¿Todavía se ajusta a tu modelo? Si puede, aquí es donde debe buscar datos de muestra o construir algunos datos de muestra. Sin embargo, no se enamore con el diseño de sus datos, prepárese para desecharlos si algo no encaja y encuentre un diseño mejor.

Bien, ahora que tenemos eso, antes de que concretemos por completo las estructuras de datos (porque hasta que no las use, no puede saber si tienen la razón), comience a dividir el problema en tareas. Normalmente trabajo en entornos OO en estos días, así que creo que cree los objetos de nivel superior y trabaje hacia abajo. No voy a entrar en MVC, MVVC, etc. Son detalles de implementación, los métodos generales no cambian.

Crea los objetos de alto nivel. Escriba los nombres de los métodos y adivine las firmas, pero aún no escriba la implementación. También puedes adivinar las propiedades, pero no exageres. Escriba la documentación para cada método, si sabe que necesita un método que debe saber lo suficiente para documentarlo (si no puede documentarlo, entonces no lo necesita todavía).

Si tiene una sensación particularmente buena de un proceso complejo, siga adelante y escriba pseudocódigo en los métodos como comentarios. Cuando haga esto, escriba los comentarios que están destinados a durar y luego codificará alrededor de los comentarios, pero suponga que los comentarios se mantendrán (existe tal cosa como un código sobre comentado, pero es bastante raro y nunca he tenido que hacerlo). pedir a alguien que escriba menos comentarios). Para el resto de los métodos, simplemente agregue los comentarios TODO y luego lance excepciones no implementadas o devuelva alguna constante.

A medida que avanza en este proceso, cree y encuentre comonalidades y mueva las cosas a interfaces, clases virtuales, etc. a medida que avanza. Limpie sus métodos no escritos para aclararlos en base a estas relaciones de clase padre. No sea creativo aquí, solo cree los métodos que realmente son necesarios para un método en un nivel más alto de complejidad. Estás resolviendo un problema, no construyendo una estatua.

A estas alturas ya sabes dónde estarán las partes difíciles. Comience a escribir esas partes difíciles y deje las partes fáciles para más adelante. Si necesita una clase para implementar otro método, escriba el esquema de ese método (tal vez modificando las interfaces, etc. a medida que avanza) y TODO comentarios, pero deje la implementación hasta más tarde. No optimice su código, simplemente escriba la versión más clara de cualquier solución. La optimización viene mucho más tarde.

Ahora es donde les digo que escriban las pruebas. No puedo decir que soy el mejor probador de unidades, (no, eso es demasiado moderado, apesto en las pruebas de unidad). Llegué a la programación antes de que realmente se enseñara. Los defensores de TDD probablemente te harían escribir las pruebas después de mi primer párrafo o algo así. Sin embargo, escribir las pruebas en este punto del proceso me parece correcto, y comenzar con las pruebas de los métodos difíciles a medida que las escribes.

A lo largo de este proceso, debe observar el modelo de datos y ver si alguno de sus nuevos conocimientos durante la implementación indica un cambio. Debería estar solidificando los modelos de datos a medida que escribe el código duro (el código fácil a menudo simplemente se sale del modelo de datos, como CRUD). Haz las pruebas del mundo real. No cree casos de uso aleatorios, apéguese a los que ha identificado (eso no significa que no encontrará nuevos casos de uso reales a medida que avanza).

Ahora que tienes un código escrito y algunas pruebas escritas, todo debería compilarse, pero no se ejecutará ni pasará las pruebas. El resto del trabajo es solo trabajo de pala. Has puesto todos los cimientos. Comience desde una función de alto nivel o comience desde una prueba, y haga que todo funcione, de extremo a extremo. Sigue haciendo eso hasta que tengas todas las funciones de alto nivel codificadas. Si las funciones de alto nivel se vuelven demasiado complejas, divídalos, empuje hacia arriba o hacia arriba cualquier código duplicado, haga que los métodos sean claros y fáciles de leer. Todavía no estás optimizando.

Mi método aquí es que recorro todas las rutas en el depurador (así es como aprendí a probar y creo que funciona bien). Reiniciaré la pila tantas veces como sea necesario y manipularé las variables para recorrer los distintos caminos. De esta manera, me aseguro de que todo esté haciendo lo que esperaba que hiciera (y sí, sé que si fui mejor en la prueba de unidad, a la larga sería mejor, estoy trabajando en ello).

Una vez que tenga todo funcionando, vaya a buscar declaraciones de TODO. Si no implementó un método en este punto, elimínelo. No lo necesitabas de todos modos. No implemente cosas que no necesita, eso es lo que sucede cuando se repite en función de los comentarios y el uso real.

Comienza a ramificar la prueba de la unidad, más y más alto. Ahora es el momento de buscar problemas de rendimiento, y no un paso antes. Asegúrate de probar cómo se utilizarán realmente las cosas.

Lo siento, esto fue un poco largo. Esperemos que esto haya sido útil.

Gracias Anurag por A2A:

Intenté esto con mi hermano Satyam Singh recientemente. Así que el pasado octubre estaba en la clase 8 entonces, y acababa de comenzar la programación básica en clase. Así que pensé en él algunos conceptos básicos en casa, como escribir una calculadora en VB. (Dado que vb se basa en la interfaz de usuario, es muy fácil visualizar lo que está escribiendo. Por lo tanto, es más interesante para los nuevos programadores). Aprendió a escribir una calculadora en pocas horas. En un par de horas más, estuvo trabajando en otros problemas como la conversión de temperatura, el cálculo de intereses, etc.

Eso fue solo el comienzo. Luego trabajó en un proyecto que sugerí:

Escribió cada línea del programa para este seguidor de línea por su cuenta. En 6 meses se convirtió en programador.

Fui arrastrado por ella. Porque no esperaba que él se diera cuenta de esto tan rápido. Siento que estas cosas lo ayudaron y lo motivaron:

  1. Comience con código básico simple
  2. Para un programador nuevo: las herramientas de la interfaz de usuario lo ayudan a visualizar y mantienen las cosas interesantes.
  3. Un reto al que puedes dedicar meses de tu tiempo.
  4. Paciencia. Trabaja en un proyecto que te guste porque se puede frustrar muy rápido. Y en esos momentos hay que seguir avanzando. Sigue presionando por un poco más de código.
  5. Alguien de su familia / amigo cercano que sabe en qué está trabajando y lo alienta todo el tiempo.

Todo lo mejor.

PD: aprender git es una cosa muy simple y mantener tu código allí. Así que no terminas perdiéndolo.

Te voy a dar la respuesta que funcionó para mí. colegio comunitario.

Mucho ánimo, buenos estudiantes (generalmente), muchos comentarios, buenos incentivos, precios económicos y excelentes horas de instrucción.

Es posible que tenga dificultades para encontrar los cursos que le interesan, pero no se dé por vencido.

No dijiste si ya estabas en un programa de cuatro años, pero si te sientes inclinado, puedes graduarte e ir a la universidad.

Realmente hombre. Si tiene que estar en Quora, pregunte a la gente cómo motivarse para codificar. . . o estás pasando por una depresión temporal o la codificación no es para ti. También podrías estar codificando para una gran corporación que te paga perlas y rubíes por limpiar los excrementos de mierda del código heredado. Por favor, dinos cuál es para que podamos ayudarte mejor.

Pruebe http://code.org . Es una buena forma de aprender y motivarte a ti mismo para codificar. Además, puede obtener algunas ideas de cómo hacer buenos juegos, programas que pueden ayudar a otros a aprender el código. 🙂

¿Qué más en la vida disfrutas? ¿Y cómo podrías mejorar en eso a través de la programación? Elija un tema que sea de su interés y en el que pueda encontrar una ganancia personal. Esto conducirá eventualmente a despertar en la informática para que pueda emprender otros proyectos de mayor complejidad. Una vez que comience, siempre que haya un objetivo a la vista, tendrá la motivación para seguir escribiendo y mejorando su código.

Disfruta de lo que estás haciendo. Parte de esto es elegir cosas que disfrutas, pero he descubierto que incluso si hay algo que no está en mi timonera, si me gusta, entonces me puede gustar.

La otra cosa es deshacerse de las cosas difíciles, deshacerse de lo desconocido. Haces esto haciendo esas partes primero. Haz todas las cosas a las que no estás acostumbrado primero. Establecer buenos marcos para trabajar. Estás trabajando para configurar una parte de codificación pura del proyecto. Luego, cuando llegues, carga tu música y ponla en marcha.

Acabo de pasar 3 semanas de codificación pura después de pasar un par de meses revisando la burocracia y las incógnitas y sentiéndome cómodo con un idioma. Se estaba volviendo loco cosas celestiales. Escribí una cantidad absurda de código de trabajo magnífico en un espacio de tiempo tan pequeño, estaba en un estado de flujo prácticamente todo el tiempo y disfruté cada minuto de él. Solo tienes que hacer el trabajo duro para llegar a ese punto en un proyecto.

una vez que comience a interesarse en la codificación automáticamente, sentirá el hambre de saber más … y el interés aumentará gradualmente si hace que sus fundamentos sean muy fuertes … Si quiere comenzar con LET US C de Yashwant Khanetkar …

Mira este YouTube –

Solo permítete comer una comida después de dos horas de codificación. El hambre lleva al trabajador a trabajar.

Simplemente comience a codificar con un programa pequeño y luego cambiará automáticamente a uno más grande una vez que tenga interés, le encantará

Pregúntate a ti mismo, y me refiero a que preguntes a ti mismo