Motivarte para escribir el código después de haber diseñado algo [cerrado]

¿Me sucede solo a mí o también te resulta familiar?

Es así: tienes que crear algo; un módulo, una característica, una aplicación completa ... lo que sea. Es algo interesante que nunca has hecho antes, es un desafío.

Entonces comienzas a pensar cómo lo vas a hacer. Dibujas algunos bocetos. Escribes algunos prototipos para poner a prueba tus ideas. Estás poniendo diferentes piezas juntas para obtener la vista completa.

Finalmente terminas con un diseño que te gusta, algo que es simple, claro para todos, fácil de mantener ... lo que sea. Cubriste cada base, pensaste en todo. Sabes que vas a tener esta clase y ese archivo y ese esquema de base de datos. Configure esto aquí, adapte esta otra cosita allí, etc.

Pero ahora, después de que todo esté resuelto, tienes que sentarte y escribir el código. Y ya no es un desafío ... He estado allí, hecho eso! Escribir el código ahora es solo "formalidades" y hace que parezca que se repite lo que acaba de terminar.

En mi trabajo anterior, a veces me salía con la suya porque alguien más hizo la codificación según mis especificaciones, pero en mi nuevo trabajo estoy a cargo de todo el proceso, así que tengo que hacer esto también (porque me pagan por hacerlo eso).

Pero tengo un proyecto para mascotas en el que estoy trabajando en casa, después del trabajo y solo estoy yo y nadie me paga por hacerlo. Hago el trabajo creativo y luego, cuando llega el momento de escribirlo, simplemente no tengo ganas (vamos a navegar un poco por la web, ver qué hay de nuevo en P.SE , SO, etc.).

Solo quiero pasar al siguiente desafío, y luego al siguiente, y al siguiente ...

¿Esto te pasa a ti también? ¿Cómo lo afrontas?

¿Cómo te convences de entrar y escribir el maldito código?

Tomaré cualquier respuesta.

Si el desafío para usted es diseñar y no implementar, tal vez necesite un factor de motivación diferente:

Si es un proyecto favorito (no para el trabajo), realmente espero verlo cobrar vida, por lo que diseñarlo no es suficiente para mí. Cuando se te ocurren tus propios proyectos favoritos, ¿cuál es el objetivo? ¿Es para algo que necesitas usar? Si es así, puede usar eso como la motivación para implementarlo. Para verlo funcionar. Para proporcionar la funcionalidad que buscabas para salir de ella.

¿Planeas ponerlo a disposición de otros? Un factor motivador podría ser verlos beneficiarse del producto final. No van a obtener la utilidad si solo está en modo de diseño. Y si planea comercializarlo, use el hecho de que nadie va a pagar por su proyecto de mascota mientras está atascado en el modo de diseño, como un factor motivador.

Cuando trabajo en lo mío, adopto un enfoque más iterativo del que podría en el trabajo: no me preocupo por todos los detalles antes de generar algo. Puede tomar más tiempo, pero 1) ya que es solo para mí (o para alguien que ni siquiera sabe que existe de alguna forma), entonces tengo la flexibilidad de experimentar y tomarme mi tiempo. 2) Paso un montón de ciclos refactorizando y aprendiendo mejores formas de hacer las cosas. Por mi cuenta, figurativamente hablando.

Sin embargo, en última instancia, ¿no es la verdadera satisfacción ver que algo cobra vida de la nada? Eso es lo que me sirve. Si eso no lo hace por usted, a menos que su motivación sea el producto final, entonces no estoy seguro de entender por qué quiere trabajar en el proyecto de mascotas. Si el diseño es lo que te entusiasma, y ​​lo haces en el trabajo, parece que ya obtienes la satisfacción que estás buscando.

Necesita prototipos rápidos, en casa.

Cuando aplica el mismo nivel de rigor profesional en un proyecto personal privado, resulta fácilmente una ingeniería excesiva.

Es perfectamente aceptable establecer un alto estándar para un proyecto personal, pero debe comprender que es posible que no tenga suficientes recursos (horas de codificación, además de sus 8 horas de trabajo diario) para avanzar en el proyecto.

¿Cuál es el objetivo más esencial en su proyecto de mascota? ¿Para probar la utilidad de una de tus ideas? Si este es el caso, recorte el proyecto hasta que se convierta en un proyecto de prueba de concepto . Luego, use prototipos rápidos para que pueda lograr más con menos tiempo de codificación.

Supongo que soy solo yo, pero tengo el problema opuesto. Por lo general, tengo problemas para pensar en todos los detalles antes de comenzar a escribir el código y realmente me encuentro con los problemas relevantes. Siendo realistas, generalmente solo tengo un diseño vago en mi cabeza cuando comienzo a codificar algo. Mi gran desafío es hacerme pensar en todos los detalles y tener un diseño por adelantado.

Definitivamente puedo relacionarme con eso. Me encanta asumir el desafío de cosas que no he encontrado, pero me cuesta comenzar a trabajar en algo que ya he resuelto. Lo más importante que hago es obligarme a sentarme con el objetivo de hacer que X funcione y funcione. Por lo general, una vez que me pongo en marcha, termino divirtiéndome y hago más de lo que me propuse en primer lugar, pero si no forzo un gol, solo me aburriré durante horas.

También estoy con ustedes en que esto sucede más en casa como trabajo lateral que en la oficina. No sé si son más distracciones, quemaduras del trabajo o qué ...

Ciertamente entiendo tu frustración ya que ya la he pasado antes.

A pesar de temer algunas llamas de la comunidad, ya que sé que este no es un gran enfoque, compartiré mi enfoque para proyectos paralelos con usted. Tenga en cuenta que este método funciona para mí y lo uso en proyectos a mediano / largo plazo, no lo haría por algo pequeño (ya que generalmente tengo la motivación para terminarlo de una vez).

Tome todo el proyecto y divídalo en 'paquetes', cada uno de los cuales consta de partes que van a interactuar entre sí a menudo. Luego divida cada paquete en pedazos pequeños (piense unas horas como máximo) que puede diseñar y codificar.

Idealmente, podría completar cada pieza en el tiempo que asigne para su proyecto paralelo por un día, pero eso no es obligatorio (depende de la persona).

Personalmente, no me configuro con un marco de tiempo estimado para cada pieza porque me decepciono y me desmotiva una vez que no cumplo con esa estimación, por lo tanto, no lo recomiendo. Tómese su tiempo, pero tampoco se demore demasiado.

Ahora, cada pieza pequeña obtiene todas las etapas de su proceso normal de desarrollo, diseño, prueba, implementación y cualquier otra cosa que necesite hacer. La idea es dar a cada pieza un buen comienzo, pero aún no un toque final completo.

Esto mantiene mi motivación porque sé que después de un par de horas de cosas aburridas de codificación real tendré que diseñar más (delicioso). No te alejes de tus objetivos, solo sigue haciendo esa terrible tarea y pronto terminarás.

Después de haber revisado todas las piezas, mira el paquete. Vea cómo funciona, qué está haciendo, revise todo el paquete nuevamente. Estoy seguro de que habrá cambios y ajustes, hazlos ahora. Mantenga la información más vital en su mente, ya que la necesitará cuando trabaje en todos los demás paquetes. Mantenga notas también, ayudan mucho.

Revisa cada paquete y sigue recordando todos los demás que hiciste antes, ¿cómo va a interactuar el nuevo código que estás escribiendo con las cosas que escribiste hace una semana? No tengas miedo de buscar cosas que ya hayas escrito y que quizás hayas olvidado.

Finalmente, cuando se acaben los paquetes, generalmente lo dejo pasar unos días, descanse y concéntrese en otra cosa.

Normalmente tengo ganas de volver y comenzar a entrelazar los paquetes y hacer algunas pruebas divertidas, no hay mucho más código para escribir y el objetivo está cerca, eso es suficiente motivación para mí.

Espero que esto te ayude con tus esfuerzos.

Me he siempre hallado que los supuestos originales no mantenga su totalidad y más o menos del diseño original tuvo que ser cambiado en base a la experiencia acumulada mientras se hace la implementación real.

Si considera que su diseño es absolutamente infalible y perfecto después de dibujar algunos cuadros, pero antes de probarlo, lo consideraría un candidato perfecto para algunas implementaciones de proyectos.

El envío es una característica. Si no vas toda la distancia, solo eres un arquitecto.

Creo que el problema está en un objetivo incorrecto. Parece que estableces el objetivo "sistema de diseño". Y luego lo haces bien, y se alcanza la meta. Entonces, una sugerencia es establecer otro objetivo "implementar el sistema", pero luego está más relacionado con la motivación y cómo lo hace.

Hay otra forma que funcionó bien para mí: establecer el objetivo inicial como "entregar el sistema a usuarios específicos" en lugar de "diseñar el sistema" o "crear el sistema". De esta forma, no estará satisfecho hasta que los usuarios obtengan algo valioso. Y lo haces bien desde el principio (incluidas las pruebas y otras cosas modernas y elegantes).

Además de ser una cuestión de motivación, creo que una parte de la solución se puede encontrar combinando el proceso de diseño y codificación. Así es como lo hago principalmente. Básicamente, se trata de implementar los conceptos básicos de su diseño cuando lo pensó, y luego pasar al siguiente paso.

Por ejemplo: si he diseñado mis clases básicas, las escribo y realizo algunas pruebas. Luego, diseñé una base de datos subyacente, la configuré y la probé. A continuación, tengo los métodos y las funciones que necesito para que todo entre / salga de la base de datos. La prueba se realiza más fácilmente ya que tengo mis clases básicas listas. Y cuando finalmente vengo a diseñar la interfaz de usuario, ya tengo todo un conjunto de códigos listo para jugar.

Ahora, esto supone que también diseñas en bloques que están vinculados a través de interfaces. No sé la palabra cara, ya que no soy un programador por educación, pero sabes a lo que me refiero.

Espero que esto ayude.

Luego, simplemente escriba sus ideas de diseño, publíquelas (en un blog), haga todo lo posible para explicar el problema y la solución que ha llegado a otros.

Un truco: ¡ escribe tu explicación del diseño como un programa alfabetizado! :) Luego te ocupas de la parte interesante (tus ideas de diseño), pero en realidad las justificas con el código real que proporciones.

¡Y publique el programa alfabetizado como una presentación de sus nuevas ideas a los demás!

Esto va a sonar trillado, pero solo comienza. Probablemente necesite abrir su entorno de desarrollo, así que hágalo. Probablemente necesitará definir cada una de las clases en su diseño y escribir sus firmas de métodos, así que hágalo. Deberá comenzar a implementar los métodos más importantes, así que hágalo.

Por lo general, por esta época, me he olvidado de que tuve problemas para comenzar y estoy en la zona.

Funciona aproximadamente el 80% del tiempo. Por lo demás, está Tetris.

¡Definitivamente no eres solo tú! De hecho, estoy posponiendo un proyecto en este momento.

Nadie puede motivarte sino tú mismo.

Crea una línea de tiempo realista y desafíate a ti mismo para completar cada sección a tiempo. No tiene nada que mostrar para los proyectos si nunca pasan la fase de diseño.

A juzgar por su pregunta, su problema es que parece estar reinventando la rueda. Si ya ha hecho todo esto, ¿por qué necesita hacerlo nuevamente? ¿No hay un marco para hacerlo por usted? Si no (aunque esto es bastante improbable), ¿por qué no escribir uno?

Una tarea clave en la programación no es hacer cosas aburridas de nuevo , sino hacerlo una vez, hacerlo correctamente y luego reutilizarlo. O incluso mejor: encontrar a alguien que ya lo hizo una vez y correctamente.

Entiendo totalmente de dónde vienes. Es el problema lo que le interesa, y una vez que lo resuelve, la implementación simplemente funciona.

¿Por qué no diseñas la solución y haces que otros la implementen?

Cosas que hago:

• Pon un gran temporizador frente a mí (puede estar en modo inverso, en partes de 1 hora)
• Oblígame a permanecer despierto hasta alcanzar alguna meta (a veces con una cerveza, descubrí que un poco de alcohol ayuda)

Aunque no siempre funciona

PD. Yo trabajo desde casa