DEV Community: Sther

Como eu aprendi a aprender (e por que a IA não veio pra pensar por você)

Sther — Tue, 08 Sep 2026 23:48:00 +0000

Eu entrei na programação de cabeça no finalzinho de 2022. Não foi um caminho gradual, do tipo "vou dar uma olhadinha e ver se gosto", foi mais um "preciso muito seguir esse caminho" dito em voz alta pra mim mesma. Comecei pelo básico: HTML, CSS, JavaScript.

Fui me aprofundando nos conceitos, caí num bootcamp muito bom do Boticário, daqueles que ainda abriam a porta pra você trabalhar lá dentro (confesso que gostaria de ter aproveitado ainda mais aquela oportunidade), mas foi por ali que consegui meu primeiro emprego e comecei a atuar de fato na área.

E aí começa a parte que eu quero contar de verdade: como eu aprendi a aprender e por que isso mudou completamente.

O aprendizado que eu conheci: Stack Overflow e código Frankenstein

Antigamente, aprender programação era mais ou menos assim: você travava num problema, ia pro Stack Overflow, pesquisava muito e rezava um pai-nosso pra alguém já ter resolvido aquilo antes. Se tivesse resolvido, ótimo. Se não, você improvisava.

O resultado eram códigos meio Frankenstein, feitos de pedaços colados com um toque generoso de lógica de negócio no meio. Funcionava? Funcionava. Era bonito? Nem sempre. Mas foi assim que eu e boa parte de quem começou naquela época aprendeu que essa era a forma de aprender: pesquisar, quebrar a cabeça, testar, errar, repetir.

Esse processo lento tinha um valor escondido que eu só fui entender depois: ele me obrigava a realmente entender o problema. Não dava pra pular etapa.

A chegada da IA e o salto de aprendizado

Aí chegou a inteligência artificial. Comecei a usar ativamente em 2024, e confesso que foi um salto. Ainda não era boa o suficiente pra tudo, mas ali eu percebi uma coisa: eu não precisava mais gastar dias inteiros numa única feature.

Só que teve um detalhe importante. Eu ainda me sentia muito júnior no sentido de que estava aprendendo a pesquisar sobre os meus próprios problemas. E como eu ainda não sabia formular bem o que estava enfrentando, os resultados da IA não eram lá muito expressivos. Porque naquela época, e eu sinto que até hoje, vivências ainda contavam muito. A IA te dá o que você sabe pedir, e eu ainda estava aprendendo a pedir.

Foi aí que caiu a ficha:

Se eu não aprender de verdade, eu não vou conseguir resolver os meus problemas.

A IA não ia me salvar de não entender o que eu estava fazendo. Ela ia, no máximo, acelerar a minha ignorância se eu deixasse.

E foi essa percepção que me fez correr atrás do tempo perdido: buscar conhecimento sobre arquitetura e entender de verdade o negócio em que eu estava atuando na época.

"Mas como eu vou aprender se a IA resolve por mim?"

Essa é a pergunta que eu mais ouço, e a resposta é mais direta do que parece: a IA não resolve.

A IA não tem a capacidade de pensar sobre um problema. Se ninguém pensou nele antes, ela não vai pensar por você, não é assim que ela funciona. Ela é excelente em preencher lacunas, sugerir caminhos, otimizar o que já existe. Mas alguém precisa ter desenhado o problema, entendido a regra de negócio e decidido como aquilo começa e como termina.

E é exatamente por isso que eu acredito que o futuro é sobre arquitetura. Sobre entender como as peças se encaixam antes de escrever a primeira linha. Sobre saber desenhar mentalmente onde o problema nasce e onde você acredita que ele deveria morrer.

As arquiteturas que vale a pena conhecer

Quando eu falo em "estudar arquitetura", não é decorar nome bonito pra impressionar em entrevista. É entender a ideia por trás de cada abordagem, porque cada uma resolve um tipo diferente de dor. Aqui vão as principais que eu acho que todo dev deveria ao menos entender o conceito:

Domain-Driven Design (DDD)

Talvez a que mais combina com o meu ponto. DDD é uma abordagem que coloca o domínio do negócio no centro de tudo. A ideia é que devs e especialistas do negócio falem a mesma língua (a linguagem ubíqua), pra que o código reflita a realidade do problema, e não só a cabeça do programador. Conceitos como bounded contexts, entidades, value objects e agregados servem pra organizar a complexidade do negócio. Se você não entende o negócio, você não faz DDD, e é por isso que ela é tão relevante nesse novo cenário.

Clean Architecture

Popularizada pelo Robert C. Martin (o "Uncle Bob"), a Clean Architecture organiza o sistema em camadas concêntricas. No centro ficam as regras de negócio mais puras; nas bordas, os detalhes como banco de dados, framework e interface. A regra de ouro é a dependency rule: as dependências sempre apontam pra dentro. Na prática, isso significa que sua lógica de negócio não deveria nem saber qual banco de dados você usa. Troca de banco, troca de framework, troca de UI, o coração continua intacto.

Arquitetura Hexagonal (Ports & Adapters)

Prima da Clean Architecture, criada pelo Alistair Cockburn. A ideia é isolar o núcleo da aplicação do mundo externo por meio de ports (interfaces) e adapters (implementações). Quer testar sem banco de verdade? Cria um adapter fake. Quer trocar de serviço externo? Troca só o adapter. O núcleo nem percebe. É maravilhosa pra testabilidade e pra manter o negócio desacoplado da tecnologia.

Arquitetura em Camadas (Layered / N-tier)

A clássica. Divide a aplicação em camadas horizontais: apresentação, aplicação/negócio, persistência e dados. É simples, é fácil de entender e ainda é a porta de entrada de muita gente. Nem tudo precisa ser sofisticado; às vezes a camada bem-feita já resolve.

Arquitetura Orientada a Eventos (Event-Driven)

Aqui os componentes conversam através de eventos, em vez de chamadas diretas. Alguém publica um evento ("pedido criado"), e quem se interessa reage a ele. O grande ganho é o desacoplamento e a escalabilidade: cada parte evolui no seu ritmo e você lida bem com processamento assíncrono. Muito comum em sistemas grandes que precisam aguentar volume.

Microsserviços vs. Monolito

Não é bem uma "arquitetura", é mais uma decisão de organização. No monolito, tudo vive junto numa aplicação só. Nos microsserviços, você quebra a aplicação em serviços pequenos e independentes, cada um cuidando de uma capacidade de negócio. Cada abordagem tem seu preço, e entender quando usar cada uma vale mais do que saber a definição de cor.

Além da arquitetura: entender a própria IA

Estudar arquitetura é metade do caminho. A outra metade, no cenário de hoje, é entender como a IA funciona, não pra virar pesquisadora de machine learning, mas pra usar a ferramenta com consciência.

Um exemplo concreto: entender o que é um token. Modelos de linguagem não leem "palavras", eles processam texto quebrado em pedacinhos chamados tokens. Isso define o tamanho do contexto que o modelo aguenta, influencia custo e explica por que às vezes ele "esquece" o início de uma conversa longa. Saber disso muda a forma como você conversa com a ferramenta e o quanto você consegue extrair dela.

Some a isso o hábito de ler documentação (sério), e usar a IA como aliada justamente nos pontos onde a doc é densa ou o conceito é complexo. Deixa a IA te ajudar a entender e otimizar, não a pular o entendimento. A diferença entre as duas coisas é tudo.

O que eu levo como lição

A forma como eu conheci o aprendizado em 2022 não é a mesma de hoje. E tudo bem, sabe? O que não pode é continuar aprendendo do mesmo jeito e achar que o mercado vai esperar. Se você não otimizar a sua própria forma de aprender, o mercado te engole. É o famoso "alguém já está pensando nisso".

Então a lição que eu deixo é essa:

Pense em como resolver problemas, não em como copiar soluções prontas.

Proatividade vai ser a sua melhor amiga nos momentos em que a IA não sabe o que fazer, que são justamente os momentos que definem um bom profissional.

Você não é burra e nem está pra trás. Não é sobre isso. É sobre entender o que pode melhorar e otimizar sempre.

A IA não veio pra pensar por você. Ela veio pra amplificar quem já sabe pensar. Então continua estudando arquitetura, continua entendendo o negócio, continua desenhando o problema do começo ao fim. O resto é ferramenta.

Espero ter dito algo que te dê algum insight.

Câmbio e desligo.

A importância de um HTML semântico

Sther — Wed, 03 Sep 2025 22:40:59 +0000

Olá! Eu sou a Sther e hoje quero compartilhar com vocês a importância do HTML semântico.
Muita gente pensa que frontend é só sair colocando <div> e "ser feliz". Mas, a longo prazo, isso pode se transformar em um verdadeiro pesadelo: código confuso, difícil de manter, prejudicial para o SEO e nada acessível para usuários que dependem de tecnologias assistivas.

Aí que entra o poder da semântica :D

🏷️ O que é HTML Semântico?

Segundo o MDN Web Docs:

Semântica:
Na programação, a semântica se refere ao significado de um trecho de código — por exemplo, "que efeito tem a execução dessa linha de JavaScript?" ou "que finalidade ou função esse elemento HTML tem" (em vez de "como ele se parece?").

Ou seja, não é sobre a aparência de um elemento, mas sobre o significado e o papel que ele exerce dentro da página.

Um exemplo simples:

<!-- Ruim: sem semântica -->
<div>Meu título principal</div>
<div>Seção de artigos</div>
<div>Rodapé</div>

<!-- Bom: com semântica -->
<h1>Meu título principal</h1>
<section>Seção de artigos</section>
<footer>Rodapé</footer>

Com o uso correto, navegadores, mecanismos de busca e leitores de tela conseguem entender melhor a estrutura do conteúdo.

📈 HTML Semântico e SEO

O SEO (Search Engine Optimization) é um dos maiores aliados de quem quer destacar um site nos mecanismos de busca.

Um dos erros mais comuns é usar vários <h1> na mesma página: isso confunde o bot do Google, e ele não sabe qual título considerar como o principal.

Exemplo:

<!-- Errado -->
<h1>Sobre nós</h1>
<h1>Produtos</h1>
<h1>Contato</h1>

<!-- Correto -->
<h1>Minha Empresa</h1>
<h2>Sobre nós</h2>
<h2>Produtos</h2>
<h2>Contato</h2>

A hierarquia correta de cabeçalhos ajuda os “bots” a entenderem a estrutura da informação e melhora o ranqueamento do site.

♿ HTML Semântico e Acessibilidade

A acessibilidade é uma das funcionalidades principais do site, gosto de imaginar que garante que qualquer pessoa consiga navegar pelo seu site, inclusive quem utiliza leitores de tela.

Veja a diferença que uma boa estrutura faz:

<header>
  <h1>Blog da Sther</h1>
</header>

<nav>
  <ul>
    <li><a href="#artigos">Artigos</a></li>
    <li><a href="#sobre">Sobre</a></li>
  </ul>
</nav>

<main>
  <article id="artigos">
    <h2>Por que HTML semântico importa?</h2>
    <p>Explicação do conteúdo…</p>
  </article>
</main>

Com essa organização, o leitor de tela consegue identificar cabeçalho, menu, conteúdo principal e artigos de forma clara.

🔧 ARIA: Quando a Semântica Precisa de Ajuda

Nem sempre apenas as tags são suficientes. Em elementos dinâmicos como carrosséis, abas ou menus dropdown é possível usar atributos ARIA para dar mais contexto às tecnologias assistivas.

<div role="region" aria-label="Carrossel de imagens">
  <button aria-label="Imagem anterior">◀</button>
  <img src="foto1.jpg" alt="Pôr do sol na praia" aria-hidden="false" />
  <img src="foto2.jpg" alt="Montanha nevada" aria-hidden="true" />
  <button aria-label="Próxima imagem">▶</button>
</div>

Aqui, o role="region" indica que se trata de um carrossel, e o aria-label descreve os botões para quem não consegue vê-los. Assim, a experiência de navegação se torna mais inclusiva e acessível.

O HTML semântico vai muito além de um detalhe técnico: ele é a base para sites mais organizados, acessíveis e preparados para o futuro.
Praticar boas escolhas de tags e atributos não só facilita a vida de quem desenvolve, como também melhora a experiência de quem navega.

Obrigada por te lido até aqui, câmbio desligo.

Front-end além de pintar botão!

Sther — Wed, 02 Jul 2025 13:26:24 +0000

Oi, pessoal! Eu sou a Sther, e esse é um blogpost sobre meu aprendizado em usar cache no front-end.

SIM, CACHE NO FRONTEND! Achou que front-end era só pintar botão ou pensar em componente mobile first?

Bom… tambémmm é. XD

Porém temos umas coisas bem legais que podemos aproveitar nele, e uma delas é o ✨cache✨.

Você sabia que ele não vive só no back-end? Então, bora ver como funciona!

Por que usar cache no front-end?

Às vezes, a gente tem aquele dado que não muda com frequência, e queremos evitar requisições desnecessárias toda vez que a página for atualizada.
Aí entra o cache no front, que pode salvar nossa performance e até melhorar a experiência do usuário.

Aqui são algumas formas de fazer cache no front:

ㅤ

🟡 SessionStorage

Guarda os dados enquanto a aba está aberta. É ótimo para dados temporários que não precisam sobreviver a um refresh completo.

Mas, como você acessa isso?

Segue aqui um exemplo:

sessionStorage.setItem('nome', 'Sther');
const nome = sessionStorage.getItem('nome'); // 'Sther'

Quando posso usar isso?

Em um formulário de múltiplas etapas. O usuário pode navegar entre os passos sem perder o progresso, mas se fechar a aba… já era!

🟢 LocalStorage

O meu preferido! Ele persiste os dados mesmo após fechar o navegador. Ideal para lembrar preferências do usuário, temas, login, etc.

Mas como posso acessar isso?

Segue um exemplo, ele é muito parecido com o SessionStorage quando vamos fazer a chamada:

localStorage.setItem('tema', 'dark');
const tema = localStorage.getItem('tema'); // 'dark'

Exemplo real:

A Shopify utiliza isso no processo de checkout (veja aqui). Quando você adiciona um produto ao carrinho, os dados são salvos no LocalStorage, se você recarregar a página, o carrinho continua lá! Isso dá uma sensação de continuidade super fluida.

Outros exemplos de uso que são conhecidos:

Lembrar o tema claro/escuro da aplicação
Salvar o token de autenticação (embora não seja recomendado)
Lembrar filtros ou preferências em uma listagem de produtos

🔵 IndexedDB

É um banco de dados completo no navegador. Suporta dados estruturados e de grande volume, diferente dos dois acima que são key-value simples. É mais complexo de usar porém muito poderoso!

Como posso acessar?

O acesso ao IndexedDB é assíncrono e um pouco mais verboso:

const request = indexedDB.open('meuBanco', 1);

request.onsuccess = (event) => {
  const db = event.target.result;
  // Aqui você pode começar a ler e escrever dados
};

request.onerror = (event) => {
  console.error('Erro ao abrir o banco', event);
};

Exemplo real:

O Google Docs usa IndexedDB para salvar seus documentos offline. Mesmo se você perder a conexão, ele continua funcionando e depois sincroniza com o servidor e também PWAs que precisam funcionar sem conexão!

Olha quanta coisa bacana dá pra fazer além de pintar alguns botões, hahaha

É ÓBVIO que o back-end tem seu papel essencial, mas pensando em performance, experiência do usuário e praticidade, vale a pena explorar o que temos disponível no navegador.

É isso, pessoal, obrigada por terem lido até aqui!

Câmbio e desligo!

Como foi voltar para o desenvolvimento?

Sther — Tue, 03 Sep 2024 17:15:35 +0000

Oi, eu sou a Sthefany Sther, mas você pode me conhecer como Sther ou Stherzada. Neste texto, quero compartilhar minha experiência no mundo do desenvolvimento. Para quem não me acompanha nas redes, vou dar um breve contexto. Eu fazia lives de live coding na Twitch e, diga-se de passagem, sou uma ótima comunicadora. Fui contratada por uma empresa como Tech Community, mas como o projeto não estava avançando, fui realocada como Product Manager. Desde então, fiquei nessa posição por um tempo.

Minha experiência como Product Manager foi muito boa. Eu criava dashboards, organizava tarefas, melhorava fluxos e, claro, ajudava o time da maneira que conseguia. Sinto que essa experiência me enriqueceu muito como profissional, mas ainda assim, eu sentia aquela vontade de estar no meio de campo, criando features incríveis, sabe? Queria codar. Para não perder o ritmo de aprendizado em programação, continuei fazendo live coding, desenvolvendo projetos mais simples, como meu portfólio e o Tindev. Esse conhecimento me permitia ir além do "Jira" no meu trabalho, pois eu sabia um pouco sobre programação.

Até que apareceu uma oportunidade através de um dos viewers da minha live, que hoje, além de parceiro de trabalho, é meu amigo, me deu a chance de voltar para o desenvolvimento.

Fiz a entrevista e expliquei que era Product Manager, mas que desejava muito voltar para o desenvolvimento. Tentei destacar meus pontos fortes, e, cara, essa entrevista foi maravilhosa, pois tive a sensação de que estava seguindo o que realmente queria, e não sendo induzida.

Uma semana depois, fui chamada para trabalhar onde estou hoje, na Carcará. Pretendo muito, no futuro, escrever sobre minha experiência aqui, porque vocês não imaginam o quanto eu mudei nesse tempo. A Carcará é uma empresa da Deco, onde implementamos e-commerce e buscamos a melhor performance possível.

Meu onboarding foi diferenciado; conheci quase todos pessoalmente por conta do Team Building, o que me deu uma noção melhor de quem é quem. Depois de todos esses processos, hoje estou implementando uma loja que, até agora, não caiu a ficha que estou fazendo.

O resumo disso tudo é que, se você tem um desejo e vontade, corra atrás. Mostre-se de alguma forma, seja através de código de aprendizado ou de uma grande implementação, documentando seu processo. Deixe que o mundo te enxergue de alguma maneira. Não há receita certa para o sucesso, mas existem formas de alcançá-lo.

Obrigada por ter lido até aqui. Câmbio, desligo.