O problema que você resolve é mais importante que o código que você escreve

Os programadores parecem ter esquecido que o verdadeiro objetivo do software é resolver problemas reais.

Há 50 anos, em 1968, foi organizada uma conferência de trabalho sobre engenharia de software , que foi organizada com o apoio do Comitê de Ciências da OTAN. Naquela época, as pessoas começaram a perceber que o software estava se tornando uma parte fundamental da sociedade. No entanto, também se tornou muito difícil de entender. Após esta conferência, a programação se tornou uma indústria. E começou a deixar de controlar os empresários.

Não importa para que lado a programação tenha sido desde então, ainda há um problema com a separação entre negócios e desenvolvimento de software - ou "ENGENHARIA", como a conferência chamou pela primeira vez. Se os desenvolvedores estão muito focados no desenvolvimento, eles podem perder o objetivo do software que escrevem. Eles podem não encontrar soluções ocultas que não exigem nenhum código.

Aqui está um exemplo.

Houve uma startup que criou um dispositivo que permitia a uma pessoa abrir a porta de sua casa via Bluetooth. Um widget foi usado como interface visual, visível mesmo quando o telefone estava bloqueado. Ele tinha um único botão chamado "Abra a porta".

Quando o usuário chegou mais perto de casa, ele pegou o telefone, encontrou o widget e pressionou um botão para abrir a porta.

Alguém olhou para ele e perguntou:

Se usarmos o Bluetooth e nosso modelo de negócios permitir que qualquer pessoa que possua um telefone entre na casa, por que devemos forçar alguém a pegar o telefone e pressionar o botão? Deixe a porta abrir quando o dispositivo se aproximar de 1 metro. Portanto, não precisamos pagar pelo desenvolvimento e programação da interface visual!

Essa história do Bluetooth é um ótimo exemplo de foco restrito: o objetivo era abrir a porta com o mínimo esforço. Não faz sentido desenvolver uma interface visual se os sensores forem sem fio.

Se você souber quais objetivos a empresa deseja alcançar e o que é de valor para o usuário, poderá combinar esse conhecimento com seu conhecimento de tecnologia. Somente então você terá informações suficientes para encontrar as melhores respostas e concluir que o produto não precisa de uma interface.

Este é um ótimo exemplo de como resolver um problema técnico sem precisar escrever nenhum código adicional além do código de desbloqueio. No entanto, como no Tech Debt , nada deve justificar a escrita de códigos de merda.

Nem todo código vale a pena escrever.

Às vezes, corrigir um erro grave pode não ser uma prioridade. Se você tiver uma troca de criptomoedas e o sistema tiver efetuado o mesmo pagamento duas vezes, a intervenção humana poderá ser a melhor solução em termos de custos e benefícios, se o custo de resolver esse problema for alto.

Essa troca entre Seriedade e Prioridade me lembra o modelo que meu colega recentemente me mostrou. É chamado de “Matriz de Prioridade”, um modelo bidimensional que pode ser usado para priorizar erros com base no número de usuários que eles afetam e na gravidade.



O problema de re-depósito descrito acima se enquadra na categoria de inconveniência que afeta um usuário. Portanto, prioridade 3.

Nem todo bug vale a pena consertar.

Isso é muito comum quando os desenvolvedores tentam escrever um script para tudo. No entanto, algumas tarefas repetitivas não valem a pena automatizar. Você não precisa gastar tempo programando scripts para ocultar o conhecimento necessário sobre como a equipe principal funciona.

Há uma diferença entre encapsular lógica complexa e abstração de conhecimento útil. Às vezes, a informação precisa ser esclarecida. Se você abstraí-los, eles podem ter o efeito oposto e serão mais difíceis de entender.

É mais útil usar alguns tipos de comandos de baixo nível na CLI do que um comando de alto nível que abstrai conhecimentos, como o Git .

Alguns anos atrás, eu estava trabalhando em um projeto usando entrega incremental . Era um sistema de verificação de identidade que exigia que o usuário fornecesse alguns dados pessoais para verificação por um fornecedor terceirizado.

Esse era um recurso especial de validação de campo que a equipe queria criar. No entanto, o histórico de auditoria foi priorizado no planejamento de cada sprint, à medida que o prazo se aproximava. No final, a equipe descobriu que não havia sentido em ter uma validação bizarra.

E aqui está o porquê: a verificação era obrigatória!

É do interesse do usuário fornecer informações confiáveis. Se o usuário fornecer dados incorretos, eles não serão verificados e não poderão usar o sistema. Além disso, a maioria dos navegadores suportava a validação HTML padrão, o que era muito bom.

Na pior das hipóteses, os usuários que não pudessem verificar a si mesmos poderiam ligar para o suporte para verificar tudo manualmente.

Nem toda função vale a pena programar.

Se você é um desenvolvedor e entende o problema que está tentando resolver, pode criar um código melhor e, às vezes, pode lidar sem o código. Você não é um " macaco de código " pago para escrever caracteres na tela. Você é um profissional que é pago para resolver problemas.

No entanto, se você tentar resolver todos os problemas usando a tecnologia, sem pensar, terá problemas para entender o que é valioso para o cliente e ter ótimas idéias.

Seu objetivo e o código que você escreveu é criar valor e tornar o mundo existente um lugar melhor, e não satisfazer sua visão egocêntrica de como o mundo deveria ser.

Há um ditado: "Se você tem apenas um martelo, tudo parece um prego".

É melhor ter um prego primeiro para poder considerar a necessidade de um martelo.

Ou seja, se você precisar de uma unha primeiro.

Obrigado por ler o artigo!

Se eu tiver erros na tradução, escreva sobre isso nos comentários!
Também verifique meu site para acesso rápido a perguntas e respostas javascript - Perguntas e respostas sobre JavaScript

Serei muito grato e grato a você)

Estou no twitter e vk

Muito obrigado pela atenção!