Diego Pacheco Tech blog

Debugging is an important tool. When it's possible to debug you have more chances to figure out the problem faster. Unfortunately not all issues are created equally and sometimes you cant debug. When you need to debug something is important to have your debug game sharp. Several engineers might consider the topic basic but as a consultant, I saw multiple times overtime people dont dominate the tools. Dominate and master your tools is important not only for productivity but also to improve your developer experience and make your life easier as an engineer.  I used Eclipse for a long time. For the last 3 months I decided to give IntelliJ a chance. A month ago I made a video about some killer stream debug trick and also how to do some configs. Today for this post I want to show some other IntelliJ Debug tricks which will make your life easier and will make debug much better and productive.

Software can get and often does get complex very fast. Many engineers and teams often don't understand the effects of some decisions resulting in extra Complexity. For this blog post, I want to explore more of these sources of Complexity. We can, in fact, only improve what we understand. Lean Thinking often tells us that we need to understand to see waste; otherwise, we cannot avoid it. Complexity can be generated thought of many sources. Nowadays, every single team is aware of technical debt. Technical debt is, in fact, too late, you can only fix it by refactoring. However, if you do teach your team to see and understand the Complexity, you will still be creating debt. It's impossible to have software that is 100% debt-free, however for sure, we can prevent a reasonable degree of debt by understanding software complexity and manage it proactively with proper education and carefully taught. Managing debt is a duty that every software product and project has. We need to act tact...

Software has hidden costs. For this post specifically, I want to cover in more depth the hidden costs of software architecture.  Making decisions is pretty cheap, you or your team could just say let's do this and that it. The cost of a decision could be not cheap at all, also the cost of a decision could be manifested only overtime when it is too late and you can't afford it any longer but them it is too late. That's why thinking will be(when it's possible and make sense ) much cheaper than doing it. Cheaper is a relative concept. If we think about innovation and product discovery there is no thinking up to the front, only experimentation. However, as we get into software engineering depending on the nature of the problem(high related to isolation/coupling and reversibility of the decisions) you might really want to think a bit more. This thinking could be called Architecture, Design, or just simple Due Diligence . In previous posts, I explore a lot the role coupling a...

Every software, DevOps, architect, QA engineer loves terminal applications. Console applications make uses more productive than GUI ones. One big important aspect of console/terminal application is the fact that they are scriptable and can be orchestrated with other automation solutions. This post is the sequence of the saga Linux Terminal Goods, If you did not check out previous posts you can do it here: Episodes I , II and III . I don't know if you realize but most of new and cool Linux console apps are written in Rust now a days.  So Let's get started.

Previously, I was blogging about two very HOT Button Issues ( The Death of Microservices and Why Waterfall can be better than Agile(Sometimes) . Today I want to expand and correlate these two topics a bit more. It's important to say again that I like agile, and I do it for +14 years. I have no problems talking about Agile issues. You shouldn't either. Hard questions sharpen our solutions. There is a huge difference between go trough a set of hard questions to justify investment harder than power or politics game to archive a result. The difference is one is healthy the other is not. There are "Healthy" matters like: Coupling, De-coupling, execution, Agile / Waterfall we should be able to navigate, talk, analyze trade offs without dogma or any issue whatsoever. However is hard to us to talk about some subjects right? What happens is that there is so much FEAR and TABOO on companies that some subjects cannot be ever on the table. Effective Learning means, we can talk...

Problem-solving is both a blessing skill and also a curse. It's on every software architect/engineer veins. It's pretty addictive and makes us feel useful and smart. Having sharp problem-solving skills is always great. I mean talent is gold. We want more talent, and what talent do intelligent solutions to complex problems. The heart of software engineering is fixing problems. Don't get me wrong this is good. However, sometimes we need to go with HARD DECISIONS. I can't think of a harder choice today than decide to pay the technical debt. However, once you got a design wrong and started things with the wrong feet is easy yo keep pushing problems aways without belly and keep the debt growing. Why does it happen?  

Sounds crazy, right? How could that possibly be the case? Before I continue, I need to say I',m doing agile for +14 years non-stop, and I sincerely believe Lean / Agile does good things. However, like everything in software, there are trade-offs. You might be thinking(Crazy Brazillian), and Agile is about incremental, fast feedback cycles, effective learning, and practical, tactical way to avoid waste and risk by shipping code to production often. How could that be bad, after all? To understand the hidden trade-offs here, we need to understand what is behind the principles of Agile. Hold on bozo; there is no such thing as assumptions behind principles. Recently I was challenging microservices . Today is Agile, tomorrow I don't know but something else might come up. To some degree, I feel agile needs to be challenged because last time I did it was around 2015. It's healthy to disagree if it helps to harden your decisions and as the whole team/company you take better decisi...