Kenneth Freitas

Pair Programming é uma prática que eu a-do-ro fazer. É um momento em que temos 2 profissionais juntando forças para criar o melhor resultado de alguma tarefa, seja um algoritmo complexo ou algo grandioso, onde um acelera o outro. Porém, na realidade (ahh a realidade…) não é bem assim, e na grande maioria das vezes gastamos tempo, não de um dev, mas de dois. Então, bora trocar uma ideia sobre como tocar um pair programming maneiro com o mínimo de desvios possíveis e, com sorte, não gastar muito dinheiro com dois devs. Antes de tudo, precisamos deixar algumas coisas extremamente alinhadas para que tais práticas deem certo, são elas: Pessoas: Não adianta querer implementar tais atividades colaborativas se as pessoas envolvidas não são tão colaborativas assim. Nisso, nem entra o fato da pessoa ser mais fechada ou não, mas é muito comum que, diante de um problema ou algo que necessite de esforço, fazer sozinho aumenta a concentração e não adianta tirar a pessoa da linha de raciocínio. Porta...

I have had my Microsoft/Azure certifications for a while, but I completely forgot to write about them. So, after some requests, let's gain a real understanding of them. To be honest, I have mixed feelings about these certifications. Some of them are quite interesting, while others are less appealing. Certifications that rely solely on multiple-choice questions, step ordering, or something of that nature (where the answer is readily available in the options) don't sit well with me. In contrast to the Node.js and Kubernetes certifications, which involve hands-on tasks, Microsoft's certifications seem to serve more as decoration; practical knowledge isn't necessarily a requirement. The primary issue with this type of exam is that it doesn't effectively validate whether the certificate holder truly possesses knowledge of the subject. This is especially evident when we consider the existence of black market exam dumps, but that's a topic for another article. Exams ...

A Síndrome do Impostor não é um assunto novo no mundo da engenharia de software. A constante evolução da tecnologia, ferramentas e modismos que sempre surgem faz com que tenhamos a sensação de não saber nada e que é impossível acompanhar. Bem, existem vários artigos e vídeos na internet falando desse sentimento tão comum, que devemos confiar em nossas potencialidades, etc. No entanto, a realidade é que, às vezes, somos realmente impostores. Ter esse autoconhecimento é extremamente importante para a evolução pessoal e profissional. Já comentei em outros artigos que a senioridade é algo volátil, e cada empresa tem sua própria régua. Às vezes, realmente damos um passo maior do que a perna, e algumas expectativas não se concretizam. Portanto, reconhecer-se nessa situação é tão importante para melhorar essa condição. Em um dos meus primeiros empregos formais como desenvolvedor, comecei atuando com uma tecnologia que tinha estudado muito, até porque estava tentando entrar na área. Coincident...

Após ler esse excelente artigo , decidir comentar um pouco sobre o processo de realizar entrevistas técnicas.  Como muito bem comentado no artigo, realização de entrevistas técnicas é algo trabalhoso e caro, trabalhoso, pois parar para analisar o candidato, entender os requerimentos do papel, nivelar perguntas e criar desafios técnicos para entender o candidato e por último criação de laudos e reporte para lideranças, demanda bastante tempo. E caro, pois todo esse trabalho exige certa senioridade técnica e de gestão, fazendo com que pessoas realmente capacitadas para esse papel diminua bastante. Pior, geralmente esse tipo de profissional tende a ter funções importantes nos projetos e times, parar tais profissionais é um custo e um risco. Então, como se tornar esse profissional tão visado e tirar melhor proveito da filtragem e entrevistas para realmente ser compensador? Bora lá! Antes de tudo, precisamos ter consciência do cenário em tecnologia, principalmente na visão de desenvolve...

I got every Kubernetes certification in the last months, and as I said at the Node.js certifications , the Linux Foundation certification it is nice because they are practical, you must test your hands-on knowledge. Kubernetes and Cloud Native Associate (KCNA) This is the first one and the easier, it is the only that is multiple choice and cover the foundation knowledge about cloud, containers, etc. To be real, it really not worth waste time and money to get that. Certified Kubernetes Application Developer (CKAD) If you are already a developer, that works with a Kubernetes and you have access and permissions to create resources that are important to a day-to-day for microservices, this is a pretty simple one. Basically, test your knowledge to containerize applications and create all necessaries of things to put online, like deployments, etc. Certified Kubernetes Administrator (CKA)  Here the thing start to be a little complicated, you must have a good knowledge about linux, and oth...

A lot of people came to me, arguing that it is hard to get a job even with a wonderful portfolio. When I start to check out the developed projects, quickly I can see what I call the "cool project" antipattern. When we're beginning to create things in our learning curve, we tend to replicate the courses, tutorials, etc. That compose our first knowledge, this is the first indicator, a lot of people have the same portfolio. The cool project antipattern starts after that, we already have some knowledge how the things works and what we can do. So the next step into the knowledge curve is created our own things. Example, thing that you have done an incredible interface with some cool framework that use an API in real-time to notify and response WhatsApp messages. It's really cool, but when you come to show this project into an interview. The interviewer want to know our knowledge about it. If we pause and look your project in details, we can see that as a lot of stuff invol...

More and more we see giant companies back to the idea of work in the office or hybrid way, these movements are explainable to be the fact exists employees that abuse from the situation and of course bad leadership that want to see their leds. I love working from my home and I will defend this so way before the covid pandemic, but as a leader also, I can see terrible behaviors and maturity in some people when work in this way, creating this environment of insecure for the company create a truth into the employees. So let's see some "good practices" for work from home to get the confidence for your company and your leader to you continue to be able to work from home. - Dailies: This is a pretty important meeting to align the sprint goal or simple a status report that happens every day, it is a great opportunity to show how was your day, and you're planning for the next one, really getting into this type of meeting increase the leader confidence to you as normally the p...

After a long journey about tests, the tools available, strategies and what to avoid, let's see good practices! How to write and maintain a good tests code base. - Clear and Concise: The test must be simple and easily to understand that the goal of the test and what it is testing. - Repeatable: I can run the same test a hundred time, and it must always return the same assertions for the same input. - Comprehensive: Must be simple to see all the things that the test uses, the AAA pattern is a good example to make clear the steps. - Independent: You must be capable of running any test individually, cannot have coupling between tests. - Validated: Well, it must validate something. - Traceable: If you are testing a method that fail, the return must be traceable to point to the original implementation, for you found the code easily. - Maintainable: Again, tests are code, so remember, if you create test for all your code, you will have two code bases at the end, so treat them equally...

There are a lot of options to organize our test, but let be aware in some details to no fell in some common traps. One test, a lot of cases: The hurts the one of the most important programming principle that is separation of responsibilities, remember one test, one case, try to create a single test that assert a lot of different case is awful. You lose the big part of the benefits of tests. Tests without assertions: Well, stranger but is very commons into a bad developer to hack the tools that verify code coverage, I will not say anything because, if a test does not have any assertion, do not test anything, so is same thing of nothing. Lack of Isolation: We see a lot of strategies to cover the real world, but if something is not properly configured, some lacks can happen and your test maybe is actually making an external request or create something at the database, this is really dangerous. Coupling between tests: Imagine that you will test a repository and the first test insert so...

 If tests are code, organizing them are extremely important. thinking about files organization, the most two common approach are: - My file, my test: The test file stays side a side from the original code, normally only differentiate by the extension. - The test project: A "folder test" that replicate the original project structure, brings the same file as their tests representations. Tests normally allow a lot of sublevels in details, like a general descriptions and tests cases, you can get this pattern to easily categorize the tests and get a better representation of what the test is, what does, and where, like: The object to test   The test case premise     The case     The case     The case   The test case premise     The case     The case When we are written the actual test, a good way to organize it is using the AAA Pattern: Arrange, Act, and Assert. This pattern is very common way to easily identify the dependenci...