Como desarrollador solitario, ¿cómo se organizan de forma sistemática?

• Cuando trabajaba con un equipo, los objetivos de corto plazo como Scrum y un backlog de trabajo estructurado realmente ayudaban a mantener el enfoque y hacer seguimiento de lo que había que hacer
• Pero al desarrollar en solitario no he logrado encontrar un enfoque adecuado, y a menudo termino desviándome y perdiendo de vista el objetivo
• ¿Qué herramientas y técnicas usan ustedes para mantenerse fieles a sus metas?

CharlieDigital

• Usar una libreta de papel
• Cuando no hay necesidad de compartir información, no hay nada mejor que una libreta para desplegar todas las ideas y repasarlas una y otra vez. No hace falta iniciar sesión, la puedes llevar a cualquier parte, sentarte en una banca a pensar ideas, o ir al gimnasio y anotarlas.
• Basta con escribir los objetivos del día en una checklist e ir marcándolos uno por uno. Como no hace falta compartir el estado con otras personas, tampoco necesitas algo como GitHub Projects

olooney

• Usa un archivo TODO.md
• Escribe una lista en GFM (GitHub flavored markdown) así:

    1. [X] Dockerfile  
    2. [ ] Bulk Inference  
    3. [ ] CLI  
    4. [ ] Logging  
  

• Arriba pone una sección llamada “backlog” para ideas futuras, una sección “bugs” para errores por corregir, y una sección sin nombre con los elementos actuales
• Cuando llega a un milestone, como un release, elimina todos los elementos completados

jasonb05

• Escribe mucho para su yo del futuro
  1. Trello con columnas por semana, mes, trimestre y año
  2. Libreta abierta al lado del mouse
     2a. Página izquierda: checklist diaria de tareas con pluma y papel. (2 a 3 líneas por día)
     2b. Página derecha: apuntes sueltos, bocetos, notas adhesivas, etc.
  3. Un diario de desarrollo donde registra investigación, URL, papers, pensamientos, ideas, progreso, extensiones, etc.
  • Todos los proyectos de GitHub tienen una carpeta dev/ para estas notas, y los archivos se nombran yyyymmmdd-n.txt
  • Según haga falta, crea un archivo nuevo por proyecto cada día
  4. Notas adhesivas amarillas para ideas temporales (pegadas en la parte inferior de la pantalla, la libreta o el pizarrón)
  • Por lo general con aforismos que señalan la dirección correcta del proyecto (por ejemplo: "nadie jamás va a rtfm")
  5. Pizarrón, columnas por proyecto, impresiones + imanes (gráfica mensual del progreso del proyecto), notas adhesivas, ideas para proyectos futuros y toda clase de cosas
• Intenta comunicarse en exceso con su yo del futuro
  • Eso le ayuda a ordenar lo que está pensando ahora: expectativas, progreso, obstáculos, etc.
  • El obstáculo soy yo, no el trabajo
  • El trabajo por lo general se dibuja en números después de “pensar con fuerza”
• Lleva 8 años trabajando así por su cuenta
  • Desde principios de los 2000, cuando hacía el doctorado, usa archivos .txt en un directorio /dev como diario de desarrollo en tiempo real. Eso le ha ahorrado incontables horas (grep).
• Ah, y hace lo mismo todos los días. Casi todos los días
  • Por ejemplo: soporte al cliente, promoción, escritura, programación y... sin pensarlo demasiado, solo hace esa tarea y luego pasa a la siguiente

liampulles

• Al trabajar en proyectos paralelos, el "desarrollo guiado por Readme" ayuda a mantener la motivación y limitar el alcance

Tehnix

• Define metas diarias/semanales/mensuales y las organiza con apps como Linear, Todoist o Notion
• Las metas mensuales son de muy alto nivel y son pocas (por ejemplo: "hacer un PoC", "rediseñar y relanzar el blog")
• Las metas semanales son más específicas y acotadas (por ejemplo: "decidir un enfoque para llamar Rust desde código Swift" o "terminar el diseño y el estilo del post")
• Las metas diarias son muy específicas (por ejemplo: "configurar el pipeline de UniFFI para generar bindings de Swift" o "implementar el nuevo tema en todas las páginas del blog")
• A veces aparecen tareas nuevas durante la implementación y entonces mueve la meta diaria al día siguiente
• Hasta ahora este método le ha servido para mejorar el enfoque, y elige las metas diarias según el foco semanal entre muchas tareas/issues en curso en varios proyectos
• Si configuras cada trabajo en curso como proyecto y asignas prioridad en cuanto agregas una tarea, puedes ver fácilmente de un vistazo proyectos grandes y pequeños, tanto en marcha como futuros
• Le gusta el papel, pero solo para cosas temporales. Prefiere un sistema digital que pueda añadir fácilmente desde el teléfono cuando se le ocurre una idea estando en movimiento. Además, escribir con teclado es mucho más rápido, y usa varias tareas como depósito de información mientras trabaja o investiga algo

OogieM

• Lo organiza en carpetas dentro de un Obsidian Vault
• Las carpetas contienen elementos comunes similares
  • Una nota Kanban con el plugin Kanban para la estructura de pantallas (qué funciones o actividades hay en cada pantalla)
  • Una nota de roadmap con detalles de cada función
  • Notas generales con varias tareas de esa app o componente
• Usa el plugin de tareas para seguir específicamente en qué está trabajando
  • Esa carpeta también contiene documentación adicional, como capturas de pantalla, referencias y otras notas relacionadas con esa app en particular
• Sus proyectos son un conjunto de programas para gestionar ganado y el registro de razas raras
  • Por eso tiene la app Farm Mobile (Android), Farm Desktop (Python), la web del registro (Flask), la app de escritorio del registro (Python) y el esquema de base de datos (SQLite), todos en repositorios separados de GitLab
• Ahora se han sumado 3 colaboradores, y comparte el Obsidian Vault mediante Obsidian Sync. Su sistema de trabajo individual terminó ampliándose para soportar trabajo en equipo

robomartin

• Lleva años usando archivos de texto simples inspirados en Kanban
• Maneja todo así, desde proyectos pequeños hasta proyectos de millones de dólares
• Cada proyecto tiene un archivo de log principal y archivos específicos por disciplina (electrónica, mecánica, óptica, manufactura, pruebas, etc.)
• El contenido del archivo

  <nombre del proyecto> archivo de log  
  -------------------------------- WORKING ON NOW   
  <tarea actual>  
  
  -------------------------------- TO DO   
  - <cada tarea empieza con un guion>  
    - <indentar subtareas o notas relacionadas>  
  
  -------------------------------- IDEAS  
  <notas en formato libre>  
  
  -------------------------------- RESOURCES  
  <recursos en formato libre>  
  
  -------------------------------- DONE  
  <mover aquí lo completado>  
  <dejar timestamp si se quiere>  
  

kkfx

• Se organiza con Emacs/org-mode/org-roam
• Usa org-agenda de la nota del año actual, con una nota por día y un directorio por año dentro de un directorio común de org-roam, dividiendo los archivos por hora
• Así org-agenda tiene menos archivos que recorrer y en la nota resumen anual disminuye el material de larga duración que se arrastra de un año al otro

makz

• Antes de salir del trabajo deja comentarios en el código: "estoy haciendo esto ahora mismo, y para que funcione necesito hacer A, B, C..."
• La próxima vez que abre el editor sabe exactamente qué tiene que hacer

qntmfred

• Tiene una plantilla de rutina diaria en Obsidian Daily Note. Eso lo hace enfocarse y entusiasmarse con el día
• La primera [X] que se da a sí mismo cada día es completar la checklist de la rutina diaria
  • Una victoria gratis para arrancar un día productivo
• En realidad redacta la mayoría de sus notas usando dictado por voz de Windows, así que es parecido a hacer un standup diario
• Además, suele hacer livestream todo el día, aunque el único espectador sea él mismo (claro, como es un livestream privado, lo hace a diario, para tener un recordatorio de qué estaba haciendo o pensando hace unos 20 minutos antes de perderse en algún agujero de conejo. De hecho, Windows Recall también está bien)
• Su día transcurre de forma parecida a cuando trabaja con otras personas en una organización de dos o más integrantes (o sea, reuniones)

mentos

• Un tablero de Trello con tres listas: Done/Doing/ToDo
  • Hace una lista de todo lo que hay que hacer
  • Le asigna prioridad
  • Mueve el elemento de arriba a la lista de tareas en curso y empieza a trabajar
  • Cuando termina, lo mueve a completado. Toma el siguiente elemento de la lista de tareas y repite
• Usa otras listas de Trello para gestionar tarjetas de investigación o para sacar de ToDo funciones que no hacen falta en la v1

macNchz

• Le gusta trabajar de forma parecida a como lo haría con un equipo pequeño
  • Gestiona issues de GitHub organizados de forma flexible por milestones, con checklists llenas de elementos
    • Como está cerca del código, es fácil dejar notas para recordar dónde se quedó con links a números de línea, bloques de código copiados/pegados o borradores de PR enlazados
    • Es muy fácil acceder desde cualquier dispositivo, así que si se le ocurre una idea o recibe un correo sobre un bug, puede crear un issue rápidamente al vuelo desde el teléfono o desde otro dispositivo que no sea el de desarrollo
    • También es sencillo invitar a otra persona en el momento adecuado y ponerla a trabajar de inmediato
    • Tiene una buena API y varias integraciones útiles (por ejemplo, crear o enlazar issues directamente desde un sistema de seguimiento de errores)

rerdavies

• Usa GitHub Projects
  • No necesariamente lo recomienda con entusiasmo
  • Pero gestionar listas de tareas y bugs no es precisamente ciencia espacial
  • Ha usado soluciones de gestión de proyectos que cuestan cientos de miles de dólares y eran mucho peores
• Aunque GitHub Projects funcione raro y nadie lo quiera mucho, para lo mínimo alcanza
  • Hay muchas cosas que uno pensaría que deberían poder automatizarse
    • Cosas como pasar a un nuevo sprint con unos pocos clics, sin tener que rehacer manualmente todas las consultas del tablero Scrum
  • Pero sí te deja hacer lo que quieres hacer
    • Eso es mucho mejor que vivir atrapado en un proceso rígido definido por otra persona
    • En cierto sentido, el minimalismo podría ser una ventaja
• Mentalmente, esto es un problema de gestión de listas. No es tan complicado. Y GitHub Projects gestiona listas perfectamente bien
• Una razón por la que recomienda GitHub Projects sobre listas en papel o tarjetas es que
  • Los usuarios pueden ver públicamente cómo se están manejando los reportes de bugs y las solicitudes de funciones
  • Además, es muy fácil convertir lo publicado en los foros de discusión en reportes de bugs o en trabajo de desarrollo (aplazado o activo)
• Aplican las reglas generales de Scrum. Todos los bugs se corrigen antes de empezar trabajo nuevo, y una tarea solo pasa a completada cuando está totalmente terminada
• Necesitas una lista. A él le gusta superponer una estructura de sprint encima de las tareas porque aporta milestones útiles para actualizaciones intermedias y releases continuos

leros

• Distingue entre sus roles de product manager, project manager, desarrollador de software, marketing, operaciones del negocio y líder general del negocio, y desempeña solo uno a la vez
• Por ejemplo,
  • Puede sentarse como líder general del negocio y decidir la dirección estratégica que quiere
  • Luego ponerse el sombrero de product manager y decidir qué construir
  • Después gestionar ese proyecto y priorizarlo
  • Luego actuar como product manager/diseñador para concretar las funciones priorizadas
  • Después apartar tiempo completamente separado (normalmente un día entero) para desarrollar la función
  • Cuando la función sale, se pone el sombrero de marketing y hace el marketing del producto correspondiente
  • Ese es como el ciclo de vida de desarrollar una sola función
• Lo peligroso es saltar entre todos los roles al mismo tiempo. Eso puede hacerte menos productivo
• Hay momentos para pensar estratégicamente, momentos para ser creativo y momentos para simplemente ejecutar, y cada uno requiere un espacio mental distinto
• Hace toda la planeación en Notion usando varios tableros Kanban distintos según el propósito

urda

• Usa un sistema de “conocimiento” en cascada:
  • Anota pensamientos aleatorios, notas, recortes, diagramas, etc. en una libreta Moleskine de bolsillo
  • Eso eventualmente termina convirtiéndose en un “ticket” en el issue tracker, o en una “wiki” o “actualización de wiki” en su servidor wiki
  • Eso a su vez termina en snippets, notas de configuración, documentos de registro, archivos históricos, runbooks, etc.
• Al final, mantener la documentación al día o meter algo en el backlog correcto cuando aparece un issue se volvió algo “natural”

[xguru]

Creo que, para cualquier cosa, la mejor forma es la que te resulte cómoda convertir en rutina. Si hay mucho trabajo previo y abrir un documento de gestión para empezar te toma tiempo y da flojera, poco a poco terminas alejándote de eso. Incluso sacar y abrir una libreta que tenías guardada en algún lado después de ordenar el escritorio puede sentirse como otro trabajo.

En ese sentido, casi siempre tengo VS Code abierto tanto en la computadora de mi casa como en la del trabajo, así que parte de mi rutina diaria es escribir y borrar cosas en un todo.txt que dejo abierto ahí arriba. Me gusta porque se vuelve una rutina y no tengo que pensar qué abrir. El contenido lo sincronizo con un repositorio privado de GitHub.

[mytory]

Yo anoto todas las tareas del proyecto en Google Sheets, dividiéndolas en bloques de 30 minutos a 1 hora, y registro cuánto tiempo me tomó completarlas. Así es más fácil estimar y también se siente bien ir resolviéndolas una por una.

[devsepnine]

Creo que principalmente uso Trello, hago una lista y organizo la descripción...
Como se puede acceder desde cualquier lugar...

[tested]

Yo creo un servidor personal en Discord, lo organizo por categorías/canales y lo uso para cosas personales como TODO, etc.

[porteleaf]

Probé varios métodos, pero todavía no logro establecerme con uno solo. Actualmente tomo notas en Obsidian y, para el trabajo práctico, voy escribiendo en una libreta legal cuando hace falta.
Como estas también son notas para reemplazar la memoria fugaz, siento que muchas veces, con el paso del tiempo, termino olvidando qué fue lo que anoté...
Voy a intentar reorganizar mi sistema tomando este texto como referencia...

[hwan0317]

Parece contenido útil para gestionar la motivación o la planificación en general, incluso si no necesariamente desarrollas en solitario.