Despotricar sobre proyectos de programas personales

Al mirar su disco duro y GitHub, puede encontrar cientos de notas y esqueletos de los repositorios de Git. Un verdadero cementerio de proyectos paralelos al programa. El flujo típico de muchos de estos proyectos es: obtener una idea, reflexionar sobre la idea hasta que se vuelva emocionante, eventualmente volverse más emocionante que el proyecto paralelo actual, se capturan notas, se crea un repositorio y el trabajo comienza muy rápidamente como foco y la emoción está ahí. Quizás algunas reescrituras o algunos cambios de dirección. Están comenzando a surgir preguntas sobre si el proyecto vale la pena o “lo que incluso este proyecto debería ser”. Con el tiempo, el entusiasmo disminuye a medida que estas preguntas continúan multiplicándose. El progreso se está desacelerando ya que el camino a seguir parece menos claro que nunca. El proyecto es una puesta de sol con un voto fúnebre de regresar algún día o se deja a un lado silenciosamente cuando algo nuevo y emocionante se reemplaza a sí mismo. ¿Te suena familiar? Tal vez no, pero los principios aquí pueden ayudar.

Este artículo en particular es principalmente una opinión de un ingeniero a otro. Se trata de diseñar el proceso mediante el cual proyecta un proyecto para obtener mejores resultados. Hay muchas razones por las que un proyecto podría eliminarse o eliminarse, y no todas provienen de la falta de una definición clara del proyecto. En el caso de que no esté claro cuál es el proyecto, puede ser útil pensar en él en un sentido más holístico / meta. Hay dos tipos de proyectos personales en su conjunto: demostraciones tecnológicas y productos.

0b10 Tipos de proyectos personales

Probar Rust con un microcontrolador es una buena razón para hacer un proyecto.

Una demostración tecnológica trata sobre la técnica o el cómo. Quizás esté probando un nuevo lenguaje o un nuevo algoritmo. Es bueno que esté medio horneado y delgado, porque no fue diseñado para eso. Fue diseñado para ser hermoso e interesante por dentro. En cierto modo, cuando ingresas, el proyecto está completo porque tienes lo que querías: aprender.

Por el contrario, un proyecto personal de producto se centra en lo que hace y la experiencia como un usuario final interactúa con él. Tal vez tenga un excelente archivo README, una buena experiencia de usuario o haga algo mejor que todo lo demás. El caso es que se centra en el usuario final que lo usa en lugar de en la persona que lo fabrica. No importa cómo se vea por dentro. Podría estar basado en COBOL y ser un entretejido de espaguetis en su interior. El código limpio ayuda con el mantenimiento y el diseño a largo plazo, pero no hace nada por la experiencia del producto.

¡Este robot se ve increíble! Si el cable está completamente suelto y el interior está caliente, ¿importa?

En una palabra, se trata de proyectar la experiencia del proyecto más que simplemente del proyecto en sí. Comienza en un nivel más abstracto, a partir de cómo abordará esta idea en particular. ¿Es una demostración demoníaca o un producto? ¿Es esta una victoria fácil? Con estas cosas en mente, puede comenzar a hacer mejores preguntas. Preguntas que le permiten dibujar cuál será. Al ser intencional sobre el proceso mediante el cual haces algo, estás influyendo directamente en lo que estás haciendo.

Deje que la pregunta correcta sea su guía

Para un producto, debe preguntar quién es el usuario final. Incluso si el usuario es usted, eso no significa que sea estático. Un viejo código incorrecto escrito por usted mismo es completamente desconcertante; ¿Por qué no haría lo mismo un producto antiguo mal diseñado? Un producto se trata del usuario final, no del desarrollador, incluso si esos dos son la misma persona. Otra buena pregunta sería si La-Tecnologia escribiera sobre mi proyecto, ¿en qué se enfocarían y sobre qué escribirían? (Continuaré con “¿incluí imágenes claras de alta resolución para que las usen?”) Como usuario final, ¿cuál es la experiencia deseada y cómo puede ser más simple? Puede ser útil tener en cuenta estas cosas. Invente un plan concreto, no lo cambie ni deje que el alcance se arrastre. Si surgen problemas, vuelva a las preguntas que hizo anteriormente y luego vuelva a definir el alcance. Trate de no distraerse con la tecnología y, en cambio, concéntrese en lo que está tratando de hacer. No esté demasiado encantado con el cómo. Un gran ejemplo de cómo se diseña y fabrica un producto es el Flipper Zero.

Para una demostración técnica, diviértete con ella. ¿Quieres tirar algo más ahí? Tomar el corazón. Tal vez estés tratando de aprender un poco de WebAssembly con Doom. No hay flujo de alcance como no hay alcance. Como se mencionó anteriormente, la atención se centra en el desarrollador, no en el usuario. La usabilidad no es el foco aquí. Las preguntas podrían ser “¿qué sería más interesante” o “cómo puedo omitir una tetera?”

¿Pero que se yo?

Por supuesto, esta es solo la opinión de un escritor y tiene un tamaño de muestra de uno. Es posible que un proyecto esté en algún lugar entre un producto y una demostración demoníaca, o ninguno en absoluto. Sin embargo, la adopción de algunas de estas metodologías ha generado mucha más satisfacción en los proyectos paralelos. ¿Tienes una perspectiva diferente? Cuando logra los objetivos que busca, ¿mueve las publicaciones de destino o da un paso atrás para abordar algo nuevo?

Fernando Román
Fernando Román

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *