Projetos desafiadores que todo programador deveria experimentar (2019)

Artigo original ↗ Discussão no Hacker News ↗

Uma lista popular de “projetos desafiadores que todo programador deveria experimentar” — de editores de texto e sistemas operacionais de brinquedo a emuladores e ray tracers — provoca debate sobre que tipos de projetos paralelos realmente desenvolvem habilidades valiosas. Muitos argumentam que reimplementar sistemas fundamentais aprofunda a compreensão de como software e hardware funcionam, enquanto outros sustentam que a engenharia de software moderna tem mais a ver com escolher bibliotecas, gerenciar complexidade e trabalhar em equipe do que com implementação de baixo nível. A discussão também aborda questões mais amplas sobre equilíbrio entre vida e trabalho, a diferença entre “programador” e “engenheiro de software” e o risco tanto de depender demais de código de terceiros quanto de cair em hábitos de “Not Invented Here”.

Projetos vs equilíbrio de vida / hobbies não relacionados a computadores

  • Alguns argumentam que listas do tipo “todo programador deveria” são irritantes; o trabalho já é exigente o suficiente e o tempo livre não deveria ser preenchido de forma prescritiva com código.
  • Vários defendem hobbies completamente alheios a computadores (marcenaria, jardinagem, música, caminhadas) e lembram explicitamente os leitores de “toque na grama”.
  • Outros observam que atividades ao ar livre/físicas e projetos profundos de programação não são mutuamente exclusivos.

Dificuldade e escopo dos projetos sugeridos

  • Há desacordo sobre se um emulador de Game Boy é mais difícil do que um “pequeno SO”; alguns dizem que o SO é mais difícil, outros que um emulador com temporização precisa e casos de borda é mais complicado.
  • Ray tracers são vistos em um espectro: um ray tracer simples de fim de semana versus sistemas de nível de produção, desenvolvidos ao longo de meses. Da mesma forma, “navegador web” pode significar apenas texto ou um navegador moderno completo.
  • Muitos enfatizam que, para aprender, você pode parar em um subconjunto mínimo e funcional, em vez de buscar fidelidade total.

Ideias adicionais de projetos

  • Sugestões comuns: mecanismo de busca + crawler, CAS (computer algebra system), ray tracer, busca de texto no estilo de mecanismo de busca, wrapper HTTP simples, framework web, clone de Netcat, cache no estilo memcached, mini banco de dados, sistema de arquivos, clone básico do Docker, mini SO via xv6, MMOs simples, robótica, drones, CFD / dinâmica de fluidos, robôs de pêndulo invertido.
  • Sugestões de segurança incluem laboratórios de buffer overflow e SQL injection, exploração com Wireshark e CTFs.

Debate entre programação e engenharia de software

  • Uma corrente: compiladores/ SOs/ editores de brinquedo melhoram as “habilidades de programador”, mas não a “engenharia de software” (seleção de bibliotecas, design em larga escala, manutenibilidade, trade-offs de otimização).
  • Contraponto: você não pode ser um engenheiro forte sem fundamentos sólidos de baixo nível; implementar coisas ensina quando não reinventá-las.
  • Há um intenso vai-e-vem sobre Big-O: alguns dizem que raramente é relevante em apps CRUD; outros culpam o desconhecimento de complexidade por software lento e inchado.

Not Invented Here vs aprender reimplementando

  • Muitos defendem reimplementar editores, busca, bancos de dados etc. como “programação recreativa” e uma forma de entender sistemas em profundidade.
  • Críticos chamam isso de NIH e argumentam que sistemas modernos (por exemplo, mecanismos de busca) não podem ser construídos sensatamente do zero e precisam integrar bibliotecas existentes.
  • Vários destacam o equilíbrio: escrever do zero em projetos de hobby, mas ser pragmático e seletivo com dependências em produção.

Editores de texto, estruturas de dados e usabilidade

  • Debate sobre armazenar texto como arrays versus ropes/piece tables: alguns relatam que editores baseados em arrays funcionam bem até o tamanho de megabytes; outros alertam para edições patológicas e arquivos gigantes.
  • Várias pessoas argumentam que a usabilidade e correção do editor importam mais do que micro-otimizar estruturas de dados internas.
  • Renderizar apenas o texto visível e lidar eficientemente com arquivos enormes e com linhas muito longas são citados como desafios reais.