Comecei a montar circuitos antes de escrever código. Isso mudou como eu penso sobre software. Quando você conecta dois fios errados numa protoboard, o resultado é imediato — o LED não acende, o sensor não lê, ou pior, você cheira aquele cheiro específico de componente queimando. O feedback loop é brutal e honesto.
Software raramente te dá isso. Você pode escrever um sistema inteiro com abstrações erradas, acoplamento excessivo e nenhuma clareza de propósito — e ele ainda vai "funcionar" por meses antes de alguém sentir o cheiro de fumaça.
Design não é sobre como uma coisa parece. É sobre o quão difícil é mudar ela depois.
A intersecção que me interessa
Sistemas físicos têm restrições concretas: tensão, corrente, temperatura, latência de hardware. Você não pode abstrair um resistor. Mas software tem uma ilusão de flexibilidade infinita que frequentemente vira armadilha — você adiciona camadas de abstração até não saber mais o que está acontecendo na base.
O que hardware me ensinou: entenda o nível abaixo do que você está operando. Não precisa construir tudo do zero, mas precisa saber o que está acontecendo uma camada abaixo da sua. Um desenvolvedor frontend que entende HTTP vai escrever código diferente de um que só conhece fetch(). Um maker que entende circuitos vai escrever firmware diferente de um que só copia bibliotecas prontas.
Por que construo em público
Não é para audiência. É porque documentar força clareza.
Quando eu tento explicar o que fiz em palavras, descubro as partes que não entendo bem. O log de progresso do Lab #01 — aquelas entradas curtas sobre calibrar o PIR ou queimar um GPIO — não são para ninguém ler. São para eu ter que articular o que aprendi enquanto ainda é fresco.
Existe uma diferença grande entre "eu sei fazer isso" e "eu consigo explicar por que fiz assim e não de outro jeito". A segunda forma é o que fica depois de alguns anos.
O que isso muda na prática
Quando começo um projeto agora, a primeira pergunta não é "como implemento isso?" — é "qual é o menor experimento que valida se essa direção faz sentido?". Em hardware isso é montar na protoboard antes de fazer PCB. Em software é escrever a interface antes da implementação.
Design e desenvolvimento, pra mim, são o mesmo processo: reduzir a distância entre intenção e resultado. O meio muda — fios, código, pixels, palavras — mas a questão central é sempre a mesma: isso comunica o que precisa comunicar? Funciona como precisa funcionar? É possível mudar quando as premissas mudarem?
Se a resposta for sim para as três, está bom o suficiente. Publico e sigo.