Uma visão desalinhada: priorizando colegas sobre usuários

Quantas vezes você olhou para o código de alguém e disse:

Eu não estou usando isso porque não parece bem escrito.

E, neste caso, “parecer bem escrito" pode ser um substituto para:

• “parece como eu escreveria”
• “parece fazer sentido para mim”.

Claro – há momentos em que usar código-fonte aberto é arriscado. Sabemos disso pelos vários softwares e serviços que aparecem com vulnerabilidades. Mas, pelo menos para este post, trate-os como a exceção – não a regra.

Isso significa que ficamos olhando para algo que podemos usar, mas optamos por não usar porque não parece estar escrito da maneira que achamos que deveria ser escrito.

Priorizando pares sobre usuários

O desenvolvimento é complicado porque existem várias trocas que nós – ou outro desenvolvedor – temos que fazer sempre que estão construindo algo.

Olhando de dentro para fora

Temos que considerar:

• restrições de tempo e orçamento,
• qual paradigma nos ajudará a entregar um sólido dentro dessas restrições,
• a solução final realmente resolve o problema central,
• haverá custos de manutenção associados à forma como montamos algo?

E a lista poderia continuar.

Considerar os vários aspectos do desenvolvimento e debater as filosofias de como algo deve ser construído não é incomum em nossa indústria

Mas também é demorado, e pode vir a ser um exercício que produz um resultado líquido zero, porque nada vem disso. (Sim, muitas vezes pode ser uma experiência de aprendizado, mas nem sempre.)

Foto de José Alejandro Cuffia no Unsplash

Olhando de fora para dentro

No entanto, na prática:

• O uso do paradigma para construir a solução afeta seu uso do software?
• O software em questão resolve o problema?
• Se você não pudesse ver como o projeto foi montado, que conclusão você tiraria sobre o software?

E o último ponto pode ser o mais crítico no que se refere ao software de código aberto.

Trabalhei na indústria por tempo suficiente para saber que muitas vezes as pessoas querem uma solução funcional que resolva seus problemas e assumem que é construída com segurança.

Os desenvolvedores, por outro lado, examinarão o código mais do que a solução que ele fornece e o problema que resolve.

Se você é um desenvolvedor, há absolutamente um tempo e um lugar para ambos. Mas se você permitir que o último o impeça de enviar o primeiro, talvez nunca consiga algo para os outros usarem porque está muito preocupado com o que seus colegas podem pensar.

E quando você está resolvendo um problema para outras pessoas, elas devem ser as que importam mais do que seus colegas.