Diego Pacheco Tech blog

Almost 3 years ago, in 2023, I wrote a blog post about the death of code review . It hasn't been that long, but software engineering has changed a lot in the last 2 years, and there is a tendency to change even more in 2026. Back in 2023, I was not even talking about AI being the "killer" of code review; it was a series of things: people not paying attention, LGTM without any effort, and a lack of prioritization. So we need to understand that code review was always an important practice, but even without AI, it was already in decline, and people were doing it wrong. Back in 2026, there were even stronger forces pushing code review to die or to change significantly. Most engineers dislike doing code review. I do like code reviews. I found code review useful and an important tool to enforce consistency. However, the disruption with code reviews is inevitable... 

IF you talk with engineers, software architects, managers, pretty much everyone, the answer will be the same: they are not happy with shared environments. We can narrow down shared environments to common envs like dev, test, stage, demo, etc Pretty much all non-prod environments suck. That is the reality in our technology industry. I don't think I ever liked any env in any company, so think about this: did you ever see a non-prod env that you liked? Now the answer for this problem is very weird because if you talk to people, what do they say you you? IF we could have one more environment them we would get it right. So my question is, why can't we get it right in the environment that we have in the first place? Why do we need a new one? In fact, we don't need it. 

If you look up on dictionary.com the first two definitions of state are: the condition of a person or thing, as with respect to circumstances or attributes: a state of health. The condition of matter with respect to structure, form, constitution, phase, or the like: water in a gaseous state. Software is all about data, which is the state. The state could be your basic data, such as your name, last name, address, phone, email, bank account ID, or any other IDs and information you might have. Buying software has many side effects, many of which  are negative . Such data needs to be captured somewhere, usually in a relational database. But it could be in any other data store like a NoSQL Database like Cassandra, a K/V store like Redis, or an object store like S3. Ideally, the state should be contained and even isolated. However, in distributed systems, we often need a distributed state. The state is necessary. However, we might create additional complexity if we don't deal with the s...

We are in the holiday season. You walk into any Starbucks and see the Christmas decorations. Lights and Christmas trees are everywhere, and the advent of code is still rolling. Whether Xmas is summer or winter, You can get some specials and flavors only on Xmas. Now, you must wonder if this is a technical blog post; yes, 100% it is. I promise there will be a point at the end. Let's imagine a very different coffee shop experience; in reality, it's not how I will describe it, but hopefully, it will help you to see my point. I'm pretty sure you've gone to a coffee shop before; how it works is simple: you look many for what coffee + snacks you want, you get in line, pay at the cashier, and then the barista will brew you coffee, warm your food, and you will be good to go. If it is a good place, they will call you by name. Now, let's imagine a very different experience. Consider this the upside-down Xmas experience. However, if you want to name it, I will give you my nam...

Every single day, engineering teams need to do magic. Such magic manifests in several different shapes and forms. It could be by making hundreds of assumptions, figuring out what to do with little to zero context, and delivering decent solutions with proper architecture, design, comprehensive testing, and value via continuous delivery. It's a lot. In reality, most industries use Scrum/SAFE, which is far from the best way to work. In theory, when you are doing Scrum, if you do not finish a story during the spring, it's not a big deal; you go to the next one, shift the stories to the following spring, and it's all good. However, in reality, it is not exactly like that, unfortunately. That happens for various reasons: ignorance of what proper agile looks like, irrational pressure, industry pressure, and hundreds of other uncontrolled and hidden variables. Lean is all about learning to see waste, remove it, optimize it, and improve it with more quality. Companies, unfortunately...

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. 

Once upon a time, Design Patterns was a big thing. In current times, perceptions have shifted and the industry has mixed feelings about them. I've thought a lot of blogging about design patterns was worth it or not. I used a lot of patterns in my life, there were moments when I was completely okay with design patterns, and other times not so okay. I got some mixed feelings but today I think they are fine. IMHO there are some fairness and some misconceptions. There are hundreds of Design Patterns, there are patterns for everything you can imagine. Usually when people complain about patterns they are talking about OOP patterns, more specifically from the 90s book from the GOF .   Patterns are not limited to OO, there are functional programming patterns, system programming patterns, OS patterns, cloud computing patterns, frontend patterns, and mobile patterns. Lots of these patterns are very similar, at the end of the day not all problems are that different, and are all about ideas an...

Complexity is everywhere. Small, medium, or big company, does not matter, no one can escape complexity. Complexity just tends to get bigger, we depend on software more and more. Ask yourself, if your subscriptions on iPhone are increasing or decreasing in the last 5 years. There is more competition, and more streaming providers, and everything becomes a subscription, from grocery to transportation to even video games. Complexity increases, maintainability decreases, and maintaining software becomes harder. More software, more complexity. Complexity needs to be fought 24x7 at all times. However, how can we figure out something if we don't fully understand it? Is easy to just give up and do whatever since there is no escape, but there is a better way, we can do better. So what is complexity after all?

Code review it's standard practice. Most of the industry does this via some git-based tool like Github, Gitlab, or any other flavor. These tools are based on deltas or diffs. They are really good for spotting what changed, so you can get that single character who would give you a big headache. When I started working with software, there was no git; people were using CVS in the best case when code was not being versioned in a folder with the sufix backup. I learned to do code reviews without any Delta tool. However, any CVS tool would have a diff capability there. IMHO Deltas are not enough nowadays, dont get me wrong, they are useful, but they have several gaps and issues. I'm not trying to blame the tools or to start any rant or say that CVS is better than Git, which it is not. I simply want to take a different perspective on reviews.

In the matrix movie(classical and awesome movie), there is a classic scene where Morpheus challenge Neo's understanding of reality and offers 2 pills the Blue one which would keep the status quo, and the red one, which could be painful but would be the reality.  If you have a successful company with software thats the reality of the industry. In other terns, the discussion can seem as should we re-write the software or should we strangle it. Re-write software and even strangler patterns have cases of success and failure. Before we enter into the trade-offs of this complicated dilemma lets us understand the forces which create problems and opportunities that are around this discussion. Let's talk more about the context and their trade-offs. 

From trait in Rust allow types to be created or converted from other types. From trait is used in the rust standard library. It's simple and yet effective. Is common to see From used with Into. However today I want to focus on the From trait. Thinking about coupling point of view you end up coupling 2 or more types, however, in sense of convenience is pretty useful since you dont need to lookup for other structs or external converters. You can use From in order to make it easy to convert from basic types to your types.I have a simple video showing From trait in action. Let's get started!

Rust is rich in sense of types. You can create your own structs and use generics. Rust even allows you to create a type alias. IMHO type alias is useful for 2 reasons. The first type alias makes the code more readable since the type alias can make the intention more clear. The second and less obvious is when you have generics because you can use the type alias to hide or save typing a big generic expression. However, this is a double edge-sword, at the same time is pretty useful to avoid typing and make the type construct proper it really could be hiding some unnecessary complexity. I have a video showing type alias in action. So let's get started.

Java is the backend solution for several companies, mainly for services and microservices. However, when you need to ship java for a CLI or DevOps solution java is a bit verbose. First, because you need to have a JDK, and second java by default is not self-contained. Meaning you will java multiple jars and if you are not running on a standalone server or using a framework like Spring Boot this could be a bit annoying. There are other solutions like you could be doing a Uber Jar or Fat Jar where you can bundle your app + dependencies in one and one jar. Today I want to share a bash trick where we can embed a Java jar into a single bash script. This trick is neat because with a single file we can combine bash and java. 

Podman is the new cool kid on the block. Podman is a deamonless container(OCI) engine for Linux. It's the natural open-source Docker replacement. Docker recently changed the license and plans. Podman commands and flags are compatible with docker and the replacement is very smooth. OCI makes things much more simple and portable. So today I want to share how we can install and use podman. So let's get started. 

This is not a production-ready neither serious parser, it's for pure fun! I was bored during one of the pandemics late nights watching Sam Rose's 3h parser video . So I decided to do something similar, inspired by Sam's video. Of course, I did not want to make a 3 hours video fighting Rust compiler - which is the ultimate reality but something shorter. The code is similar but I have few more operations like * and inc.  I also using a queue for Args not Stack so we can preserve ordering. So this is a cool way to learn rust because in the code we will be using Stack and Queue Data Structures and basics of borrow and ownership in rust. Let's get started!

Vector is a core collection in Rust. Vector(Vec) can be used for storing a list of values or even if you need a Stack - it's your data type. Rust language is pretty fast and secure however dealing with borrowing, ownership, and lifespan lifecycle is a high wall that often you can bash your head pretty hard against it. Returning Vecs and passing them as parameters could be pretty challenging if you were new to Rust. Strings also are pretty challenging in Rust. So today I want to share a video doing common operations with Vecs but always using functions and passing Vecs and Receiving Vecs. Hopefully, this will be useful in your common and daily work with Rust. Let's get started!  

I want to share my cents about the post: " On the Diverse And Fantastical Shapes of Testing ". First of all, I believe this is a very interesting subject and yet still see very few engineers talking about it. People mostly take tests for granted. Secondly, I would like to acknowledge the parts I agree with on this post mainly around the concept of Sociable and Solitary Unit Tests are quite useful and show be widespread. Also with the need for teams to have reliable, fast, Bounded(Isolated) and not Flacky on Justin tweet . Now that I acknowledge that, let me elaborate on what I think we are missing and why IMHO the pyramid is dated and we need a mentality shift. I have 4 points I want to elaborate on and give more context.

Every company out there works with teams. There are all sorts of teams such as teams specialized in technology stack like Hadoop or teams which are domain-driven and have cross disciplines( Cross-Functional Team ) inside such as backend, frontend, QA, UX, Architecture, and more. People don't leave companies they leave teams, also it would be accurate to say that people don't join companies and they join teams. So should we have dynamic or static teams? Should teams self-assemble or should we have PMO doing that? Should the teams be stable or should we allow dynamic reteaming? Is work always fitting well in our team's structure? What about Platform vs product teams, which one is best? Should we just pick one model or should we use different models? Should engineers organize around managers or managers organized around engineers? Teams affect Architecture and our perception of ownership. Teams should be a people organization but often is just a grouping of people where everyb...

Spring Boot is the standard framework for developing java services nowadays. It's more than normal to have multiple deploys into productions during the day if you are not trapped by a release calendar or release train which should be a temporary thing and end up being a permanent thing. Ideally, you will have 3 at least 3 instances of your service, one for each availability zone in AWS. In order to introduce changes, DevOps often apply a pattern called Rolled Updates where often you patch one service and restart the application and then you do that one server at a time. In order to do that you server should be able to handle a clean shutdown and manage restarts smoothly which requires some config or code in your service side and also some consideration in sense of release resources, deny connections and prepare the land for a proper restart to happen. You might be in the middle of an important transaction so maybe you want to finish that first. For services is common to use the Sag...

@Value annotation allows you to inject either values or results of expression into fields or even methods and constructors. Spring has several mechanisms to deal with configuration and dependency inject. IMHO for Services is more them fine to use all these features, however for libraries we need to be extremely careful and I would say you don't want to use any of these capabilities. We also need to be careful about versioning properties inside jars, especially for libraries. It's very easy to get unpredictable behavior. So great powers require great responsibility and thinking beyond anything I made a video showing some of this feature and also some simple POC - so let's get started!