DEV Community: Jessilyneh

30 days of Javascript no LeetCode

Jessilyneh — Sun, 19 Jan 2025 00:52:21 +0000

No texto anterior, eu comecei a usar o site Hacker Rank para praticar algoritmos e comentei sobre isso com o meu namorado. Ele sugeriu testar o LeetCode porque eu não precisaria usar Node.js e poderia me concentrar apenas no desafio do algoritmo. Já estou no segundo dia usando o LeetCode.

Reforço: esses textos dentro de series, tipo esse e o do System Design, sou eu trocando o twitter/x e bluesky pelo dev.to . Dito isso, eu vou falar de forma despreocupada, tipo "mesa de bar". Por favor, levem isso em consideração hahaha

...

Eu confesso que sempre tive a impressão que LeetCode era coisa de gente muito inteligente e que definitivamente isso não era pra mim, o pensamento de "brucutu ignorante" que boa parte de nós, devs, temos com as coisas que escolhemos não conhecer e apenas julgar hahaha

Eu falo isso porque foi um julgamento que eu fiz com base no que eu via dos meus colegas no Twitter - e sabemos que "ás vezes" homens gostam de fazer o equivalente a "quem tem a p*ca maior" usando salários, hobbies tipo café, empresa que trabalha e inclusive, algumas "demonstrações intelectuais" como desafios super complexos de algoritmos.

Eu sei que praticar desafios de algoritmos ajuda em entrevistas de emprego, mas, como desenvolvedora que trabalha no Brasil, eu nunca precisei fazer um teste de algoritmo e ficar discutindo a complexidade e etc - nunca fiz teste pra empresas que exigem essas coisas e confesso que eu peguei ranço por conta dos meus colegas de rede social vestindo um monóculo e enrolando a ponta do bigode cada vez que iriam falar de onde trabalhavam e sobre os testes de algoritmos hahaha

Mas ei, se você também criou esses julgamentos, estou aqui pra te falar que resolver desafios de algoritmo é super legal, não é uma coisa para semi deuses e não vai te tornar uma pessoa de monóculo - exceto se você já tiver tendência a "medição de p*ca", mas ai a culpa não é da plataforma.

Como é o LeetCode

Sim, tem a parte dos desafios super difíceis. Mas essa não é a plataforma toda. Inclusive, mesmo se você for iniciante em Javascript (já precisa saber programar, menos que isso você não vai conseguir aproveitar bem e vai se frustrar) o LeetCode é sim para você.

Ou então, se você já é dev pleno ou senior mas não tem tempo e nem interesse de ficar gastando horas e horas com coisa que você nem usa no trabalho, saiba que em 10 minutos você resolve um desafio no LeetCode e vai aprender coisas legais.

Minha sugestão é você começar pelo "30 days of Javascript" na plataforma. O único ponto é que precisa saber inglês ou pelo menos, ficar traduzindo o que não entender (acho que tem tradução direta da pagina no navegador também, mas não testei). Mas tirando esse ponto do idioma, os desafios desse plano de estudos são bem possíveis de serem feitos em poucos minutos.

A carinha do plano de estudos e os dois exercícios que já resolvi

Mesmo se você já for pleno ou senior, porém não tiver costume com desafios de algoritmo, também sugiro que comece por esse plano de estudos. Sim, você vai achar as coisas fáceis mas vai ver que tem oportunidade de aprender principalmente a pensar sobre a estrutura de como solucionar um problema e de se acostumar a ter 3 ou 4 formas de resolver o mesmo problema - e saber o porquê de cada escolha.

O desafio está descrito na aba "description" e é interessante ler tudo (eu fui nessa do "ah, é fácil" não li tudo e fiz errado na primeira haha Ah, o mercado cria muito mal habito na gente) para não fazer nem a mais e nem a menos do que realmente foi pedido.

Mas a minha parte preferida fica na aba "editorial", que é a coisa mais valiosa do LeetCode, na minha opinião:

Aqui, você vai não apenas entender qual o objetivo do teste mas aprender sobre o conceito em si e poxa, falar de closures em Javascript me deixa emocionada. E curti mais ainda que essa parte trouxe 4 formas possíveis de solucionar o desafio, por ordem de performance e simplicidade, além de trazer um conteúdo super interessante fazendo um comparativo de classes no Javascript (que não são classes de verdade, como no Java, porque o construtor é uma função) com Closures.

Um pequeno parêntese para falar sobre closures

Closure é uma funcionalidade bem poderosa e interessante, porém, dificilmente usada porque as pessoas sempre falam que "não precisa", que é "perigoso", que "não é performático" mas na verdade é porque acabamos vendo muito projeto de mercado usando JavaScript estritamente com orientação a objetos, que "não complica".

Não tenho nenhuma objeção contra uso de paradigma de orientação a objetos com JavaScript, a linguagem inclusive dá suporte para esse comportamento, milhares de empresas usam dessa forma e é prático porque é mais familiar para quem vem de Java ou C#. Porém, saibam que tem muito comportamento interessante do JavaScript que deixamos de aproveitar porque acabamos usando ele como um Java com sintaxe mais simples - e ai vem as reclamações de comparar coisas totalmente diferentes.

Mas eu falarei sobre isso num artigo sério que vou publicar na próxima semana, o "Javascript Idiomático". Voltando ao assunto:

Medidor de runtime

Depois de submeter o seu teste (e é bem legal que tem casos de teste para garantir que você tá atendendo ao cenário pedido) você vai ver o quanto performática foi a sua solução e quantas outras pessoas também elaboraram soluções com o tempo aproximado de execução que o seu levou para ser executado. Isso é muito legal porque é possível olhar quais foram as outras soluções mais rápidas de execução e expandir o seu repertório sobre formas variadas de resolver o mesmo problema.

Concluindo...

Repetindo: LeetCode não é para gênios, é para qualquer pessoa que trabalhe com programação e queira aprender mais. É uma plataforma legal para estudar mesmo sem ter ambições de se inscrever em processos seletivos que usem desafios de LeetCode, e serve bem tanto se você for junior quanto se for senior cansado e ocupado que não tem tempo pra nada. 10 minutinhos você tem sim haha Nem que seja pra ir conhecer e ver que não é algo fora da sua realidade.

Eu não to ganhando absolutamente nada pra recomendar isso aqui e nem quero, estou falando porque foi algo que eu realmente achei vantajoso. Então, de uma chance e vai conhecer o 30 days of Javascript!

System Design: encurtador de URL parte 1

Jessilyneh — Sat, 18 Jan 2025 03:33:18 +0000

Continuando a série que eu registro meus estudos de system design, hoje vou planejar como eu criaria um encurtador de URL em 45 min (não codar, planejar como faria) e comparar minha resposta com o livro. Eu já planejei sistemas bem mais complexos, porém, nunca em tão pouco tempo.

O escopo que eu tenho neste momento é nenhum quase hahaah o exercício só pede para criar um encurtador. Então, eu vou usar a ajuda da internet, já que não tenho um entrevistador.

Contador rolando, 45 minutos setados, vou começar!

Entendimento de requisitos

Como não tenho alguém para me entrevistar, vou tentar pedir ajuda do Perplexity porque, na internet, só tem respostas prontas e não é essa a minha ideia.

Minha primeira dificuldade foi que eu definitivamente não estou acostumada a fazer perguntas de pronto e fiquei pensando o que escreveria. Só nisso eu perdi 8 minutos hahah

Para vocês acompanharem a "entrevista", segue o prompt que eu escrevi:

Olá, boa noite! Pode me ajudar a estudar system design? Eu
 preciso que você se comporte como o entrevistador que me
 pediu para desenvolver um encurtador de url.
A ordem das etapas desse teste de system design será a
 seguinte:

> Requisitos 
> Design de interface
> Estimativa da escala do sistema
> Modelo de dados
> 5-6 blocos de design alto nível
> 2-3 componentes com detalhes
> Identificar possíveis gargalos

Neste primeiro momento, eu vou validar com você algumas
 perguntas sobre os requistos, ai você me responde como se
 fosse o entrevistador, sem me entregar a resposta
 completa, apenas respondendo o suficiente para eu colher
 insumos apenas para essa primeira etapa de entendimento
 de requisitos, tudo bem? 
Farei outras perguntas também, conforme a sequencia de
 etapas que te passei.
Se puder, poderia também me dar um feedback se as minhas
 perguntas foram boas? 
Mas preciso que seja bem pragmático e que exija de mim
 como um desenvolvedor senior, e que traga os pontos que
 poderia melhorar, sem adiantar etapas de perguntas.

Por exemplo, se estou na etapa de levantamento
de requisitos, trazer feedback que preciso pensar em
complexidade de desenvolvimento poderia ser algo para a
etapa seguinte, de escalabilidade do sistema.

Minhas perguntas para a etapa de requisitos:
- Esse encurtador de URL deve gerar URLs que o usuário
 pode customizar tipo bit.ly/customizar-url ou vai apenas
 encurtar, tipo bit.ly/ss7g9dv ?
- O serviço deve fornecer analytics dos clicks na URL?

A resposta que eu recebi do Perplexity e poxa, eu realmente fiquei surpresa como é legal para praticar com ajuda, na ausência de alguém para treinar comigo. Vou chama-lo de "entrevistador" no resto do texto:

O Entrevistador:

Customização de URLs
Resposta: Essa é uma pergunta muito relevante.
É importante entender as expectativas do usuário em 
relação à personalização. Pergunte-se: qual é o valor que
 a personalização traz para os usuários? Isso pode
 influenciar a adoção do serviço e sua diferenciação no
 mercado.

Analytics dos Clicks
Resposta: Essa questão é crucial, pois a análise de dados
 pode ser um dos principais atrativos do seu serviço.
 Considere quais métricas seriam mais valiosas para os
 usuários e como você planeja apresentar essas
 informações. Além disso, pense em como isso afetará a
 arquitetura do sistema e o armazenamento de dados.

Feedback sobre suas perguntas
Clareza e Direcionamento: Suas perguntas são claras e
 diretas, abordando aspectos fundamentais do sistema. Isso
 é positivo, pois demonstra que você está focando nas
 funcionalidades essenciais.

Exploração de Funcionalidades: Considere expandir suas
 perguntas para incluir aspectos como segurança (por
 exemplo, proteção contra spam), integração com outras
 plataformas ou serviços, e limites de uso (quantidade de
 URLs encurtadas por usuário).

Complexidade de Desenvolvimento: Lembre-se de que cada
 funcionalidade adicional pode aumentar a complexidade do
 desenvolvimento. Pense em como cada requisito pode
 impactar a escalabilidade e a manutenção do sistema.

E até aqui eu já senti que, mesmo o "entrevistador" pegando super leve, que eu preciso treinar mais esse aspecto de pensar no produto como um todo logo no começo. Como eu trabalhei numa area de arquitetura voltada para plataforma, eu acabei acostumando a pensar mais em sistema do que em cliente, porque era com quem eu lidava, com uma plataforma e os nossos "clientes" eram outros desenvolvedores.

Outro ponto é que embora eu crie produtos pra usuários e pense sim em quem vai usar, eu tenho PM, Designer, UX e mais uma galera junto trazendo respostas. Eu já fiz uma entrevista de System Design, que inclusive eu passei na vaga, mas senti que não desempenhei o melhor que poderia e que, se eu fosse exposta aquela atuação diariamente, eu teria dificuldades pelo escopo que estou "acostumada".

Portanto, mais um reforço pra você também dar uma chance ao estudo e prática de system design interview

Pra não me alongar muito, eu segui fazendo as perguntas para o meu "entrevistador" e no próximo texto (até pra não ficar muito longo, que esse não é o objetivo desse formato diário) eu trago o resultado mas, era muito importante mostrar o método - pelo menos eu acho - que estou usando para praticar.

Curiosidade: só esse processo da primeira parte foi embora 10 min (pra ser justa, a parte do prompt eu pausei o tempo porque numa situação real eu não precisaria fazer isso) e, para uma entrevista de System Design, levar 10 min só pra levantar requisitos, é um tempo bem longo, pensando que sobraria só 30 min para todas as outras etapas - inclusive, aprofundar nos componentes mais importantes, ou seja, não daria tempo.

Guia do HMTL prático

Jessilyneh — Fri, 17 Jan 2025 12:04:00 +0000

Esse artigo surgiu de anotações que eu tinha já faz um tempo no meu Github sobre HTML e que estou passando pra cá para o conteúdo não ficar parado. Comecei as anotações 3 anos atrás e fiz mais uma atualizações aqui enquanto escrevia esse artigo.

Se você já está com familiaridade sobre o que é, como funciona e procura algo prático com tags essenciais, era exatamente isso que eu estava buscando quando escrevi essas anotações.

Nesse conteúdo, é preciso que você já tenha conhecimentos sobre o que é HTML. Caso não tenha, acompanhe a documentação oficial antes de continuar a leitura :)

Por fim, como é um guia, o conteúdo vai ser um pouco mais longo que os demais conteúdos publicados aqui. Um outro adendo é que eu não estou tentando resumir documentação, essas foram as anotações que eu achei pertinente na época que estava lendo sobre o tema. Portanto, não deixe de consultar a documentação sempre que sentir necessidade de aprofundar em algum conceito.

Aqui vou falar sobre:

Formatação de texto
Elementos genéricos
Navegação
Audio
Imagem

Formatação de Texto

Para que o seu texto, titulos e todo conteúdo textual da página esteja organizado e facilite manutenção futura, mas que também traga ganho de acessibilidade (a experiência de uso de um leitor de tela com um HTML semântico vai tornar a jornada de quem tem alguma deficiencia visual, funcional)e inclusive ganhos em SEO, tão importante para seu site ser indexado e encontrado nas pesquisas dos motores de busca.

Títulos

<h1>h1</h1>
<h2>h2</h2>
<h3>h3</h3>
<h4>h4</h4>
<h5>h5</h5>
<h6>h6</h6>

Aqui, a ideia é hierarquia de títulos, do mais importante e que precisa ser visto primeiro, seguindo numeração decrescente. Lembre que é recomendável ter apenas um titulo h1 por página.
A parte do layout conseguimos fazer usando CSS, o importante agora é pensar em uma hierarquia de títulos para tornar a arvore de acessibilidade funcional e para marcar as sessões da página.

Itálico e ênfase

A tag  é usada para distinção visual de itálico, enquanto a tag  faz ênfase acrescentando valor semântico.

`Bold` e `Strong`

Da mesma forma, a tag  acrescenta distinção visual e a tag  serve para ênfase de alertas ou avisos

Listas

Lista não ordenadas

lista que não precisa seguir ordenação.

unordered item
unordered item
unordered item

            <ul>
                <li>unordered item</li>
                <li>unordered item</li>
                <li>unordered item</li>
            </ul>

Listas ordenadas

lista ordenada de alguma forma, seja por ordem numérica ou alfabética.

Lista numérica

ordered item
ordered item
ordered item

            <ol>
                <li>ordered item</li>
                <li>ordered item</li>
                <li>ordered item</li>
            </ol>

Lista ordenada por letras

c - ordered item
d - another item
e - one more item

Utiliza a propriedade type para definir o tipo da enumeração, neste caso, o type="a" significa letras minúsculas. Ja a propriedade start para definir a partir de qual ponto sua lista vai começar. Como vamos usar letras minúsculas e o valor de start é 3, vamos começar da letra c:

<ol start="3" type="a">
    <li>ordered item</li
    <li>another item</li
    <li>one more item</li
</ol>

Listas de definição

Lista tipo key:value, com um <dt>de definição do termo e um <dd>de descrição da definição:

definition term
definition description

            <dl>
                <dt>definition term</dt>
                <dd>definition description</dd>
            </dl>

Quotes

Usado para destacar trechos ou palavras num texto

Blockquote
usado para blocos de texto

Lorem, ipsum dolor sit amet consectetur adipisicing elit. Reiciendis eius maiores aperiam aut tenetur animi!. Eius modi necessitatibus natus enim sint vel rem accusamus excepturi! Mollitia nam dignissimos quo ea.
-- Ipsum Dolor

       <blockquote>
         <p>Lorem, ipsum dolor sit amet consectetur adipisicing elit. Reiciendis eius maiores aperiam aut tenetur animi!.
         Eius modi necessitatibus natus enim sint vel rem accusamus excepturi! Mollitia nam dignissimos quo ea.</p>
   <cite> -- Ipsum Dolor </cite>
       </blockquote>

Marcações de quotes

usado para marcar citações em linha

Lorem, ipsum dolor sit amet consectetur adipisicing elit. Reiciendis eius maiores aperiam aut tenetur animi!

<p>Lorem, ipsum dolor sit amet consectetur adipisicing elit. <q>Reiciendis eius maiores aperiam aut tenetur animi!</q></p>

Datas

Transforma qualquer data em um formato que o navegador (máquina) consegue entender

    <time datetime="2022-07-15">15 de julho de 2022 </time>
    <time datetime="23:00">11:00 p.m. </time>
    <time datetime="2022-07-13">2 dias atrás </time>
    <time datetime="23:00-06:00">11:00 no Canadá </time>
    <time datetime="2022-07-15T23:00">Quinta, 15 de julho as 23h </time>

Código, tag < e >

Para acrescentar cores em um texto, podemos usar {color:red}

        <code>
            <p>Para acrescentar cores em um texto, podemos usar <code>{color:red} </code></p>
        </code>

Superscripts, subscripts e textos minúsculos

Subscripts:
A tag  em HTML é usada para exibir um texto como sobrescrito, que aparece metade acima da linha de base normal e é renderizado usando um tamanho de texto menor

exemplo: H2O

<p>H<sub>2</sub>O</p>

Superscripts:

O texto dentro da tag  é renderizado meio caractere acima da linha normal e tem um tamanho de fonte menor.

exemplo: a área compreende 25m²

    <p>A área compreende 25m<sup>2</sup></p>

Fórmulas Matemáticas

Se voce precisa criar formulas complexas, pode usar o MathML, que é uma linguagem de marcação matemática baseada em XML, que vai ser renderizado em navegadores que tenham suporte.

Para exibir expressões matemáticas no GitHub usando MathML, você pode usar a sintaxe do LaTeX, colocando entre $ o conteúdo desejado.

Exemplo: Para exibir a equação quadrática ( ax^2 + bx + c = 0 ), você pode usar a fórmula:

Para isso, seu código HTML deverá ser assim:

$x = \frac{{-b \pm \sqrt{{b^2 - 4ac}}}}{{2a}}$

Elementos Genéricos

`div` e `span`

Devem ser utilizados apenas nos casos onde:

Não exista outro elemento semântico mais adequado;
Para envolver um grupo de elementos ou frase para aplicar alguma estilização (CSS) ou ação (Javascript)

Tanto a div como spam fazem a mesma coisa: NADA. Servem apenas para envolver elementos.

`<div>`

Utilizada como container genérico, para facilitar a aplicação de estilização ou ação, usando "class" ou "id" para identificação.

    <div class="container">
      <h2>HTML Notes</h2>
      <p>Repositório de assuntos importantes sobre HTML </p>
    </div>

``

Utilizada para edição inline (em linha) de um elemento, como por exemplo, aplicar estilização para uma frase em outro idioma.

    <div class="container">
      <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
       <span class="subtitle">Pellentesque habitant morbi </span> tristique senectus et netus et malesuada fames ac turpis egestas.
  </div>

Navegação

Links

<a href="http://github.com">Click here</a>

onde:

<a>: anchor - essa tag indica que é um elemento de linha.

href: Hypertext Reference - atributo da tag <a>. Nele, definimos para qual link vai apontar.

="http://github.com": URL absoluta contem todas as informações necessárias da localização de um recurso. É formada por scheme, server, path e um recurso, assim: scheme://server/path/resource

="index.html":URL relativa localiza um recurso, contendo apenas um path e as vezes, um resource.

Audio

A tag contém uma ou mais tags com diferentes fontes de áudio. O navegador escolhe a primeira fonte que ele suporta.

O texto entre as tags e só será exibido em navegadores que não suportam o elemento .

Existem três formatos de áudio suportados em HTML: MP3, WAV e OGG.

    <audio controls>
        <source src="/Audio/passaros.mp3" type="audio/mpeg">
        <source src="/Audio/passaros.ogg" type="audio/ogg" codec="opus">
        Seu browser não suporta esse arquivo de audio
    </audio>

Atributos

controls é um atributo booleano.

Especifica que os controles de áudio devem ser exibidos. Os controles de áudio incluem:

Play
Pause
Volume
Baixar arquivo
Velocidade de reprodução

Você pode encontrar mais informações na documentação da Mozilla

Também tem um exemplo de implementação com audios no repo do Github

Imagens

Usamos a tag <img> para renderizar diferentes arquivos de imagem para telas de tamanhos diferentes.

Uso básico da tag `image`

<img src="" alt="" width="" height=">

Uso do `srcset`

O atributo srcset oferece ao browser escolhas de tamanho de imagem que se adaptam melhor, evitando carregamento desnecessário. Neste exemplo, o w fornece o pixel measurement, no lugar de colocarmos 2x, 3x, saindo de um resolution-based para um srcset width-based. Dessa forma, conseguimos especificar o width de origem da imagem

  <img src="img/img-480.png" alt="flores" width="auto" height="auto"
    srcset="img/img-480.png 480w,
            img/img-w960.png 960w,
            img/img-w1440.png 1440w,
            img/img-w1920.png 1920w"
    sizes="(max-width:480px) 240px,
            (max-width:960px) 480px,
            (max-width:1440px) 690px,
            1920px"
            >

Figure e Caption

O elemento Figure vai encapsular o elemento caption e outros elementos gráficos, mas que vai manter a legenda junto da imagem.

figure
para usar em tudo que aparecer como uma figura, ilustrando algo.

figcaption
para demonstração de um conceito que precisa de uma legenda.

Você pode encontrar mais informações na documentação da Mozilla

Também tem um exemplo de implementação com as imagens no repo do Github

System Design - primeiros passos

Jessilyneh — Fri, 17 Jan 2025 02:41:19 +0000

Além da série sobre algoritmos, também estou começando uma serie sobre System Design. Mesma coisa que comentei antes: eu simplesmente troquei o X/Twitter e Bluesky pelo Dev.to, portanto, é um conteúdo mais descompromissado, algo que eu apenas to tirando da cabeça e regstrando, como fazia com as threads. Os artigos "formais" eu publico aqui toda sexta feira, às 9 da manhã.

Para me acompanhar no conteúdo, será ideal que você já tenha familiaridade pelo menos com a definição do que é System Design (isso você acha fácil na internet, nem tem porque explicar), e com desenvolvimento end-to-end de uma aplicação incluindo front, backend, banco de dados, segurança, infraestrutura. E também com arquitetura. Resumo, vai ser mais fácil se você já foi senior ou estiver em vias de se tornar senior. Eu realmente não acho que já saber System Design deve ser uma preocupação de Junior de mercado ( que não é de Big Tech).

Estou lendo o livro do autor Alex Xu, "Grokking the system design interview" que me pareceu bem completo e num preço que eu podia pagar. Também estou fazendo mapas mentais no Canva como forma de registrar os pontos chave do que estou lendo porque, senão, até a metade do livro, eu já não vou lembrar mais do que vi no inicio.

Já tinha feito algo parecido (resumos de mapas mentais) sobre o que é esperado de uma pessoa que trabalhe como arquiteta de software. Foi um trabalho bem demorado mas ficou tão bom que eu acho que valeu a pena o tempo dedicado e quero fazer o mesmo para outros temas. Se você se interessar, tenho o desenho que eu fiz publicado no Pinterest.

Mas, voltando para o assunto de hoje, que é System Design...

O que eu tenho anotado lendo o primeiro capítulo é o seguinte:

obs: eu adoro fazer essas anotações, mapas mentais...meu lado de artista precisa de coisas visuais

Dando um pouco mais de detalhes, a ideia é levantar estes pontos iniciais antes de começar a fazer um desenho robusto. A ideia é ter essas validações importantes logo no começo. O livro é focado em entrevistas de SD (System Design) então, tudo começa com um passo a passo de por onde começar seu projeto: com perguntas

Requisitos

Embora todo desafio de SD tenha um escopo, esse escopo não trás muitas definições precisas. Então, é bom confirmar o entendimento nesta etapa, com perguntas que busquem entender o quê é o foco do sistema, tipo de dados que passarão por lá, necessidade de atualização em tempo real dos dados e quais seriam as limitações ( o que está fora do escopo) entre outras perguntas pertinentes para entender o que o sistema "é" ou precisa ser.

Design de interface

Essa etapa é o entendimento básico de contratos de API, com quais sistemas a aplicação deve se comunicar e quais os contratos esperados em cada uma dessas pontas. Caso não tenha uma definição expressa, fazer a definição imaginada e validar com quem está aplicando o teste (feedback nessa etapa é primordial)

Estimativa da escala do sistema

Quanto será preciso de armazenamento? O quando esta aplicação pode crescer? Qual velocidade de internet estamos esperando? Essas e outras perguntas devem ser focadas em entender o quanto é esperado de elasticidade e escalabilidade (fazendo um parênteses aqui, estou relendo "Software Architecture — the Hard Parts" e estou justamente na parte que os autores discutem sobre estes dois pontos, bem no começo do livro. Queria dizer que planejo escrever sobre o que estou aprendendo neste, mas, tenho outro livro, "Padrões de Javascript" que estou finalizando a leitura e logo mais quero escrever sobre).

Modelo de dados

É preciso conseguir definir as entidades de dados, mesmo sem uma precisão perfeita mas, entender as interações necessárias e aspectos mais práticos como capacidade de armazenamento, criptografia, disponibilidade dos dados e outros pontos relevantes pensando no que foi definido nos passos anteriores.

5-6 blocos de design alto nível

Depois de levantar todas as informações, a ideia é criar um diagrama de alto nível de 5 a 6 blocos, mais pra validar todo o escopo entendido e já apresentar uma primeira solução. Acho que é um exercício bem interessante essa visão macro, principalmente porque trabalhando no desenvolvimento, podemos nos acostumar apenas na visão aplicação.

2-3 componentes com detalhes

Depois dos feedbacks da primeira parte da solução, a sugestão é focar em 2 ou 3 componentes (as entrevistas de System Design são curtas em relação ao que vai ser construído, então, faz muito sentido focar na parte que importa mais naquele momento, ainda mais porque não existe apenas uma resposta para as perguntas) e se focar em apresentar trade-offs de cada abordagem. Este ponto eu achei bem interessante também, de procurar apresentar mais de uma forma de fazer a mesma coisa e pontuando o que tem as desvantagens mais gerenciáveis.

Identificar possíveis gargalos

Após essa parte do desenho do sistema, vem a parte de identificar se tem algum ponto de falha e quais as possíveis formas de mitiga-lo (se é possível, inclusive). Aqui também entra a parte de monitoria de performance, por exemplo.

Por fim, tem um desafio de criar um sistema encurtador de URL, que eu definitivamente vou tentar fazer com o que já aprendi ate agora antes de olhar no livro como foi feita a solução. No fim das contas, o exercício de System Design é sobre prática.

Independente da questão de estudar para passar em processos seletivos de big techs, no meu trabalho atual, esse conhecimento vai ser incrivelmente util porque, embora eu esteja acostumada a pensar em desenho de sistemas, normalmente eu tenho semanas e até meses para criar esse desenho.

Fazer algo desse tipo em uma hora é definitivamente muito interessante e vai ser util porque conseguirei trabalhar melhor em reuniões de arquitetura e definições com a minha gestão técnica, porque vai ser muito mais proveitoso eu trazer ali na hora as melhores perguntas e um desenho e sair da reunião com uma hipótese cujos pontos principais foram validados com as minhas partes interessadas.

Então, fica meu endosso para o estudo desse tema se você está hoje num cargo que envolve decisões de sistemas e arquiteturas. Se você atua com foco na implantação de soluções, ate aqui eu entendo que focar em algoritmos vai ser mais vantajoso.

No próximo post, vou apresentar minha solução do encurtador de URL :) Tentarei fazer em 45 minutos, vamos ver o que vai sair haha

Resolvendo meu primeiro desafio no HackerRank

Jessilyneh — Thu, 16 Jan 2025 00:34:34 +0000

Esta série não tem o objetivo tão didático quando os demais conteúdos, é mais para eu registrar minha experiência nos estudos de algoritmos. Vão ser textos mais curtos inicialmente. Como já falei em outros posts, como eu não uso mais X/Twitter e nem Bluesky, vou deixar tudo que postaria lá, por aqui - inclusive os Learning in Public.

Se você nunca ouviu falar, Hacker Rank é uma plataforma com desafios de programação que servem tanto para se preparar para entrevistas técnicas que pedem testes de algoritmo e estrutura de dados, quanto para se divertir (sim, tem gente que gosta e eu gosto também) e competir com outros devs que também gostam de resolver problemas.

Eu me interessei de começar a estudar esses testes com dedicação este ano, porque é algo que sempre adiei e, embora eu saiba que não vai ser tão útil neste momento no meu trabalho (confiem em mim, eu sei do que estou falando e, a menos que vocês trabalhem comigo, se não conhecem o contexto do que eu faço, vocês não podem dizer que eu to errada haha só aceitem meus motivos sem querer me ensinar ou corrigir) acho que é a hora de aprofundar.

Eu vou tentar publicar sempre que for fazer um novo teste.

1 - function solveMeFirst

O primeiro desafio é bem mais amigável do que a primeira vez que eu tive contato com a plataforma, uns 9 anos atrás quando ainda estava estudando. Achei legal porque assim tiram a imagem de "isso é impossível de ser feito".

Para resolver esse primeiro desafio, foi preciso apenas retornar a soma de duas variáveis:

function solveMeFirst(a, b) {
  return a+b  // essa foi a linha que eu adicionei 
}

E pronto, estava resolvido.

Porém, embora esse desafio foi super fácil, eu percebi que estava bem fraca em Node.js porque já faz mais de um ano que eu trabalho apenas com Angular e Java, li o restante do código do desafio e não entendi foi é nada hahaha Como eu estou atuando com foco no frontend, não vou me culpar e cobrar, mas sim apenas estudar Node.js para relembrar as coisas porque vou precisar, nos próximos.

Se você é backend provavelmente não precisa passar pelo mesmo, mas para outras pessoas que assim como eu atuam mais forte no frontend, é uma realidade necessária para colocar no plano de estudo: sim, você vai ter que aprender ou relembrar backend (No meu caso, Node.js)

Quando eu vi esse trecho aqui, logo no começo do código:

process.stdin.resume();
process.stdin.setEncoding('ascii');

var input_stdin = "";
var input_stdin_array = "";
var input_currentline = 0;

Eu tive essa certeza haha entendi o que estava sendo feito porque é possivel entender sim, mas não entendi a forma que estava sendo feito. Aqui eu fui lendo sobre o modulo process no Node.js, fui olhando a documentação e pronto, era um trecho de código que lê dois números inteiros a partir da entrada padrão e, em seguida, calcula a soma desses números.

Caso não conheça, tem um conteúdo bem completo sobre Node.js no próprio site oficial, e caso você não fale inglês, como está em texto, fica mais fácil de traduzir. Se assim como eu você não lembra o que o stdin.resume faz, dá uma olhadinha na doc, que ela vai ser sua melhor amiga, ou vai acompanhando os módulos educacionais no site da Node.js

Por hoje é isso, pessoal! Vou continuar meus estudos e acho que quando sair dos desafios super fáceis, publico novamente :)

O que realmente agregou profissionalmente quando eu era Junior

Jessilyneh — Fri, 10 Jan 2025 12:00:00 +0000

Sei que vocês já ouviram muitos relatos sobre como passar logo de jr pra pleno, etc etc
Hoje vim falar algo diferente: quais tem sido as coisas que eu tive feedbacks mais legais, como jr. Ou seja, vou falar do que eu "achava" que era legal fazer versus o que realmente agregou.

Essa é uma série de artigos feitos com base em threads que fiz no finado Twitter, que tiveram engajamento legal. Essa de hoje é sobre os hábitos que fizeram diferença muito positiva na minha carreira.

Esse conteúdo é de 2022 mas, continuo entendendo que tudo é relevante e ainda aproveito os benefícios dos hábitos de revisar PRs, começar a investigar problemas mesmo sem conseguir resolve-los e o pair programming. Vamos lá:

1 - Revisar PRs.

Eu não tinha uma relação séria com revisão de PRs em experiencias anteriores. Sempre ouvia um "aprova ai pra mim rapidão". Ou seja, não lia. Depois disso, fui trabalhar numa equipe de 3 pessoas que nós mesmos que fazíamos as aprovações, sem nenhuma revisão.

Quando mudei de emprego, no primeiro mês, não olhei PR nenhuma porque eu pensava "todo mundo aqui tem um nível técnico muito alto, não tenho nem o que acrescentar". Depois, fui percebendo como eram todas pessoas extremamente acessíveis e que davam muito valor para qualidade de código.

Disso, comecei a revisar PRs sempre que tinha um tempinho. Era comum que, numa mesma semana revisasse 4 PRs. O que eu não entendia, perguntava para a galera. Mesmo que na época eu não fosse nem de longe tão experiente quanto eles ( e eu amo estar em lugares com tanta gente boa), conseguia contribuir com melhorias.

Então, uma lição importante que eu tive de ser uma boa jr é não querer esperar eu ser especialista para perguntar ou sugerir algo que eu acredito que pode melhorar um codigo, mesmo que seja uma coisa pequena. E mais importante: nao ter medo de falar "não sei isso, pode explicar?".

Quando ingressamos na área mais velhas (eu entrei com 26, enquanto outros juniors que trabalhavam comigo tinham 18) é comum ficar desconfortável de ver gente mais nova ou da nossa idade que já é senior. Mas olha, não ligue pra isso. Sei que não é fácil mas foque em ser uma boa jr antes de querer ser pleno ou senior, não queira pular etapas.

2 - Trabalhar em problemas que você não sabe resolver, com supervisão

Meu primeiro tech lead me dava uns problemas que eu não sabia resolver. Eu desesperava e achava toda semana que seria demitida. Ai eu queria resolver aquilo a todo custo - e sempre sozinha.

Pra mim, fazer sozinha mostrava que eu sabia e que, quanto mais coisas sozinhas eu soubesse fazer, mais rapido eu seria PL. Pois bem, eu passava dias quieta, tentando resolver algo sozinha.

Quando o meu tech lead me perguntava se eu ja tinha feito, ai eu quase chorava pra falar que não e que estava com dificuldades.

Isso ajudou ZERO no meu desenvolvimento e só ajudava a duvidar mais e mais da minha capacidade.

O que ele me falava: "não passei pra voce RESOLVER, passei pra voce começar a investigar".

Eu demorei pra entender isso, viu...

Depois dessa fala dele, eu aprendi que a ideia de alguem passar um problema complexo pra você, como Junior, não é voce mostrar que é uma inteligência acima da média e resolver tudo sozinha.

Esse exercicio é pra você começar a pensar por onde pode resolver e FALAR para a pessoa o que já testou e quais os resultados resultado. Assim, a outra pessoa mais experiente já pega o problema esmiuçado.

3 - Fazer Pair Programming

Sei que é uma situação desconfortável ter alguém observando você enquanto escreve seu código, porque vai acabar esquecendo as coisas, parecendo que não sabe nada e até tendo problemas para se concentrar mas, o pair programming é uma das coisas que mais vai te ajudar a progredir tecnicamente em confiança e qualidade de código, se feito com alguém mais experiente e que preza boas práticas.

A pessoa que tá atuando como junior ganha aprendendo a analisar as coisas e, cada vez mais, conseguindo avançar nas soluções. Importante: eu também aprendi a melhorar minha comunicação para explicar de forma pragmática o que eu já tinha feito e a linha de pensamento que estava seguindo.
PARA PAIR PROGRAMMING, ISSO FOI UM DIVISOR DE ÁGUAS. Sério.

Isso de ir fazendo e explicando sua linha de raciocinio, na minha experiencia e opinião, foi uma das coisas mais importantes. Eu sinto que de fato eu estou aproveitando a pessoa que está trabalhando no problema comigo e que estou aprendendo.

O impacto a longo prazo

Quando você estiver em cargos de pleno ou senior, analisar bem as PRs, se acostumar a trabalhar em problemas que não sabe resolver e saber fazer pair programming já devem ser no minimo atividades instintivas porque vamos usa-la para o resto da nossa vida util na profissão. Por isso, galera junior, procurem desenvolver esses pontos porque,dessa forma, conseguimos aprender qualquer coisa.

Acredito que qualquer pessoa vai ter dificuldade para aprender coisas novas, ainda mais quando começam numa área que não tem nenhuma familiaridade. O começo é sempre difícil e parece que nunca vamos conseguir superar algumas dificuldades.
Na minha experiência, a forma de lidar foi buscando praticar os meus pontos fracos sem me importar quanto tempo isso fosse levar. Ler é super importante mas eu só absorvi ( e não esqueci mais) quando peguei as coisas na prática.

E analisar PRs ( de verdade e com vontade) somada a isso de começar a resolver problemas complexos e fazer pair sao medidas simples e acessíveis, que vão fazer a diferença MESMO.

De pleno para senior: o que está faltando?

Jessilyneh — Fri, 03 Jan 2025 12:00:00 +0000

Eu encontro com muita facilidade - e muitas opções - conteúdos pra quem é iniciante ( e isso é maravilhoso, continuem) com dica de carreira e tudo mais.

Porém, quem está no momento em uma vaga de pleno e tá naquele limbo desgraçado de não entender o que precisa pra ser senior?

Com base na minha experiência e nas conversas e convivência com outras pessoas, trouxe alguns tópicos relevantes:

1 - Nem sempre é você que ainda não se desenvolveu

A empresa pode tá sem recursos financeiros pra te promover ou, pode ter gente que ela quer segurar pra nao ir embora e vai passar a promoção dela na frente da sua.

2 - Nao existe associação internacional de senioridade de TI

Cada empresa define o que quer sobre senioridade. Seria no mínimo muita pretensão da minha parte querer achar o ponto em comum.

3 - Habilidade técnica não é tudo

O entendimento de senioridade para a promoção não depende apenas da sua habilidade de escrever código igual uma máquina, mas pode ser também (uma coisa não exclui a outra) cultural.

Por exemplo, a empresa pode considerar alguém mais competente para assumir um cargo de senior do que você, simplesmente porque ela sabe se comunicar melhor. Então, sempre pergunte o que é esperado e entenda que, não raro, a empresa pode nem ter definido o que espera de cada cargo.

4 - Habilidades de controle emocional

um ponto que dificilmente eu vejo alguém comentando é sobre o quanto desenvolvimento emocional é importante ao decorrer da senioridade. Como falei, não basta ser uma metralhadora de código, faz parte das habilidades não descritas no cargo de senior o famoso "segurar a bucha". Entender que quando acontecer uma merda, é você que esperam na linha de frente.

5 - A lógica do peixinho dourado

Uma das minhas analogias preferidas é a do peixinho dourado que cresce conforme o tamanho do "aquário" que ele está, para me referir ao entendimento de quando pode ser a hora de mudar de empresa.

Muitas vezes, você vai precisar mudar de empresa pra conseguir a "promoção" pra senior. Entenda muito bem que tipo de expectativas vai serão esperadas de você e quanto de espaço vai ter para crescer, antes de aceitar uma vaga.
Pode acontecer da experiência ser muito válida, porém, com data de validade.

6 - As bases que importam não são apenas as teóricas

As vezes, pode valer a pena voltar uma casa e entrar numa empresa muito estruturada com junior, do que aceitar um cargo de senior, se você é pleno mas não teve um bom desenvolvimento como junior.
Digo isso porque foi o meu caso e, de longe, foi o melhor movimento que fiz na minha carreira.

7 - Cuidado com o ego

Principalmente para carreiras com pouco tempo: não menospreze o valor da experiência em campo, lidando com aplicações com milhares de requisições por dia, versus um projeto seu com complexidade desnecessária e com total de zero usuários.

Entendo que é importante olhar a qualidade do profissional acima do tempo de experiência e que a pessoa pode estar 10 anos no cargo mas fazendo a mesma coisa todos os dias e sem evolução técnica significativa, porém, vamos evitar olhar sempre os piores cenários, que não sabemos nem a quantos % ele representa do mercado.

Nosso entorno super limitado (pessoas do nosso trabalho, pessoas que interagimos em rede social) não são suficientes pra dizermos como "é" o mercado, sendo que esquecemos que uma boa parte dos nossos colegas de trabalho sequer usa rede social.

Por isso, procure estabelecer comparativos com pessoas de tempo de experiência e qualidade técnica, não com o pior cenário.

8 - Se você nao sabe se vender, se alie a alguém que saiba

Não adianta reclamar do jeito que as coisas são, porque a vida é como é e a gente tem formas de lidar.

Infelizmente, se você não mostrar o seu trabalho, ninguém vai conseguir saber o que está fazendo.

Não precisa virar influencer (isso não é sinônimo de propriedade em algum assunto, é sinônimo de popularidade. Acontece de alguns influencers serem referências técnicas mas, nem todos), as vezes só é preciso mostrar o seu trabalho para a pessoa certa que vai conseguir vender seu trabalho para outras pessoas.

9 - Evite comparações

Principalmente de tempo de experiência ou de salário. Sei que isso é quase impossivel dado a dinâmica de redes sociais e de sociedade, mas é uma baita distração inútil.

10 - Se pensa em migrar de area,é um bom momento

Por exemplo, se você está pensando de mudar de front pra backend, de backend pra devops, dados ou segurança, esse é um ótimo momento porque você ainda nao tem um salario alto te prendendo e tem conhecimento de pelo menos 2 níveis, que vai te ajudar em qualquer area que vá.

11 - Cuidado com o "emprego na gringa"

O famoso "estão desesperados atrás de dev e estão pagando em dolar" que as pessoas juram pra você que é só falar inglês suficiente pra se comunicar.

Tem muita questão a se considerar, inclusive, não é porque um salário é em dólar que vale a pena. Cuidado principalmente com consultoria, que te prometem um monte de coisa, te enrolam e não contratam.

Cada um faz o que quiser da vida, mas saiba que não existe mais facilidade. Se você pegar algo maior do que aguenta, e muitas vezes sem necessidade real, isso vai ter um preço e ele pode ser maior do que o seu ganho.

Estou falando isso especificamente porque sei que nesse momento do "pleno pra senior" a gente se emociona e acaba indo atrás do que nao aguenta. Como senior, normalmente, você já aprende a sentir cheiro de enrascada.

12 - Não fique apenas vendo coisa da sua área, procure além

Mantenha o foco na sua especialização desejada porque é ela que garante seu emprego mas, conhecer outras áreas correlacionadas vai te ajudar a ter mais bagagem pra chegar na senioridade que busca.

Saber sobre infra, dados, segurança e automação vai te garantir um diferencial relevante. Nao fique se distraindo com truques de influencer, tipo se preocupar com a cor da sua IDE ou formato do seu teclado.

13 - Leia sobre fundamentos avançados

Sei que voce ja aprendeu o basico quando era junior, mas infelizmente a maioria de pessoas instrutoras pegam leve demais com quem ta começando. Entao, volte e revise as suas bases, mas se aprofunde nelas. Acredite, você vai precisar.

14 - Se conheça. Daqui pra frente, vai ficar mais dificil

Se voce tem algum tipo de comportamento que te atrapalha,busque mante-lo sob controle agora. Voce já conseguiu um trabalho com melhor remuneração do que tinha como junior, então, precisa investir em saude pra conseguir levar o que está por vir sem surtar.

15 - Aprenda a conversar, não só bater teclado

Este é auto explicativo. Sem comunicação eficaz, seu trabalho não anda, ainda mais agora que não vai ter alguém num cargo acima te explicando como fazer seu trabalho.

Estou avaliando publicar alguns dos textos em inglês porque a grande maioria dos conteúdos aqui é em inglês

Jessilyneh — Sun, 29 Dec 2024 13:14:06 +0000

Conteúdos de estudo e cursos para iniciantes em programação web

Jessilyneh — Sat, 28 Dec 2024 12:00:00 +0000

Não raro vejo pessoas cobrando conteúdo de iniciantes em posts de conteúdos avançados. Já tem tanto conteúdo pra junior, mas TANTO, que eu acho que talvez falte apenas saber quais são.

Acho que não preciso mencionar as documentações oficiais de cada tecnologia porque esse já é o ponto de inicio básico para qualquer tema.

Então, partindo do principio que, lendo a documentação ou a especificação de uma tecnologia não foi suficiente para conseguir entende-la, segue alguns bons e muito conhecidos pela maioria:

1- Para CSS, o melhor e mais didático sem dúvida é o flexbox Froggy:
https://flexboxfroggy.com/#pt-br

2 - FreecodeCamp tem uma concentração incrível de conteúdo de qualidade gratuito. Você pode fazer doações para eles em dinheiro, se curtir o trabalho.
Tem Design Responsivo, Algoritmos e estrutura de dados, banco de dados, frameworks de frontend, tudo em pt-br

https://www.freecodecamp.org/portuguese/learn/

3 - Curso em Video de Javascript, 40 horas, do Guanabara, o professor de 99% dos devs BR.
A didatica sempre impecável e gratuito:
https://www.cursoemvideo.com/curso/javascript/

4 - Curso em Video de Java, mesma plataforma do curso de Javascript. Lembrando que a parte que cobram é só emissão de certificado (e eu nao acho que certificado seja algo super necessário):
https://www.cursoemvideo.com/curso/java-basico/

5 - A linux Tips tem Linux Tips Essentials, que tem muito curso bom e gratuito. Lá voce acha curso de infra, linux, Python e outros assuntos incríveis. Basta procurar "essentials" no filtro dos cursos:
https://linuxtips.io/treinamentos

Por fim, Kan Academy, se você sente que suas "bases" de computação, matemática ou outro tema deixam a desejar:
https://pt.khanacademy.org/

Acredito que tenham muitos outros conteúdos e links, a minha ideia foi trazer os mais populares para facilitar as buscas de quem não encontra "o básico".

"Ser" ou "estar" Senior?

Jessilyneh — Fri, 27 Dec 2024 12:26:55 +0000

Nossos títulos profissionais são importantes para dizer onde atuamos no mercado, o que fazemos e o nosso grau de habilidade em realizar nossas tarefas, sem que alguém precise conversar conosco ou buscar nosso currículo para saber essa informação.

Tem gente que prefere titulos genéricos, tem quem prefira deixar especificado ao máximo para facilitar a busca de recrutadores ou de possíveis novas conexões e o papel de senior acaba sendo o mais falado nas conversas da comunidade, justamente por passar a ideia de uma pessoa com bastante proficiência e tempo de mercado. E ai vem o meu ponto do título desse texto: "somos" ou "estamos" senior?

Esse é mais um artigo da série de threads do Twitter que eu não queria deixar morrer e trouxe para cá.
Esse de hoje sobre uma resposta que eu fiz num tweet de um colega de profissão, o @sseraphini no finado twitter:

"Porque ser sênior em uma empresa não te faz sênior em outra empresa?"
"porque ninguém "é", todo mundo apenas 'está'"

Comentando um pouco mais sobre, eu respondi no tweet do Sibs "porque ninguém 'é', todo mundo 'está' apenas" e isso não quer dizer que não existe senioridade ou que é uma coisa trivial.
Quer dizer que precisamos nos perguntar quanto da nossa senioridade atual é saber contexto da empresa que trabalhamos e, se sairmos de lá, acabou nosso conhecimento.

Já falei inúmeras vezes sobre o que eu entendo sobre um profissional senior. Mas trazendo um reforço aqui, tem muito pouco a ver com saber isso ou saber aquilo na teoria.

Pra mim, tem a ver com prática, com tempo de código, exposição a cenários que podem ser replicados em outros domínios de negócio (na thread que fiz falando que já migrei monolito pra MFE e vice versa, coisas assim) e outros exemplos de vivência. Aqui, eu acredito muito que é a experiência que vai pesar, tá?

Acho que a gente perde muito tempo precioso discutindo perfumaria, como comunidade. É legal, mas ninguém vira senior assim haha Claro, temos que lembrar que cada empresa tem uma régua diferente e tudo mais e, no meu entendimento, muita empresa desceu a régua pra incluir mais pessoas, por necessidade do negócio.

Então, é por isso que tem seniors e seniors. Não quero levar ninguem a sindrome de impostor, mas acho que em geral, voces devem ter consciência dos "gaps" de formação que tem e dos pontos que precisam melhorar.

Estava falando hoje com um colega e ele trouxe um ponto excelente (espero que ele comente no perfil dele, porque foi um ponto bem legal) que ultimamente nós estamos tratando nossa profissão com muito simplismo.

Fazer o que fazemos não é fácil. Ser junior já não é fácil. Ser senior não é "só" isso ou aquilo, é um trabalho de anos de experiências de qualidade (essa parte da qualidade é muito importante).

A empresa pode chamar a gente de senior, super devemos aceitar isso e o salário que vem junto sim, mas ter consciência onde nós realmente estamos, sem vaidade.

Concluindo, no meu entendimento, vai chegar um ponto que você vai ser senior em todas as empresas que passar, mesmo sem dominio do negócio, porque você já vai ter entendido como lidar com essa questão da curva de aprendizado e ja estiver calejado o suficiente pra não se intimidar. E entender que ninguem aprende isso em pouco tempo :)

Eu quero ressaltar que eu não falo isso com qualquer tipo de vaidade, porque, pra mim, eu fiz o minimo esperado de um senior, sem ficar me prendendo ao que empresa essa ou aquela define. Tá cheio de gente com a "mesma experiencia" que eu, guardadas as devidas proporções.

Mas o meu ponto é falarmos mais das nossas experiencias e nos preocuparmos menos com o nome que o departamento de Recursos Humanos nos registra na hora de pagar salário.

As experiências técnicas que me fizeram senior

Jessilyneh — Fri, 27 Dec 2024 04:35:00 +0000

Esse é o primeiro artigo de uma série de artigos feitos com base em threads que fiz no finado Twitter, que tiveram engajamento legal e, pra não ficarem perdidos lá na rede do Kiko do Foguete, trouxe pra cá.

Neste artigo, trouxe uma lista das atividades mais relevantes que eu fiz ao longo dos 7 anos que trabalho com desenvolvimento de software profissionalmente e que, hoje, eu entendo que foram as "pedrinhas" que usei para construir meu caminho profissional até chegar no cargo de senior.

1 - Ter construído uma aplicação desde o começo, definido e entregue uma V1 que foi para produção
2 - Lidar com os erros que eu mesma cometi numa aplicação
3 - Trabalhar num legado
4 - Modernizar um legado
5 - Começar a desligar um legado
6 - Refatorar uma aplicação
7 - transformar micro fronts em um monolito
8 - trabalhar num monolito que estava sendo dividido em micro fronts
9 - Trabalhar em projeto que acessibilidade era obrigatória
10 - Participar da construção de um design system
11 - Participar de definições de arquitetura
12 - Entender o que é handoff e como participar de um
13 - Documentar como uma profissional
14 - Participar de correções de erros em produção com alto impacto
15- Treinar alguém para ficar no meu papel
16 - Criar processo de onboarding
17- Mentorar pessoas para subirem de cargo
18 - Ser duramente questionada por uma liderança sobre as decisões de projeto e precisar criar um roadmap de melhorias
19 - Ter atuado como tech lead num papel extremamente burocrático
20 - Ter atuado como tech lead num papel totalmente técnico
21 - Escrever ADR (Architecture Decision Records)
22 - Passar por sabatinas duras de perguntas sobre o que eu digo que sei, mas com muito respeito
23 - Trabalhar com tecnologias que eu não tinha domínio nenhum
24 - Montar um dash que era alimentado por diferentes fontes de dados, para a área de produto
25 - Dar aula.

Adicionais:

ter tido uma pessoa que teve coragem de me dizer que eu não era boa, que precisava estudar de verdade e ter foco;
ter ouvido o que ele me disse, porque era tudo verdade;
ter recusado um cargo de pleno e aceito um de junior, numa empresa boa pro meu desenvolvimento.

Meu desenvolvimento como junior até ali não tinha sido dos melhores e até por isso, recebi o feedback de que eu não era boa para ser pleno ainda.

Coisas que não me ajudaram em nada ou que colaboraram muito pouco no desenvolvimento profissional:

Fazer vários cursos livres de tecnologias que eu não estava usando no meu trabalho e nem fora dele;
Popularidade em rede social;
Estudar até a exaustão;
Discussões em rede social;
Criação de conteúdo, que me fazia gastar muito tempo e energia.

Se você está num papel de senior em diante, já parou para pensar quais eventos profissionais te fizeram ter as duras mas valiosas lições aprendidas?

Entenda um código JS - que não tem readme ou testes e que não foi você que escreveu

Jessilyneh — Mon, 12 Jun 2023 12:59:08 +0000

1 a 5 — Execução básica do projeto

1 - Verificar no package.json a versão de Node.js utilizada (essa informação fica lá no finalzinho do arquivo, em engines) e usar a mesma versão localmente antes de qualquer outra etapa (um nvm ajuda a alternar entre versões, facilmente)

2 - Instalar as dependências (npm install).

3 - Voltar ao package.json e verificar se existe em scripts uma instrução "build". Se sim, realizar esse processo (npm run build)

4 - Se o build der certo, veja se existe em scripts a instrução "start". Se sim, execute o comando.(npm start)

Em alguns casos, o build é só para gerar o bundle de produção, então, também é importante avaliar se tem um script "dev" no lugar do start**

5 - Se der certo, verifique a execução no terminal ou no no navegador. A informação de qual será a “porta" que a aplicação vai ser executada sempre está presente na saída das informações do terminal, que é "https://localhost:" e a porta, que pode ser 8080, 4200 ou outra.

Agora, começa a parte "difícil" haha

Continuando, meu exemplo é uma aplicação de front:

6 — Verifique configurações de ambiente

Se o build ou o start (ou ambos) não der certo, estude a estrutura de pastas do projeto para entender se existe mais algo que precisa ser executado localmente, como outro projeto. Também pode ser importante verificar arquivos como o .npmrc ou outros arquivos de ambiente.

7 — Mapeie classes, objetos e fluxos

Se a etapa de build e execução do projeto der certo, comece entendendo o que aparentemente a aplicação faz. Depois disso, com a ajuda do "inspetor de código" do seu navegador, comece a tentar se situar com os nomes dos componentes e onde eles estão, no código. Anote tudo isso, ou faça um mapa mental.

Caso fique difícil entender onde começa o fluxo da aplicação busque pelo atributo "main" do package.json que indica qual é o arquivo de entry point, ou seja, é onde está o primeiro código a ser executado.*

8 — Use o Debugger

Agora, se já ficou mais entendível quais os arquivos que guardam as classes ou as funções mais importantes, use a ferramenta de debugger do navegador ( eu sempre uso Developer Tools do Google Chrome) e entenda qual o fluxo de dados da aplicação:

o que é consumido
onde é usado
como é processado
qual a saída gerada

Anote tudo no seu mapa mental ou num documento de apoio. Voce precisa entender o que cada variável e funçao faz. Tente explicar pra si mesma enquanto le suas anotações. O mapa mental vai te ajudar a medir o impacto de mudanças, exclusões ou acréscimo de algo, no projeto.

9 - Documente

Como inicializar o projeto, no Readme.md
Se é necessário executar algum outro projeto, em paralelo
A versão de Node.js usada
Passe o fluxo desenhado e as anotações para a wiki do repositorio ou algum portal de documentação, do projeto
Tem algum conhecimento prévio que ajudaria a entender o funcionamento dos processos principais? Algo pouco comum de usar, como por exemplo, uso de Symbol? Se teve algum artigo ou documentação que te ajudou a entendem, inclua também.

10 - Melhorias

Depois de realizar toda análise e começar a trabalhar na adição ou remoção de código, veja se tem algo que pode refatorar, como por exemplo,nomes de variáveis ou melhoraria da legibilidade do código. Também verifique se algum processo é realizado sem necessidade, como requisições repetidas ou armazenamento de informações desnecessárias.

Por fim, dentro dos seus conhecimentos,verifique se existe alguma falha de segurança.Isso inclui verificar obfuscação de código,segurança das chamadas http e pacotes vulneráveis na aplicação (npm audit).
Também é interessante criar ao menos um teste de ponta a ponta, na operação principal.

Considerações finais

Esse processo foi escrito com base em uma experiência que eu tive, no trabalho. Claro, poderia desdobrar muito mais em cada etapa, além do mais, tem o fator muito importante de entender qual o problema que a aplicação resolve. Mas mesmo sabendo que é um escopo geral, o que falei, acho que pode ser util :)

Uma coisa ate mais importante que o texto todo: não se preocupe, isso pode levar tempo. Ás vezes, dias. E não é tempo perdido e voce nao é incompetente por precisar fazer esse processo. Essa foi a coisa mais importante que eu aprendi com o meu mentor aqui da F1rst essa semana: realizar esse processo não é falta de conhecimento, é parte do trabalho.

Dica do Jhonny Freire, pelo twitter

** Dica do Luciano Lima, pelo twitter