Minha estrela-guia no software

Prioridades no desenvolvimento de software

1. O software deve ser útil para o usuário final e buscar se tornar um "software que dá para amar"
2. O software deve ser correto (correct). Um software que funciona mal reduz a utilidade que o usuário pode obter
3. O software deve ser manutenível e eficiente. Esse é o critério para evitar desperdício de recursos humanos e computacionais ao tentar extrair mais utilidade do software

O vazio de inverter as prioridades

• Mesmo que uma blockchain não tenha bugs, isso não significa nada se ela for um rugpull
• Mesmo que a linguagem usada seja memory-safe, isso não significa nada se não houver projeto voltado à correção e um processo para ir corrigindo todos os bugs no fim das contas
• Mesmo que o software tenha um belo dossel de abstrações, isso não significa nada se ele funcionar mal e ninguém conseguir fazer manutenção ou adicionar novos recursos

Às vezes eu desanimo, às vezes sigo pelo caminho errado e, às vezes, faço desvios de propósito, mas ninguém pode me fazer confundir meu verdadeiro destino com algo menor.
Eu valorizo minha experiência como desenvolvedor, mas só a valorizo na medida em que ela me ajuda a criar mais software que outras pessoas — e vocês — possam aproveitar.

• O objetivo final é maximizar a utilidade para o usuário final, e todo o resto são meios para atingir esse objetivo
  • Esse é o princípio mais importante no desenvolvimento de software

[GN⁺]

Comentários do Lobste.rs

• Prefiro uma abordagem parecida
  Mesmo ferramentas não “adoráveis”, como uma chave de fenda, podem ser altamente confiáveis por muito tempo. Uma chave Phillips é sempre Phillips, e quando você a tira da caixa de ferramentas não existe 1% de chance de ela ter virado uma chave de fenda comum e você precisar guardar e pegar de novo. O design do cabo também não muda sem parar, e dá para simplesmente usar a ferramenta que você comprou até ela quebrar
  Seria bom se mais softwares fossem assim

  • Fico curioso sobre o que significa “ferramentas não adoráveis, como uma chave de fenda”

• Respeito e agradeço desenvolvedores que seguem o princípio de que “o objetivo final é maximizar a utilidade para o usuário final, e todo o resto existe para esse objetivo”, mas eu mesmo não consigo viver sempre assim. Acho que software tem responsabilidades legítimas para além do usuário final
  Profissionalmente, faço software para sustentar minha família, e embora eu fique bastante do lado dos usuários, no fim minha lealdade é maior à empresa que paga e à minha família.
  Em trabalhos pessoais, o critério é “isso é gratificante para mim?”, e a satisfação artística, estética e intelectual é importante. Em geral isso combina com o benefício do usuário, mas eu também posso julgar mal a utilidade para o usuário e, por exemplo, mesmo que se prove que um menu hambúrguer animado maximize a utilidade, acho que posso exercer meu direito de escolha estética na minha criação e abrir mão dessa utilidade

  • Além desses compromissos, nem sempre dá para definir quem é o verdadeiro usuário final
    Também existe a questão de como encarar casos em que parte do software é deliberadamente tornada pouco amigável para o usuário, para impedir que ele faça alguma besteira absurda que prejudique os usuários do próprio trabalho dele.
    Já discuti deliberadamente esse tipo de mecanismo para manter para sempre em estado de “ainda não” uma certa funcionalidade de relatório, muito vulnerável à lei de Goodhart e com um alcance de efeitos colaterais muito grande, mesmo que os usuários do software a quisessem

• Só ao ver este texto descobri que a Tiger Style agora tem um site

• Fala-se ao mesmo tempo em “ninguém consegue fazer manutenção, muito menos adicionar novos recursos” e em “corrigir todos os bugs”, mas no fim eu realmente não entendo como seria possível corrigir todos os bugs sem um congelamento de escopo

• A frase “não adianta blockchain sem bugs se for um rug pull” consegue colocar três coisas numa sentença só
  Aumentar a eficiência de algo não adianta se isso criar novos bugs, e mesmo assim só adianta se não for um rug pull

• Chama atenção o fato de não haver exigência de que o software tenha de ser escrito necessariamente por humanos. Isso é ainda mais interessante porque, pelo que sei, Kristoff é um dos principais desenvolvedores de Ziglang
  Quero acreditar que dá para fazer software que atenda a esses requisitos mesmo usando desenvolvimento assistido por AI.
  Escrever código manualmente é prazeroso, e terminar também é prazeroso, mas às vezes as duas coisas entram em conflito.
  Desculpem por trazer AI para a conversa, mas é difícil separar isso da relação próxima entre Kristoff e a comunidade Zig, das posições fortes do Zig, e do fato de que, de todo modo, eu continuo evangelizando Ziglang

  • Acho que o terceiro item, na verdade, sugere o lado contrário em relação a esse tipo de ferramenta. O que elas produzem geralmente parece código espaguete impossível de manter
  • Acho que há um motivo para este texto ter saído no blog pessoal do Loris, e não em ziglang.org
    O fato de um projeto ter uma posição clara sobre código baseado em modelos de linguagem de grande escala não significa que todas as pessoas desse projeto compartilhem a mesma posição sobre este projeto ou sobre todos os projetos.
    Não vale só para o Loris individualmente; em decisões assim, o razoável é julgar caso a caso