[{"content":"Muito do conteúdo que cresceu e se espalhou nos últimos anos sobre tecnologia é de como ingressar na carreira. Mas e depois que você já está na área, como subir de nível? Como sair da estagnação? Como dar fim naquela angústia de que não estamos alcançando o próximo nível?\nO que é estagnação? Como identificar? Estagnação é um estado, uma situação em que nos encontramos quando não estamos evoluindo. É quando não estamos aprendendo nada novo, não estamos nos desafiando de forma saudável.\nEm toda minha carreira, eu sempre identifiquei essa situação quando:\nMeu salário não aumentava conforme minhas entregas. Minha experiência não aumentava conforme o tempo. Se você está se sentindo em algum dos dois pontos acima, você está em estagnação.\nPara quebrar esse ciclo, precisamos entender que:\nEntregar constantemente não é exatamente ser eficiente. Experiência e tempo de carreira não são a mesma coisa. Enfrentar essa dura realidade vai tornar sua vida mais fácil.\nComo subir de nível? Existem várias maneiras de evoluir na carreira, mas vou listar aqui as que reuni ao olhar pra minha carreira e de pessoas que admiro e que foram ou são minhas referências.\nParticipe das reuniões Se sua presença foi solicitada na reunião, sua opinião também foi. Para evoluir na carreira você precisa se posicionar nas reuniões, sendo fazendo críticas ao que está acontecendo, dando ideias ou até mesmo perguntando fazendo questionamentos - principalmente em reuniões de planejamento.\nÉ muito comum em times de desenvolvimento de software poucas pessoas falarem. Geralmente as pessoas que falam são as mais experientes, e não precisa ser assim. Se você tem uma opinião, fale. Se você tem uma dúvida, pergunte. Se você tem uma ideia, compartilhe.\nConheça profundamente o negócio Falta de entendimento do negócio é muito comum em pessoas desenvolvedoras de software. É quase raro encontrar pessoas que entendem o negócio e sabem fazer críticas e questionamentos sobre o futuro dos produtos e soluções que a empresa oferece. Boa parte desse problema deve-se ao fato de que há uma falsa ideia de que desenvolvimento é sobre código. Código é só um meio pra resolver um problema que, algumas vezes, pode ser resolvido sem código algum - ou com o mínimo de código possível.\nA inabilidade de conhecer o negócio se reflete na eficiência. Como você pretende ser eficiente se você não consegue entender o fruto do seu trabalho? Como você pretende ser eficiente se você não consegue entender o problema que você está resolvendo?\nTrabalhe com outros times Empresas de tecnologia costumam ter áreas com diversos times, cada um trabalhando em um ou muitos projetos que fazem parte do negócio. É muito comum que times de desenvolvimento de software trabalhem isolados de outros times, mas isso não é eficiente.\nInvariavelmente, algumas pessoas vão fazer pontes com outros times. Se você pretende evoluir na carreira, essa pessoa precisa ser você. Pense nas features que o time tem desenvolvido e saiba comunicar outros times das mudancas, solicite feedbacks, testes ou até codifique em repositórios de outros times.\nEntenda além do código Você compreende como os programas do seu time rodam? Como é feito o deploy?\nÉ essencial que você entenda como o código que você escreveu é executado. Isso vai te ajudar a entender como o seu código se comporta em produção, como ele se comporta em situações de erro, de alta demanda e vai te dar base para entender possíveis \u0026ldquo;corner cases\u0026rdquo;. É muito comum encontrar pessoas que não sabem como o código é executado, como o deploy é feito, como o código é testado, como o código é monitorado e como o código é escalado. Se você quer evoluir na carreira, você precisa entender isso.\nA alta demanda dos anos recentes forçou o mercado a contratar pessoas que compreendem apenas código, resultando em equipes inchadas e disfuncionais. Como recém aprendemos que código é só uma parte de um software, é natural que as empresas busquem pessoas que entendam além do código e que possam suprir necessidades que não são atendidas por pessoas que só sabem escrever código.\nEntenda sobre custos Produzir software custa muito caro. Times que usam inúmeras ferramentas pagas, bancos de dados caros, serviços de integração caros tendem a tornar o software muito mais custoso do que poderia ser. É claro que você não deve abrir mão de ferramentas que te ajudam a desenvolver melhor, mas entenda que elas custam caro e que você pode não precisar delas pra ter o mesmo efeito. Isso é eficiência.\nColocar um banco de dados desnecessário em uma aplicação vai adicionar mais custos. Adicionar Elastic Search em uma feature na qual um banco relacional daria conta é, também, uma despesa desnecessária . Aplicações que não tem suas métricas de performance em dia também custam caro, pois elas vão ser escaladas sem necessidade real, sem ter demanda que justifique.\nE não menos importante, focar em soluções mirabolantes também é custo. Foque em soluções que sejam fáceis de mudar ou de remover. Todo código que gera dependências gera custo na hora de dar manutenção ou remoção.\nEntenda sobre FinOps, consulte as pessoas na empresa que já discutem esse assunto. Caso não esteja sendo discutido, seja a pessoa que traz o assunto e busca diminuir os custos.\nAjude pessoas menos experientes Ninguém vai te falar que você precisa ajudar pessoas menos experientes. Ajudar outras pessoas é uma via de mão dupla: as pessoas menos experientes vão ter mais sabedoria pra resolver problemas, e você vai ter mais tempo pra resolver problemas maiores.\nIncentive as pessoas a trazerem ideias e soluções. Não faça pareamento apenas de código, mas de documentação, de passagem de conhecimento do negócio, compartilhe ideias e dê espaço pra elas serem protagonistas, também. As pessoas vão perceber que você está pavimentando a carreira das pessoas, ao mesmo tempo que você foca em problemas mais urgentes. Aquele refactor de código é importante, mas ele não deveria mais ser sua prioridade.\nReflita sobre quais das coisas acima você tem feito. Se você não está fazendo todas, comece a fazer. Se você não está fazendo nenhuma, você provavelmente já está atrasada - mas não entre em pânico, não é tarde pra começar.\n","permalink":"https://samambaia.dev/posts/subindo_de_nivel/","summary":"Muito do conteúdo que cresceu e se espalhou nos últimos anos sobre tecnologia é de como ingressar na carreira. Mas e depois que você já está na área, como subir de nível? Como sair da estagnação? Como dar fim naquela angústia de que não estamos alcançando o próximo nível?\nO que é estagnação? Como identificar? Estagnação é um estado, uma situação em que nos encontramos quando não estamos evoluindo. É quando não estamos aprendendo nada novo, não estamos nos desafiando de forma saudável.","title":"Subindo de nível"},{"content":"System design is a critical aspect of software engineering that involves identifying user requirements, analyzing problems, defining system architecture, and developing a prototype. The goal should be always to create a robust and scalable system that meets the needs of the users. In this note, we will discuss the key components and processes involved in architecting software.\nKeep in mind that every project and company have their own limitations. And we, as humans, also have our limits defined by how much we know about the business and the technologies involved. Problems may create limitations, and some of these limitations may get really hard to overcome.\nTo illustrate the concepts discussed, we will use a case study of a system that extracts thumbnails from live streams and inserts them into a database to be queried further. The system design will address scalability and reliability concerns, and the database used to store thumbnail data will be agnostic.\nYoutube, for example, shows in the seek bar a thumbnail with the exact image the program you were watching, you just need to hover your mouse over the seekbar. It is a very useful feature for live stream you can watch the past minutes.\nIdentifying user requirements The first step in system design is identifying user requirements. In the case of our thumbnail extraction system, the user requirement is to extract thumbnails from live streams and store them in a database. Users should be able to query the database for specific thumbnails based on parameters such as the time the thumbnail was captured, the stream it was captured from, and other metadata.\nAnalyzing the problem Once we have identified the user requirements, the next step is to analyze the problem. We need to consider factors such as the number of streams the system will handle, the frequency of thumbnail extraction, and the amount of data that will be stored in the database. For example, the number of the stream and the thumbnail quality will impact the amount of storage we will need, increasing the cost and the latency of our queries.\nDefining system architecture After analyzing the problem, the next step is to define the system architecture. In the case of our thumbnail extraction system, the architecture would consist of a set of components that work together to make available all the stored thumbnails to users.\nA component that process live streams and extracts thumbnails from them. A component that inserts all extract thumbnails in a database. A query component that enables users to query the database for specific thumbnails based on parameters like datetime, width and height. Diagrams are tools to facilitate the understanding of how things get connected.\nThumbnails extractor diagram In my experience, beginners have less difficulty trying to understand complex systems with visual information.\nDeveloping a prototype Once the system architecture has been defined, the next step is to develop a prototype. The prototype should be designed to test the system architecture and identify any potential issues or limitations. In the case of our thumbnail extraction system, the prototype would involve developing and testing each component of the system.\nDesigning a system involves a critical stage where we get closer to reality, making it one of the most crucial parts of the process. Although in theory all our ideas should work, it is common to face challenges and iterate in order to find more accurate solutions to problems.\nA concrete example: to extract thumbnails, one of the best tools to do the job is ffmpeg. And how does ffmpeg extract thumbnails? Ignoring the multitude of options and flags available, ffmpeg saves every thumbnail in the filesystem. Would it be easier if ffmpeg could send all the files through an API? Problably, but we would end with different problems: network connections are more susceptible to fail, and they will be much slower than writing a file to the disk. Since we are doing with realtime systems, we need to account every time we lose passing information around.\nIterating Asking questions is one of the most valuable ways to find answers. Ask, for example, how long our thumbnails will stay in the database? Since these are thumbnails from live streams, do they need to live forever? If not, how could we remove old thumbnails? Using strategies like defining a TTL to every thumbnail might be an alternative to solve the problem. Then it brings other questions to the table: how to query the database? Which structure are we going to use? Defining the right data structure to the problem may be a hard job but it will pay the time we take to choose them more precisely.\nOther topics to consider Keep in mind that the ideas mentioned above are general considerations to apply when designing a system. However, there are many other essential topics you should be concerned about, such as scalability, monitoring, performance, cost optimization, and more. Designing a robust system is a highly complex task that requires careful attention to various aspects.\nI will talk more about these topics over the time.\n","permalink":"https://samambaia.dev/posts/a_basic_approach_to_systems_design/","summary":"System design is a critical aspect of software engineering that involves identifying user requirements, analyzing problems, defining system architecture, and developing a prototype. The goal should be always to create a robust and scalable system that meets the needs of the users. In this note, we will discuss the key components and processes involved in architecting software.\nKeep in mind that every project and company have their own limitations. And we, as humans, also have our limits defined by how much we know about the business and the technologies involved.","title":"A basic approach to systems design"},{"content":"Hello there! I\u0026rsquo;m Maurício, born in Brazil in 1990. I\u0026rsquo;m happily married and, alongside my spouse, I share my life with a dog, Bentinho.\nMy journey in the world of technology started back in 2009, and since then, I have been passionate about all things tech-related. Over the years, I have had the privilege of contributing my expertise to a variety of successful software projects, including e-commerce platforms, portals, CDNs (Content Delivery Networks), and a video streaming platform (Globoplay).\nMy fascination with technology goes hand in hand with a relentless drive to explore new possibilities and embrace challenges. Each project I take on fuels my desire to create innovative solutions and deliver valuable experiences to users.\nIn this blog, I aim to share my knowledge, experiences, and insights gained throughout my career in the tech industry.\nCurrently, I lead a team responsible for all the live video content streamed by Globoplay - the largest media company in Latin America.\nFeel free to connect with me and share your thoughts.\nWith love, Maurício ❤️\n~ family ~me, my wife and my dog\n","permalink":"https://samambaia.dev/about/","summary":"About me","title":"About me"}]