Proyectos desafiantes que todo programador debería intentar (2019)

Artículo original ↗ Discusión en Hacker News ↗

Una lista popular de “proyectos desafiantes que todo programador debería intentar” —desde editores de texto y sistemas operativos de juguete hasta emuladores y ray tracers— provoca debate sobre qué tipos de proyectos paralelos realmente desarrollan habilidades valiosas. Muchos argumentan que reimplementar sistemas fundamentales profundiza la comprensión de cómo funcionan el software y el hardware, mientras que otros sostienen que la ingeniería de software moderna se trata más de elegir bibliotecas, gestionar la complejidad y trabajar en equipo que de la implementación de bajo nivel. El hilo también plantea preguntas más amplias sobre el equilibrio entre trabajo y vida personal, la diferencia entre “programador” e “ingeniero de software”, y el riesgo tanto de depender en exceso de código de terceros como de caer en hábitos de “No Inventado Aquí”.

Proyectos vs. equilibrio de vida / pasatiempos no informáticos

  • Algunos sostienen que las listas de “todo programador debería” resultan irritantes; el trabajo ya exige bastante y el tiempo libre no debería llenarse prescriptivamente con código.
  • Varios defienden pasatiempos completamente ajenos a las computadoras (carpintería, jardinería, música, senderismo) y recuerdan explícitamente a los lectores que “toquen el césped”.
  • Otros señalan que las actividades al aire libre o físicas y los proyectos profundos de programación no son mutuamente excluyentes.

Dificultad y alcance de los proyectos sugeridos

  • Hay desacuerdo sobre si un emulador de Game Boy es más difícil que un “pequeño SO”; algunos dicen que el SO es más difícil, otros que un emulador con sincronización precisa y casos límite es más duro.
  • Los ray tracers se ven en un espectro: desde un ray tracer simple de fin de semana hasta sistemas de nivel de producción que llevan meses. De forma similar, “navegador web” puede significar solo texto o un navegador moderno completo.
  • Muchos enfatizan que, para aprender, se puede detener en un subconjunto mínimo y funcional en lugar de buscar la fidelidad total.

Ideas adicionales de proyectos

  • Sugerencias comunes: motor de búsqueda + rastreador, CAS (computer algebra system), ray tracer, búsqueda de texto tipo motor de búsqueda, envoltorio HTTP simple, framework web, clon de Netcat, caché tipo memcached, mini base de datos, sistema de archivos, clon básico de Docker, mini SO mediante xv6, MMO sencillos, robótica, drones, CFD / dinámica de fluidos, robots de péndulo invertido.
  • Las sugerencias de seguridad incluyen laboratorios de desbordamiento de búfer e inyección SQL, exploración con Wireshark y CTFs.

Debate entre programación e ingeniería de software

  • Un bando: los compiladores/SO/editors de juguete mejoran las “aptitudes de programador” pero no la “ingeniería de software” (selección de bibliotecas, diseño a gran escala, mantenibilidad, compromisos de optimización).
  • Contrapunto: no se puede ser un buen ingeniero sin bases sólidas de bajo nivel; implementar cosas enseña cuándo no reinventarlas.
  • Hay un fuerte ida y vuelta sobre Big-O: algunos dicen que rara vez es relevante en apps CRUD; otros culpan al desconocimiento de la complejidad por el software lento e hinchado.

No Inventado Aquí vs. aprender reimplementando

  • Muchos defienden reimplementar editores, búsqueda, bases de datos, etc. como “programación recreativa” y una forma de entender los sistemas en profundidad.
  • Los críticos lo llaman NIH y argumentan que los sistemas modernos (por ejemplo, los motores de búsqueda) no pueden construirse sensatamente desde cero por completo y deben integrar bibliotecas existentes.
  • Varios insisten en el equilibrio: escribir desde cero en proyectos de afición, pero ser pragmático y selectivo con las dependencias en producción.

Editores de texto, estructuras de datos y usabilidad

  • Debate sobre almacenar texto como arrays frente a ropes/piece tables: algunos informan que los editores basados en arrays van bien hasta tamaños de megabytes; otros advierten sobre ediciones patológicas y archivos enormes.
  • Varias personas sostienen que la usabilidad y corrección del editor importan más que la microoptimización de las estructuras de datos internas.
  • Renderizar solo el texto visible y manejar eficientemente archivos enormes o de líneas muy largas se citan como desafíos reales.