Posts

The Cost of Silence

Image
All engineers and professionals in the tech industry, at least one time or multiple times in professional life, suffered from impostor syndrome. Besides the impostor syndrome, as humans, we dont like to receive bad feedback. Remote work can often be a source of more silence than would usually happen in a face-to-face work environment. Everyboddy is on the call with the video off, just audio, why would you turn your video on? You are joining a new team, you don't ask questions, you wait for the last minute when you need to code something, then you "might" ask questions. It's possible you are wondering now: What do impostor syndrome, zoom calls, onboarding new team members, and asking questions have to do with such a blog post? Is it all ramblings? No. All these moments build up on something I'm calling: The Cost of The Silence. Silence is not desired; meetings that are supposed to reduce the cost of silence, like Daily meetings, fail the goal and often just bring w

Refactoring: Making sense of the invisible

Image
Refactoring is so underrated and misunderstood. There will never be enough books or enough blog posts about it. It's something that we need to keep revisiting from time to time. Very few people deeply understand it, but one thing is for sure: genuine and spread across the whole industry like wildfire: fear of refactoring. Fear can be a powerful feeling and an excellent way to keep you in check with reality, especially in difficult economic times. Still, fear can also be a significant source of blindness, inertia, and illusion, leading to bad economic decisions. Refactoring is not a binary decision; you either do it all and re-write the system or do zero-to-nothing. Companies and engineers need to apply more refactoring daily , and this matter is definitely unbalanced. Software at scale makes complete rewrites almost impossible. No company can stop the business for years and still succeed; many companies have tried and failed financially and in rewriting. So don't do more refact

My second book is out: Principles of Software Architecture Modernization

Image
After 1+ year of hard work, my second book is finally out. Introducing: Principles of Software Architecture Modernization: Delivering Engineering Excellence with the art of fixing microservices, monoliths, and distributed monoliths. I've 20+ years of experience with technology and have been an architect and a technology consultant for most of this time, software architecture is a deep passion of mine. It is a huge pride and joy, for me to come here today to share this with you, my friends, and dear readers. 🎉🎉🎉 I deeply appreciate all the blessings God has given me, from my family, my daughter Clara, my wife Andressa, my work, and my friends. It was not easy to write this book 📘, there was sweat, blood, and tears, lots of remote work with my co-author Sam . Rest assured you are getting my passion, vision, and perspective of software architecture. First and foremost the book is about principles, tradeoffs, and software architecture design at the heart of complexity. The book is

Continuous Refactoring

Image
Software is very interesting, it's amazing how little things make a huge difference, being able to see all the small intricacies and how the pieces fit together is a complex and fascinating task. The more we understand, the more we learn effectively, better we can do it. Software complexity does not reduce, it only grows, working with a relentless mindset of continuous improvement is the only way to go forward. Refactoring is often seen as a "bad word" a big spooky thing because everybody believes is busy, so why are you risking breaking a lot of things if you can move forward and "live" with the problems. XP (Extreme Programming) got this right from the get-go, you need the principles and values. XP has a value called: courage; courage to do refactoring, especially when the conditions are not in your favor, considering monoliths and distributed monoliths the odds are never in your favor. Once you start doing so, slowly put all guardrails in place, would such c

The Death of CI/CD

Image
XP (Extreme Programming) leaders popularized CI (Continous Integration) in the late 90s. The idea was very simple, to continuously integrate code in a common branch usually called trunk, nowadays we call it main. The principles behind CI were (A) Reduce feedback cycles (B) Increase response time and release software faster. CI it's a powerful concept, that requires automation of the build process and of course, automated tests. In order to do CI you also an SCM (Source Code Management system), in the past there were various solutions like CVS (not a drugstore), SVN, and GIT rules today. By definition CI also requires continuous merging, which leads to interesting realizations like, how often should we merge, the answer is as much as possible, as frequent as possible. Today's environments are more complicated than they were in the 90s, back in that time, the CI process was generating one single binary. 

Principles for Code Reviews and Reviewers

Image
Last month I was blogging about how code review is dead . Today I want to share some principles and practices to make things better. In the previous post I shared some actions, now let's understand the principles behind many of these actions.  First of all, can we save code reviews, and make them better, for sure we can. It's not that hard, for the code review it self-improve we need a couple of things in place. Usually, engineers have the same complaints like It takes a long time to do code reviews, there are too many files, I don't know this code or this service, etc... The fact is there are multiple mindset problems here. 

The Death of Code Review

Image
How we work matters, a lot. Unfortunately, very often engineers and managers don't care about engineering working practices, which is a big mistake. How we work is the key to heaven or the highway to hell. Code review is a pretty default practice, it's everywhere, companies do code review, at least that is what they claim. But how good is the code review? How many times do you need to be chasing engineers to beg them to merge your code? How many times are you actually getting useful feedback or bugs are being caught? Very often engineers don't prioritize code review, which means that quality is not being prioritized. Quality, to some degree, needs to be prioritized and to some degree enforced. There are many forces that make code reviews skipped and not performed with the due diligence that they need such as unrealistic release pressure, lack of critical talent density, poor engineering culture, low standards, and many other factors. Some languages have stronger type system