Executando verificação de segurança...
8

O dev que sabe vs o dev que faz

Como resolvi automação de trading sem usar framework da moda

Tem uma geração de dev que acha que ser bom é saber todas as siglas da moda.
Mas esquece do básico: resolver problema.

O problema real que enfrentei

Precisava automatizar operações numa corretora. Nada de tutorial bonito no YouTube ou curso de "Como ser dev em 30 dias". Era um problema real, com prazo, e que precisa funcionar.

O desafio:

  • API sem documentação decente
  • WebSocket com protocolo proprietário
  • Autenticação complexa com cookies
  • Alternância entre conta demo/real
  • Operações em tempo real
  • Zero margem para erro (é dinheiro real)

O que o "dev que sabe" faria

Ia direto pro Stack Overflow perguntar:

  • "Qual framework usar para WebSocket?"
  • "React ou Vue para o frontend?"
  • "Precisa de microserviços?"
  • "E GraphQL? E tRPC?"

Ia passar 3 semanas escolhendo stack, mais 2 semanas configurando, e quando fosse testar... a API mudou.

O que o "dev que faz" realmente fez

Peguei o básico:

  • TypeScript (porque type safety é vida)
  • Socket.IO (WebSocket que funciona)
  • Axios (HTTP sem firula)
  • Bun (rápido e simples)

Resultado? Sistema funcionando em 2 dias.

// Sem enrolação, direto ao ponto
const trader = new IvestronTrader(email, password);
await trader.authenticate();
await trader.executeOperation({
  direction: "up",
  amount: "20.00",
  currency: "btcusd",
  duration: 60
});

As lições que ficaram

1. Stack não define ninguém. Resultado sim.

Podia ter usado Next.js, Nest.js, tRPC, Prisma, Docker...
Mas o cliente não paga pela stack, paga pelo problema resolvido.

2. WebSocket > Polling

Enquanto outros ficam fazendo setInterval() feito amador, usei WebSocket real.
Resultado instantâneo, sem sobrecarregar API.

3. TypeScript salva vidas

Não é hype. É profissionalismo.
Quando você está lidando com dinheiro real, não pode dar erro de tipo.

4. Validação é sagrada

Dev iniciante acha que validação é perda de tempo.
Dev profissional sabe que é o que separa sistema de gambiarra.

O que realmente importa

💣 Debug às 2h da manhã: Quando o sistema cai e você precisa resolver
🔥 Produção quebrando: Saber onde está o problema em 30 segundos
Performance real: Sistema que aguenta carga, não só demo bonita
🎯 Entregar valor: Código que resolve problema, não que impressiona no GitHub

A realidade do mercado

Cliente não quer saber se você usa React Hooks ou Vue Composition API.
Quer saber se o sistema:

  • ✅ Funciona
  • ✅ É confiável
  • ✅ Resolve o problema dele
  • ✅ Não quebra de madrugada

Para os devs que querem crescer de verdade

Para de colecionar curso e começa a construir coisa real.

Pega um problema real:

  1. Automação de algum processo chato
  2. API que você usa mas que poderia ser melhor
  3. Sistema que quebra na sua empresa
  4. Ferramenta que você gostaria que existisse

E resolve. Sem framework da moda. Sem over-engineering.
Com código que funciona.

Conclusão

Dev bom não é o que manda bem no fórum.
É o que segura o rojão quando o site cai às 2h da manhada.

Quer ser valorizado?
Prática constante > teoria infinita.


Ps: O sistema que criei processa operações financeiras reais há semanas sem falha. Zero frameworks desnecessários, só código que resolve problema.

Carregando publicação patrocinada...
5

Boa provocação! Concordo plenamente com a sua conclusão: "Dev bom não é o que manda bem no fórum. É o que segura o rojão quando o site cai às 2h da manhã." e que "Prática constante > teoria infinita."

No entanto, é importante ter muito cuidado...

Os problemas que você descreveu – "API sem documentação decente", "Autenticação complexa" – muitas vezes são justamente o resultado de projetos onde alguém "apenas fez" sem o devido conhecimento de padrões ou boas práticas.

Debugar um código em produção às 2 da manhã certamente te faz mais forte e experiente. Mas, escrever um código robusto, bem documentado e testado, que não quebra em produção nem com um apocalipse nuclear, requer MUITO conhecimento teórico aplicado de forma consciente.

Cuidado com a armadilha de achar que "basta fazer". A prática é fundamental, mas praticar de verdade não é apenas repetir o que você já está confortável em fazer. É ir além da sua zona de conforto, é enfrentar o desconhecido, experimentar e aplicar conceitos novos. A verdadeira essência da prática é a repetição focada no aprendizado e na melhoria contínua, não apenas na execução.

No fim, para os bons programadores: saber o fazer o feijão com arroz bem feito é o mínimo, mas buscar conhecimento para construir soluções cada vez melhores e evitar que o "rojão" estoure para começo de conversa é que faz a diferença quando a conta chega.

Um abraço e bons estudos!

4

Não só isso, mas o que vai perguntar em algum lugar o que fazer, claramente não sabe também. Podemos dizer que tem 4 grupos de intersecção, sendo que o menor de todos, quase irrisório, deve ser o que sabe e não faz. A esmagadora maioria são os que não sabem e fazem, tudo errado, mas fazem. Tem um grupo relativamente pequeno dos que sabem e fazem. Outro grupo irrisório são dos que não sabem e não fazem, até porque eles desistem.

Existem variações dos que fazem errado e sabem disso, esses têm salvação, porque ou foram obrigados fazer assim, ou estão em processo de aprendizado mas vão chegar lá, sabem que é necessário um processo holístico para se tornar profissional de primeira linha.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

2

Concordo contigo, não é sobre ignorar teoria, mas sobre não se esconder atrás dela. O ponto do post é provocar quem só acumula buzzwords e esquece que código bom é o que resolve. Boas práticas importam, mas prática real também.

O ideal é equilíbrio: teoria que se aplica e prática que entrega

2
1