Forem: Era

A natureza da Complexidade

Era — Thu, 16 May 2024 11:46:22 +0000

Notas ao ler: A Philosophy of Software Design - Capítulo 2

A Philosophy of Software Design é um livro que tenta ensinar como escrever código de qualidade. Aqui estão algumas das minhas notas ao ler o capítulo 2. Eu também estou postando esses e outros textos no meu Patreon (que é de graça).

O autor define complexidade como "qualquer coisa relacionada a estrutura do software que faz com que seja difícil de entender ou modificar tal sistema".

Em outras palavras, complexidade não está relacionado ao tamanho do sistema ou de uma funcionalidade, mas a dificuldade de lidar com ele ao fazer modificações ou consertar algo que deu errado.

O autor define formalmente complexidade como:

Onde a Complexidade do Sistema (C) é determinada pela complexidade de cada parte p, onde c é o tamanho da complexidade da parte e t o tempo em que o desenvolvedor gasta naquela parte do sistema. Essa formula é muito interessante porque mostra claramente que se caso algo seja extremamente complexo, mas o tempo em que o desenvolvedor gaste nela seja nulo ou próximo disso, essa complexidade é bem próxima de zero. Demonstrando a importancia de "esconder" complexidade do dia-a-dia.

Uma dica muito importante que o autor dá é que: "complexidade é mais aparente para o leitor do que para quem escreveu o código. Se alguém fala que o código que você escreveu é complexo, então ele é complexo.

Sintomas da Complexidade

1 Change Amplification: uma mudança que deveria ser simples, acaba gerando mudanças em diversas partes diferentes da aplicação. O autor dá um exemplo bem simples de entender (ao menos para os devs mais velhos). Dá época que a gente escrevia os HTMLs inteiros de um website a mão.

O exemplo: Imagina que um website é feito de várias páginas HTML, todas escritas a mão e que cada uma delas tem um banner. Se a gente quiser trocar a cor de fundo desse banner, a gente vai ter que trocar em cada página. Hoje em dia páginas não são mais feitas assim, e esse tipo de detalhe é configurado em somente um arquivo (e.g. um arquivo css).

2 Cognitive load: Quanto você precisa deixar em mente para executar uma tarefa? Sistemas complexos forçam o programador a manter MUITA coisa em mente. O autor cita o gerenciamento de memória em C, onde o programador tem que lembrar de liberar um pedaço de memória depois de usa-lo e não usar um ponteiro depois de liberar o espaço que ele aponta.

Uma observação importante: algumas vezes uma solução que exige que tem mais linhas de código pode ser mais simples justamente por causa do Cognitive Load.

3 Uknown unkowns: Sistemas complexos são cheios de coisas que não sabemos que não sabemos. Esse é o pior sintoma, pois é o mais complicado de se resolver. Sabe quando você tem que fazer uma tarefa, e não tem ideia de onde começar, quanto vai demorar ou até fica com medo de modificaralguma coisa e quebrar o sistema?

Um dos pontos mais importantes quando fazendo um system design é fazer com que ele seja óbvio, justamente para evitar esse problema.

Causas da Complexidade

Existem duas causas de complexidade: dependências e obscuridade. O livro define dependência como: quando um pedaço de código não pode ser entendido e modificado de forma isolada, o código está relacionado a outro de alguma forma, e onde outra parte do código deva ser mantido em mente e considerado quando uma mudança em outra parte é feita. No exemplo das páginas HTMl, a cor de fundo do banner cria uma dependência entre todas as páginas HTML.

Importante notar que existem dependências explicitas (e.g. uma função é utilizada em uma parte do código) e dependências não-explicitas: duas partes do código usam um mapa de string e precisam que a chave sejam exatamente iguais (e constantes não são utilizadas). Dependências não-explicitas são o pior caso possível.

Navegadores, muito mais que apenas consumo

Era — Fri, 30 Sep 2022 06:52:08 +0000

Postado originalmente no meu blog em português

O navegador é bem mais do que uma simples media para consumo de informação. Graças a add-ons como o Greasemonkey, usuários podem utilizar javascript para personalizar sua experiência na web.

Quando eu trabalhava na Amazon, era bem comum termos que interagir com sistemas internos escritos por outros times para lidar com o serviço deles. Esses sistemas eram pensados de um ponto de vista, mas a maioria das pessoas quando chegavam neles, tinham necessidades diferentes. Por exemplo, a gente no Redshift tinha um website para controlar nosso fleet de máquinas (banco de dados dos clientes). Ele era otimizado para que um engenheiro de plantão pudesse ver o estado da máquina e fazer as ações mais comuns. O suporte também utilizava esse nosso site, mas eles tinham necessidades bem diferentes. Por isso eles tinham uma série de scripts para personalizar as ações.

Outra possibilidade é a criação de add-ons/plug-ins/extensões que é suportada por todos os navegadores modernos. Extensões como https://web.hypothes.is/ e https://memex.garden/ tentam tornar os navegadores em ferramentas para “o pensamento”, possibilitando anotar sites, mais ou menos como pessoas anotam livros.

As pessoas que sabem javascript e sabem como os sites funcionam tem a possibilidade de se empoderar e pegar as rédeas de sua experiência. Você não gosta de um botão? Tira ele. Você prefere um atalho para uma certa página? Adiciona. Você quer que a página seja atualizada a cada 5 minutos? Só fazer!

Infelizmente existe um incentivo a sermos somente espectadores de nossa vida, inclusive na internet. Mas nossa vida não precisa ser assim! Use os navegadores, se empodere! E melhor ainda, compartilhe seus scripts e divulgue aos seus amigos todas as possibilidades que os computadores nos dão!

Gostou? Me segue lá no insta para mais dicas! @code_elias_code

Como eu me preparo para entrevistas no exterior

Era — Wed, 28 Sep 2022 07:51:42 +0000

(baseado em um post meu no instagram)

(originalmente postado em: https://br.elias.sh/posts/entrevistas/ )

As entrevistas para as grandes empresas de tecnologia no exterior tem uma forma de entrevista similar. A parte que mais varia é a de soft-skills, que geralmente vai perguntar sobre o seu passado para saber se você é um bom cultural fit para a empresa.

Por causa disso, quando estou pensando em mudar de empresa, eu geralmente reviso os mesmos materiais, independentemente das empresas que irei entrevistar. A única exceção foi a Amazon, que eu ainda não conhecia essas dicas e acabei passando para Software Engineer L4 somente com o que tinha aprendido no Mestrado¹. Esse conteúdo me ajudou a passar nas empresas: MongoDB, Stripe e Huawei.

Normalmente alguma pessoa recrutadora vai fazer a primeira “entrevista”, que é basicamente para te falar da vaga, da empresa e ver se faz sentido mesmo continuar. Após essa conversa inicial, você terá que resolver algum exercício de programação. Geralmente é algo de nível médio, você provavelmente vai ter que usar alguma estrutura de dados específica ou Programação Dinâmica. Você também terá que discutir a complexidade do algoritmo (em Big O). Algumas empresas aqui podem pedir um projetinho básico (e.g. um app de TODO) ou para você comentar sobre algum design de sistemas.

A segunda parte é normalmente uma ligação com alguém do time que é focada na parte de programação, você terá novamente que programar algo de nível médio de dificuldade na frente de alguém. O segredo aqui é fazer várias perguntas para ver se você realmente entendeu o problema. Caso você esteja travado, tente conversar com a pessoa que está te entrevistando. Muito provavelmente ela irá te dar dicas.

A terceira parte é uma tarde de entrevistas com 4 ou 5 pessoas do time. Aqui você normalmente tem: uma entrevista com o gerente (soft skills), uma sobre programação, uma sobre design de sistemas. As outras entrevistas do dia variam de empresa para empresa, você pode ter que conversar com alguém do RH, pode ter que debuggar um problema ou pode ser só mais uma entrevista de programação.

Para estudar para esses temas eu uso:

donnemartin/system-design-primer: Eu geralmente reviso todo o conteúdo do repositório, é deverás util para as perguntas de design de sistemas
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems: Eu gosto desse livro para me aprofundar em temas de design the sistemas. Eu já li o livro algumas vezes, então eu leio capitulos especificos que eu sinto que nao lembro o suficiente dos detalhes
leetcode: Leetcode é um site onde você pode praticar resolver problemas bem parecidos com os das entrevistas. Eu fico resolvendo somente os médio e fáceis. Eu não vejo muita utilidade nos mais difíceis.

Digo no mestrado porque tive que usar muita estrutura de dados e algoritmos na entrevista e isso eu aprendi de maneira aprofundada na Unicamp. ↩

Oncall ou o famoso plantão para engenheiros de software na Irlanda

Era — Sat, 24 Sep 2022 18:22:10 +0000

Quando se trabalha no desenvolvimento de algum produto com clientes externos é comum a prática do “oncall” (plantão). O formato varia de time para time mesmo dentro da mesma empresa. É importante notar que indiferente da empresa, ela ainda precisa seguir o Organisation of Working Time Act, 1997.

Nas duas empresas que trabalhei na Irlanda, elas me forneceram celular (para eu instalar o aplicativo que notifica de problemas em produção). Na Amazon, o formato do meu oncall era de 8 horas por dia, pois o plantão era divido entre o time nos EUA, Austrália e Europa. Todo final de semana que ficavamos oncall era recompensado com dois dias de folga. Independente do tempo que gastamos ativamente trabalhando. Esses dias podiam ser retirados a qualquer momento.

Outros amigos que ficavam oncall por 24 horas na Amazon recebiam um valor adicional no salário.

Na Stripe o formato do oncall é de 24 horas também, mas sem nenhum incentivo financeiro. Porém as horas trabalhadas podem ser recuperadas. Por exemplo: recebi uma notificação que tenho que trabalhar e demorou uma hora para consertar o problema, então tenho direito de pegar uma hora em algum outro dia.

Um ponto importante da lei irlandesa é que todo empregado tem o direito de 11 horas consecutivas de descanso em um período de 24 horas (“11.—An employee shall be entitled to a rest period of not less than 11 consecutive hours in each period of 24 hours during which he or she works for his or her employer”).

Nas duas empresas, estar de plantão nunca significou resolver o problema sozinho, mas avaliar o que está acontecendo. Se você consegue resolver, ótimo, mas caso não saiba ou precise de ajuda dado o volume de problemas, sempre há um caminho claro de quem você deve notificar. No geral, o conselho era: se em dúvida, notifica outra pessoa.

Normalmente as soluções ou dicas de como debugar o problema estão em documentações internas, “runbooks”, essas documentações normalmente explicam como confirmar qual o problema e possíveis soluções.

A melhor dica para o plantão é: mantenha a calma, procure o runbook ou uma ocorrência do problema no passado, em caso de dúvida, “escale” o problema.

PS: Originalmente publicado em aqui.