Diego Pacheco Tech blog

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

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. 

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.